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.
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.
Tenant configuration is defined within your Role Based Access Configuration YAML file.
A tenant can:
Include or exclude specific topics or topic prefixes, e.g. tx-topic, tx-top*
Include or exclude specific groups or group prefixes, e.g. tx-group, tx-grou*
Include or exclude specific resources, e.g Kafka clusters, Schema registries, or Connect clusters
Be assigned to one or many user roles
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.
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.
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:
Contains only Kafka resources connected to or within Dev and UAT (or any combination of clusters)
Contains only specific topics or groups, or matches them with a prefix. E.g
Includes or excludes Connect or Schema resource in their entirety (more granular control shortly)
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 RBAC yaml configuration file you can specify a top-level
This configuration matches the default tenants that kPow provides if you have none configured.
tenants:- name: "Global"description: "All configured Kafka resources."resources:- include:- [ "*" ]roles:- "*"- name: "kPow Hidden"description: "All configured Kafka resources except internal kPow resources and __consumer_offsets."resources:- include:- [ "*" ]- exclude:- [ "cluster", "*", "topic", "oprtr*" ]- [ "cluster", "*", "topic", "__oprtr*" ]- [ "cluster", "*", "topic", "__consumer_offsets" ]- [ "cluster", "*", "group", "oprtr*" ]roles:- "*"
Each tenant is configured with a name, description, resources, and roles.
The name of the tenant.
name field will be the assigned name of the tenant used within kPow's UI. It must be unique.
The description of the tenant.
description field will be used within kPow's UI as a description when switching tenants.
A list of resources either included or excluded for this tenant.
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
Where the resource refers to the path of the object you wish to include/exclude.
["cluster", "*", "topic", "tx_*"]refers to any topic matching
tx_*for any Kafka cluster defined in kPow.
The list of roles assigned to this tenant.
roles field describes which roles (specified by your auth provider) are assigned to this tenant.
For more details about resources refer to the RBAC documentation.
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.
This tenant has 230 topics, 3.9GB replica disk and is receiving 762 writes/s
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.