Manage Kafka Visibility with Multi-Tenancy

Monday, August 16th 2021 by Derek Troy-West

This article teaches you how to configure Kpow to restrict visibility of Kafka resources with Multi-Tenancy.

Kpow provides sophisticated Role Based Access Control to allow, deny, or stage user actions for any Kafka resource, to a group or topic level. However, for some of our users controlling the actions that a user can take wasn't quite enough.

"I have hundreds of topics and groups, showing users all of them is confusing. Can I restrict visibility of resources with RBAC?"

The best part of working on Kpow is understanding the needs of engineering teams who use Apache Kafka. On the face of it using RBAC to restrict user visibility as well control of resources is reasonable, but when we considered the broader idea we understood this is a bigger problem.

Introducing Multi-Tenancy

Kpow Multi-Tenancy allows you to assign user roles to one or more tenants.

Each tenant explicitly includes or excludes resources such as Kafka Clusters, Groups, Topics, Schema Registries and Connect Clusters.

A user role may be assigned multiple tenants, and a user with multiple tenants has the ability to easily switch between them.

When operating within a tenant a user can only see resources included by that tenant or create resources that would be valid within that tenant.

Importantly, users will 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.

Now our user with hundreds of groups and topics can configure views for different business units and provide a simplified Kafka experience to their users.

Tenants In Action

Let's start at the end, below you can see the Broker UI of two different tenants operating in the one Kpow instance:

  • Global tenant is configured to contain all resources
  • Transaction tenant is configured to contain only topics starting with tx_*

Global Tenant UI

We can see 233 topics in the global tenant.


Transaction Tenant UI

The transaction tenant only shows 200 topics, and they are much more uniform.


A user can switch between these two tenants if they have roles with each tenant assigned. Kpow continues to observe and control all attached Kafka resources, but provides a consistent view of synthetic clusters constructed of only the groups and topics included in each tenant. Aggregated metrics like write/s and total disk space can be seen in either view with different figures.

Uses of Multi-Tenancy

The primary intended use of Multi-Tenancy is for you to provide restricted views of Kafka resources to users from different teams in your organisation.

However with the growth of Managed Kafka Services you may also want to configure basic tenants that exclude topics and groups of no regular interest.

Kpow stores all information regarding your Kafka resources in internal topics within your cluster, including an audit log of user actions. Kpow is also constructed of two Kafka Streams applications that run in unison to build the telemetry presented back to you.

A common user request has been to hide these internal topics and groups in the general UI as they're not of interest to our end users. Previously this had been a complicated task of in-place exclusion in the front-end, but aggregated metrics were hard to achieve.

If you have no tenants configured Kpow automatically provides two. A Global tenant that shows all attached Kafka resources and a Kpow Hidden tenant that hides Kpow resources and the consumer offsets topic.

You may want to provide tenants for specific business units, or you might just want to exclude internal topics from your cloud or managed service provider, or both!

Get Started

Multi-Tenancy is related to Role Based Access Control and both require User Authentication which is not available to trial users.

If you are on trial and would like to explore any of these features please request a license upgrade from [email protected].


Within your RBAC yaml configuration file you can specify a top-level tenants key:

The following example 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*" ]
      - "*"

For more information about Multi-Tenancy see our online documentation, for help contact [email protected].


Role Based Access Control
User Authentication
User Authorization