User authorization



Multi-tenancy allows you to configure Kpow to restrict visibility of Kafka resources.

See the article How to manage Kafka visibility with Multi-tenancy for an overview.

About tenants

A tenant restricts the set of Kafka resources that are accessible to a user role from all the resources available to Kpow. A user role may be assigned multiple tenants.

When operating within a tenant a user can only see resources included by that tenant, they will also see a fully consistent synthetic cluster-view of their aggregated resources.

The overall user experience is simply of a restricted set of Kafka resources as if they were truly the only resources in the system.

A user can only create resources valid to their tenant.

Tenant configuration is defined within your Role Based Access Configuration YAML file.

A tenant can:

  • Include or exclude topics by name, prefix, or suffix, e.g. tx-topic, tx-top*, *-topic
  • Include or exclude groups by name, prefix, or suffix, e.g. tx-group, tx-grou*, *-group
  • Include or exclude full resources, e.g Kafka clusters, Schema registries, or Connect clusters
  • Be assigned to one or many user roles

Inferred Resources

Most resources are evaluated atomically as included or excluded.

Where a group is included, any topics that group consumes from are automatically included. This is in order to keep the synthetic cluster-view consistent. These resources are called inferred resources.

Resource evaluation

A tenant determines what resources are visible with the following logic:

  • Initially, all resources are implicitly excluded.
  • Explicitly included resources are added.
  • Inferred resources are added.
  • Exclusions are applied last.

Multi-tenancy use cases

The primary use for multi-tenancy is to provide different views of Kafka resources to different teams within your organisation.

Consider a Kpow that is connected to three Kafka clusters (Dev, UAT, Prod), each having 200 topics and 200 groups, two Connect installations and one Schema Registry.

You can create tenants that:

  • Contain Kafka resources connected to or within Dev and UAT (or any combination of clusters)
  • Contain specific topics or groups. E.g my-topic or my-grou*
  • Include or exclude Connect or Schema resource in their entirety
  • Any combination of the above.

The secondary use is to exclude groups and topics of no interest to your organisation.

For example, Kpow provides two default tenants when you have none specifically configured:

  • Global: All Kafka resources
  • Kpow Hidden: All Kafka resources with Kpow internal groups and topics excluded


Within your %{ link id="role-based-access-control" product="kpow-ee" /%} yaml configuration file you can specify a top-level tenants key:

This configuration matches the default tenants that Kpow provides if you have none configured.

  - name: "Global"
    description: "All configured Kafka resources."
      - include:
          - [ "*" ]
      - "*"
  - name: "Kpow Hidden"
    description: "All configured Kafka resources except internal Kpow resources and __consumer_offsets."
      - include:
          - [ "*" ]
      - exclude:
          - [ "cluster", "*", "topic", "oprtr*" ]
          - [ "cluster", "*", "topic", "__oprtr*" ]
          - [ "cluster", "*", "topic", "__consumer_offsets" ]
          - [ "cluster", "*", "group", "oprtr*" ]
      - "*"


Each tenant is configured with a name, description, resources, and roles.


nameYStringThe name of the tenant.

The name field will be the assigned name of the tenant used within Kpow's UI. It must be unique.


descriptionNStringThe description of the tenant.

The optional description field will be used within Kpow's UI as a description when switching tenants.


resourcesYListA list of resources either included or excluded for this tenant.

The resources field defines which resources are either included or excluded for this tenant.

Each item in the list is a map of either include: [resource...] or exclude: [resouce...]

Where the resource refers to the path of the object you wish to include/exclude.

For example: ["cluster", "*", "topic", "tx_*"]refers to any topic matching tx_*for any Kafka cluster defined in Kpow.

Possible resources:

  • ["cluster", "*", "group|topic|broker|principal", "...."]
  • ["schema", "*", "subject", "...."]
  • ["connect", "*", "connector", "..."]
  • ["ksqldb", "*", "ksqldb-source|ksqldb-query", "..."]


presentation_modeNEnumThe UI presentation mode for this tenant.

The presentation_mode field controls how the UI will be displayed based on its value and your configured tenancy rules:

Valid values:

  • DEFAULT - the default presentation mode. No menu items are hidden.
  • HIDE_RESOURCES - if the tenant has no associated Connect/Schema/ksqlDB resources then these menu items are hidden.


rolesYListThe list of roles assigned to this tenant.

The roles field describes which roles (specified by your User authentication provider are assigned to this tenant.

For more details about resources refer to the Role Based Access Control documentation.


Restrict brokers + broker configuration

The following configuration restricts all broker information including broker configuration from the UI:

   - exclude: [ "cluster", "*", "broker", "*" ]

Restrict ACL principals

The following configuration restricts all ACL information to only the principal User:Kpow

   - include: [ "cluster", "*", "principal", "User:Kpow" ]

Restrict Kafka Connect connectors

The following configuration restricts all Kafka Connect connectors to only connector IDs that match the wildcard tx-*

   - include: [ "connect", "*", "connector", "tx-*" ]

Restrict Schema Registry subjects

The following configuration restricts all Schema Registry subjects to only subject IDs that match the wildcard tx-*

   - include: [ "schema", "*", "subject", "tx-*" ]

User experience

Kpow users with a single tenant are automatically entered into that tenant on session start.

Kpow users with multiple tenants have the option of choosing and switching tenant:

Once a tenant is selected the user the chooses a cluster (if multi-cluster is configured)

A user can switch tenants at any time by selecting the top-left user context menu

Once a tenant is selected the user is presented an internally consistent view of a synthetic set of Kafka resources that matches the tenant exactly.

Here is an example of the Cluster view in two tenants in our demo environment.

Each tenant provides a different synthetic view of the Kafka resources configured with Kpow.

Global tenant

This tenant has 230 topics, 3.9GB replica disk and is receiving 762 writes/s

Transaction tenant

This tenant has 200 topics, 86.8MB replica disk and is receiving 1.75 writes/s.

It looks strikingly different because tx-* topics are generated event topics in our demo environment.