Multi-tenancy

Introduction

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

Configuration

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.

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:
      - "*"

Fields

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

name

Key	Required	Type	Description
name	Y	String	The name of the tenant.

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

description

Key	Required	Type	Description
description	N	String	The description of the tenant.

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

resources

Key	Required	Type	Description
resources	Y	List	A 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_mode

Key	Required	Type	Description
presentation_mode	N	Enum	The 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.

roles

Key	Required	Type	Description
roles	Y	List	The 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.

Examples

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.