In this article, we'll guide how to set up Kafka-UI with role-based access control.
Authentication methods
First of all, you'd need to set up authentication method(s). Refer to article for OAuth2 setup.
Config placement
First of all, you have to decide if either:
You wish to store all roles in a separate config file
Or within a main config file
This is how you include one more file to start with a docker-compose example:
services:
kafka-ui:
container_name: kafka-ui
image: provectuslabs/kafka-ui:latest
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 each role has access to defined clusters:
rbac:
roles:
- name: "memelords"
clusters:
- local
- dev
- staging
- prod
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.
A list of supported providers and corresponding subject fetch mechanism:
oauth_google: user, domain
oauth_github: user, organization
oauth_cognito: user, group
ldap: group
ldap_ad: (unsupported yet, will do in 0.8 release)
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:
Resource Can be one of the: CLUSTERCONFIG, TOPIC, CONSUMER, SCHEMA, CONNECT, KSQL, ACL.
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.
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":
