Role Based Access Control
Role Based Access Control (RBAC) provides fine-grained control of user actions.
RBAC integrates with Overview, leveraging roles assigned to users in the credentials system of your choice. User roles are granted ALLOW, DENY, or STAGE to actions on specific resources.
RBAC configuration is defined in a YAML file and configured with an environment variable:
By default, Kpow will restrict UI access to users who have at least one role defined in the RBAC configuration.
You may override this behaviour by providing a specific list of
authorized_roles in your config.
You can open access to all users by specifying the special
"*" role in the
Users who have an Admin Role assigned (see below) are considered authorized to access Kpow regardless if authorization is derived from RBAC configuration or restricted to a specific list of authorized roles.
## Allow all users access to the UI ("*" is a role held by everyone) authorized_roles: - "*" ## Or, allow users with specific roles access to the UI authorized_roles: - "kafka-user" - "kafka-admin" - "ops-support"
You can optionally provide
admin_roles, a list of roles considered to be admins in Kpow.
You can learn more about administration in Kpow here: Administration.
admin_roles: - "kafka-admin"
An RBAC policy contains:
- Resource: The resource that this policy controls access to.
- Effect: Whether to deny, allow, or stage access to the Resource
- Actions: A list of actions that this policy Effects
- Role: The user role that this policy applies to
- Roles: The list of user roles that this policy applies to
The following configuration describes policies for two roles, one of which is an admin role, and permits all authenticated users access.
kafka-users with role names from your Identity Provider.
authorized_roles: - "*" policies: - resource: ["cluster", "N9xnGujkR32eYxHICeaHuQ"] effect: "Allow" actions: ["TOPIC_INSPECT", "TOPIC_PRODUCE", "TOPIC_EDIT"] role: "kafka-admin" - resource: ["cluster", "N9xnGujkR32eYxHICeaHuQ", "topic", "tx_audit"] effect: "Deny" actions: ["TOPIC_PRODUCE", "TOPIC_EDIT"] role: "kafka-admin" - resource: ["cluster", "*"] effect: "Allow" actions: ["GROUP_EDIT"] roles: ["kafka-admin"] - effect: "Stage" actions: ["GROUP_EDIT"] roles: ["kafka-user"] resources: # resources (plural) is also supported: - ["cluster", "*", "group", "tx_*"] - ["cluster", "*", "group", "payments_*"]
kafka-admin is allowed to inspect, produce, and edit all topics in a specific cluster, then explicitly denied produce and edit actions to one specific topic in that same cluster.
kafka-admin is then permitted group edit permissions on all clusters,
kafka-user are permitted stage access to the group edit action for groups starting with
tx_ - stage meaning the request will have to be confirmed by an admin user.
All remaining actions are implicitly denied actions to all users on all resources.
Resources are defined within a taxonomy that describes the hierarchy of objects in Kpow.
[DOMAIN_TYPE, DOMAIN_ID, OBJECT_TYPE?, OBJECT_ID?]
- Domain Type: The top-level resource, either cluster, schema, connect or ksqldb. Can be a wildcard (
*) to denote everything.
- Domain ID: Unique identifier of the domain or
- Object Type: (Optional) Either topic, group, connector, subject,, broker, ksqldb-source or ksqldb-query.
- Object ID: (Optional) Unique identified of the object. Prefix and Suffix supported.
Specifying the object is optional. If not provided the resource includes all objects within a domain.
["cluster", "*"] - all clusters and all objects ["cluster", "*", "topic"] - all topics on all clusters ["cluster", "N9xnGujkR32eYxHICeaHuQ"] - all objects in a cluster ["cluster", "*", "topic", "tx-events"] - named topic in all clusters ["schema", "*"] - all schema registries and all objects ["schema", "*", "subject", "tx-events"] - named subject in all schema registries ["connect", "*"] - all connect clusters and all objects ["connect", "*", "connector", "csv-*"] - matching connector in all connect clusters ["ksqldb", "*"] - matching all ksqldb servers and all objects ["ksqldb", "*", "ksqldb-source", "QUERYABLE_GRADES"] - matching all ksqldb servers source (table or stream) named QUERYABLE_GRADES
Kpow logs the IDs of all top-level domains at startup.
Connected to  Kafka clusters: * g10tMLohRLKthriTt0749g (Local): - kafka connect: http://kafka:8083 (g10tMLohRLKthriTt0749g) - schema registry not configured * lkc-lo019 (Confluent Cloud): - kafka connect not configured - schema registry: https://xxx.us-east-2.aws.confluent.cloud (a2f06a916672d71d675f) (Confluent Cloud)
In the example above we have four domain resources:
- Two Kafka Clusters (
- One Kafka Connect Cluster (
- One Schema Registry (
Resource ID Definitions
- Kafka Cluster: - the ID of the Kafka cluster as returned by a broker
- Kafka Connect: the ID of the Kafka cluster associated with the Kafka Connect installation
- Schema Registry: a SHA256 hash of the Schema Registry endpoint
Note: Where multiple policies apply to one resource, Deny effects take precedence.
Stage to indicate whether the policy allows or denies access to a resource. View Administration documentation to learn about the
Where no matching policy exists the effect is an implicit deny.
Define a user role to which you would like to allow or deny access.
Can be a wildcard (*) to specify the policy is for all roles.
User access to an action on a resource is determined by gathering all policies for roles assigned to a user and evaluating them with the following logic.
RBAC_EVALUATION_STRATEGY environment variable controls the precedence in which policies get applied.
This is the default evaluation strategy where Stage policies take precedence over Allow policies.
RBAC_EVALUATION_STRATEGY=STAGE_LENIENT will give precedence to Allow policies over Stage policies. This can be useful when a user has attached Stage policies and an administrator assigns an Allow temporary policy.
User Access Governance
All actions are retained in the Kpow Audit Log. See: Data Governance (Audit Log).
To use RBAC you must configure Overview and ensure users have assigned roles.
Below are integration guides for common authentication providers:
SAML Integration (Generic)
Kpow can integrate with your SAML IdP as a service provider.
Roles are defined in a
Roles attribute in the SAMLResponse from your IdP.
If you would like to use a field other than the
Roles attribute, you can extend the YAML configuration as follows:
saml: role_field: "Groups"
Now, Kpow will look to the
Groups attribute for its basis of roles.