Gateway resources

​

Deploy Interceptor

---
apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: enforce-partition-limit
  # scope:
  #   vCluster: aaa
  #   group: bbb
  #   username: ccc
spec:
  pluginClass: "io.conduktor.gateway.interceptor.safeguard.CreateTopicPolicyPlugin"
  priority: 100
  config:
    topic: "myprefix-.*"
    numPartition:
      min: 5
      max: 5
      action: "INFO"

• metadata.scope is optional (default empty).
• metadata.scope.[vCluster | group | username] combine with each other to define the targeting
  • Check the dedicated Interceptor targeting section
• spec.pluginClass is mandatory. Has to be a valid Interceptor class name.
• spec.priority is mandatory
• spec.config is a valid config for the pluginClass

​

Interceptor targeting

​

Examples

  ---
  # This interceptor targets everyone (Including Virtual Clusters)
  apiVersion: gateway/v2
  kind: Interceptor
  metadata:
    name: enforce-partition-limit
    scope:
      vCluster: null
      group: null
      username: null
  spec:

  ---
  # This interceptor targets everyone (Excluding Virtual Clusters)
  apiVersion: gateway/v2
  kind: Interceptor
  metadata:
    name: enforce-partition-limit
  spec:

  ---
  # This interceptor targets only `admin` service account
  apiVersion: gateway/v2
  kind: Interceptor
  metadata:
    name: enforce-partition-limit
    scope:
      username: admin
  spec:

  ---
  # This interceptor targets only `read-only` virtual cluster
  apiVersion: gateway/v2
  kind: Interceptor
  metadata:
    name: enforce-partition-limit
    scope:
      vCluster: read-only
  spec:

​

GatewayServiceAccount

• creating local service accounts
• renaming service accounts for easier clarity when using Interceptors
• attaching service accounts to Virtual Clusters

---
# External user renamed
apiVersion: gateway/v2
kind: GatewayServiceAccount
metadata:
  name: application1
spec:
  type: EXTERNAL
  externalNames:
  - 00u9vme99nxudvxZA0h7
---
# Local User on Virtual Cluster vc-B
apiVersion: gateway/v2
kind: GatewayServiceAccount
metadata:
  vCluster: vc-B
  name: admin
spec:
  type: LOCAL

• When spec.type is EXTERNAL:
  • spec.externalNames must be a non-empty list of external names. Each name must be unique across all declared GatewayServiceAccount.
  • we currently only support a list of one element.

• When spec.type is EXTERNAL:
  • During Client connection, the authenticated user will be checked against the list of externalNames to decide which GatewayServiceAccount it is.
• When spec.type is LOCAL:
  • Access to /gateway/v2/tokens endpoint to generate a password for this service account
  • Switching a GatewayServiceAccount spec.type from LOCAL to EXTERNAL does not invalidate previously emitted tokens. They will keep on working for their TTL.

​

GatewayGroup

---
# Users added to the group manually
apiVersion: gateway/v2
kind: GatewayGroup
metadata:
  name: group-a
spec:
  members:
    - name: admin
    - vCluster: vc-B
      name: "0000-AAAA-BBBB-CCCC"

• spec.members[].name is mandatory.
  • Currently, the username needs to refer to an existing GatewayServiceAccount otherwise it will fail. This is a known issue that we’ll address in a further release.
• spec.members[].vCluster is optional. It has to refer to an existing Virtual Cluster. When not using Virtual Clusters, don’t set this attribute.

• All members of the group will be affected by Interceptors deployed with this group’s scope.

​

ConcentrationRule

---
apiVersion: gateway/v2
kind: ConcentrationRule
metadata:
  # vCluster: vc-B
  name: toutdanstiti
spec:
  pattern: titi-.*
  physicalTopics:
    delete: titi-delete
    compact: titi-compact
    deleteCompact: titi-cd
  autoManaged: false
  offsetCorrectness: false

• metadata.vCluster is optional. Must refer to an existing Virtual Cluster. When not using Virtual Clusters, don’t set this attribute.
• spec.physicalTopics.delete is mandatory. Has to be a valid topic name with a cleanup.policy set to delete.
• spec.physicalTopics.compact is optional. Has ti be a valid topic name with a cleanup.policy set to compact.
• spec.physicalTopics.deleteCompact is optional. Has to be a valid topic name with a cleanup.policy set to delete,compact.
• spec.autoManaged is optional, default is false.
• spec.offsetCorrectness is optional, default is false.

• Once the Concentration Rule is deployed, topics created with a name matching the spec.pattern will not be created as real Kafka topics but as concentrated topics instead.
• Depending on the topic’s cleanup.policy, the topic’s data will be stored in one of the configured physical topics.
• If a topic creation request is made with a cleanup.policy that isn’t configured in the ConcentrationRule, topic creation will fail.
• It is not possible to update cleanup.policy of a concentrated topic.
• If spec.autoManaged is set to true, the underlying physical topics and configurations will be automatically created and/or extended to honour the topics configurations.
• If spec.offsetCorrectness is set to true, Gateway will maintain a list of offsets for each of the concentrated topic records.
  • This allows for a proper calculation of message count and consumer group lag.
  • There are some limitations with offset correctness.
• If spec.offsetCorrectness is set to false, Gateway will report the offsets of the backing topic records.

​

VirtualCluster

---
apiVersion: gateway/v2
kind: VirtualCluster
metadata:
 name: "mon-app-A"
spec:
 aclEnabled: false

• metadata.name must be a valid topic prefix as all vcluster topics and consumer groups will be created on the physical kafka cluster with this as the prefix (they will appear on the vcluster without the prefix).
• spec.aclEnabled is optional (default false). When unset or false,
  • there are no authorization checks for clients connecting to the vcluster. Clients are free to perform any operation on resources within the vcluster
  • The fields acls and superUsers cannot be set
• spec.type must be either Standard or Partner (default if not set is Standard)

​

ACLs configurable via Kafka

---
apiVersion: gateway/v2
kind: VirtualCluster
metadata:
 name: "mon-app-A"
spec:
 aclEnabled: true
 aclMode: KAFKA_API
 superUsers:
 - username1
 - username2

• when spec.aclMode is set to KAFKA_API (default if aclEnabled: true)
  • it cannot be changed
  • acls cannot be set
  • spec.superUsers must be set
• spec.superUsers is the list of usernames for which the associated service accounts in this virtual cluster can bypass ACLs.
  • Specified usernames are not created automatically. You still need to create the associated gateway service accounts on the vcluster for them to work.

​

ACLs configurable via REST

---
apiVersion: gateway/v2
kind: VirtualCluster
metadata:
 name: "mon-app-A"
spec:
 aclEnabled: true
 aclMode: REST_API
 acls:
  - resourcePattern:
      resourceType: TOPIC
      name: customers
      patternType: LITERAL
    principal: User:username1
    operation: READ
    permissionType: ALLOW
  - resourcePattern:
      resourceType: TOPIC
      name: customers
      patternType: LITERAL
    principal: User:username1
    operation: WRITE
    permissionType: ALLOW

• when spec.aclMode is set to REST_API
  • it cannot be changed
  • spec.acls must be set
  • spec.superUsers cannot be set
• spec.acls is the complete list of ACL bindings for the vcluster and allows (nearly) any valid Kafka API ACL binding (inc * wildcards) to be set. For a complete list of valid ACL bindings checkout the Open API schema.

​

AliasTopic

---
apiVersion: gateway/v2
kind: AliasTopic
metadata:
  name: name1
  vCluster: vCluster1
spec:
  physicalName: physicalName1

​

Related resources

• Use and configure Interceptors
• View Interceptor reference
• Give us feedback/request a feature