Skip to main content

Dynamic Topic Aliases

Use CaseMulti-tenantZilla Plus
★Zilla Plus This use case is implemented by Zilla Plus, Aklivity's commercial edition of Kafka Gateway.

The Problem

Platforms with many external Kafka clients, whether internal teams, partners, or end customers, often want every client to address the same external topic name for simplicity, while keeping each client's data fully isolated in its own internal topic. Provisioning a distinct external topic name per client doesn't scale: onboarding a new client means hand-editing routing configuration for every topic they touch.

How Zilla Solves It

Zilla Plus's kafka-proxy binding pairs a topic's alias template with the identity established by a guard during the client's SASL handshake. Every client authenticates against the same external topic name; Zilla rewrites the internal topic name from a placeholder such as ${guarded['<guard-name>'].identity}, so each client transparently lands on its own dedicated internal topic, with no per-client entry in zilla.yaml.

Pairing this with the aws-cognito guard lets each client authenticate over SASL/OAUTHBEARER with a client_credentials token from its own Cognito app client, so onboarding a client is provisioning a Cognito app client and a Kafka topic, not touching the proxy configuration.

Architecture

Key Capabilities

  • Per-client topic isolation with one external topic name: no per-client routing configuration.
  • Identity-driven aliasing: topics[].alias substitutes the guard-established identity or a named attribute into the internal topic name.
  • Guard-agnostic: works with any guard that authenticates the external SASL handshake, including aws-cognito and jwt.
  • SASL/OAUTHBEARER termination: external clients authenticate with a bearer token instead of static credentials; on rejection they receive an RFC 7628 challenge instead of an immediate SASL failure.

Configure Topic Aliasing

A topics[].alias template rewrites the internal topic name using the identity established by the named guard during the external SASL handshake:

kafka_cluster:
  type: kafka-proxy
  kind: proxy
  options:
    topics:
      - name: messages
        alias: "messages-${guarded['cognito0'].identity}"
    external:
      authorization:
        cognito0:
          mechanism: oauthbearer
      host: kafka-#.external.net
      port: 9094

Every client produces and fetches through the external messages topic name; Zilla Plus rewrites it to messages-<their-identity> on the way to the internal cluster, based on the identity the cognito0 guard established during that client's SASL/OAUTHBEARER handshake.

Deploy

See Dynamic Topic Aliases with AWS Cognito on AWS ECS Fargate for a full walkthrough: provisioning the Cognito user pool, the complete zilla.yaml, IAM roles, and the ECS task definition.