Ctrlk
WebsiteGithubDiscordLinkedinProduct HuntAWS Marketplace
For the complete documentation index, see llms.txt. This page is also available as Markdown.
Edit

RBAC (Role based access control)

Role-based access control

In this article, we'll guide how to set up Kafbat-UI with role-based access control.

Authentication methods

First of all, you'd need to set up authentication method(s). Refer to this article for setup.

Config placement

First of all, you have to decide if either:

  1. You wish to store all roles in a separate config file

  2. Or within a main config file

This is how you include one more file to start with a docker-compose example:

services:
  kafbat-ui:
    container_name: kafbat-ui
    image: ghcr.io/kafbat/kafka-ui
    environment:
      KAFKA_CLUSTERS_0_NAME: local
      # other properties, omitted
      SPRING_CONFIG_ADDITIONAL-LOCATION: /roles.yml
    volumes:
      - /tmp/roles.yml:/roles.yml

Alternatively, you can append the roles file contents to your main config file.

Roles file structure

Clusters

In the roles file we define roles, duh. Every role has access to defined clusters:

Subjects

A role also has a list of subjects which are the entities we will use to assign roles to. They are provider-dependant, in general, they can be users, groups, or some other entities (github orgs, google domains, LDAP queries, etc.) In this example we define a role memelords that will contain all the users within the Google domain memelord.lol and, additionally, a GitHub user Haarolean. You can combine as many subjects as you want within a role.

The subject value is either a fixed string or a regular expression identifying a subject. To use regular expression, you must set regex: true. Regular expression works for any combination of provider and type. In this example, we define a role admins that will contain all the users with an oauth role ending with -ADMIN.

Providers

A list of supported providers and corresponding subject fetch mechanism:

  • oauth: user, role

  • oauth_google: user, domain

  • oauth_github: user, organization, team

  • oauth_cognito: user, group

  • ldap: user, group

  • ldap_ad: user, group

More on identity providers in: Supported Identity Providers

Find the more detailed examples in a full example file lower.

Permissions

The next thing which is present in your roles file is, surprisingly, permissions. They consist of:

  1. Resource Can be one of the: CLUSTERCONFIG, TOPIC, CONSUMER, SCHEMA, CONNECT, CONNECTOR, KSQL, ACL.

  2. The resource value is either a fixed string or a regular expression identifying a resource. Value is not applicable to clusterconfig and ksql resources. Please do not fill it out.

  3. Actions It's a list of actions (the possible values depend on the resource, see the lists below) that will be applied to the certain permission. Also, note, there's a special action for any of the resources called "all", it will virtually grant all the actions within the corresponding resource. An example for enabling viewing and creating topics whose name start with "derp":

Actions

A list of all the actions for the corresponding resources (please note neither resource nor action names are case-sensitive):

  • applicationconfig: view, edit

  • clusterconfig: view, edit

  • topic: view, create, edit, delete, messages_read, messages_produce, messages_delete, analysis_run, analysis_view

  • consumer: view, delete, reset_offsets

  • schema: view, create, delete, edit, modify_global_compatibility

  • connect: view, edit, create, delete, operate, reset_offsets — applies to all connectors in a connect cluster

  • connector: view, edit, create, delete, operate, reset_offsets — granular per-connector permissions (value format: connectName/connectorName)

  • ksql: execute

  • acl: view, edit

  • audit: view

  • client_quotas: view, edit — not yet implemented

Default Role

The Default Role is applied to users who have successfully authenticated but do not have a mapped role assigned. This role only requires permissions configuration.

Example file

A complete file example:

A read-only setup:

An admin-group setup example:

An admin group with a read-only default role example:

PreviousSASL_SCRAMNextSupported Identity Providers

Last updated

Was this helpful?