Role Based Access Control (RBAC) provides fine-grained control of user actions.
RBAC integrates with User Authentication, 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:
1
RBAC_CONFIGURATION_FILE=/path/to/rbac-config.yaml
Copied!
Authorized Roles
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.
1
## Allow all users access to the UI ("*" is a role held by everyone)
2
authorized_roles:
3
-"*"
4
5
## Or, allow users with specific roles access to the UI
6
authorized_roles:
7
-"kafka-user"
8
-"kafka-admin"
9
-"ops-support"
Copied!
Admin Roles
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.
1
admin_roles:
2
-"kafka-admin"
Copied!
Policies
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
Then either:
Role: The user role that this policy applies to
Roles: The list of user roles that this policy applies to
Example Configuration
The following configuration applies controls to three roles and permits all authenticated users access.
Note: Where multiple policies apply to one resource, Deny effects take precedence.
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-userare permitted stage access to the group edit action - 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
Resources are defined within a taxonomy that describes the hierarchy of objects in kPow.
In the example above we have four domain resources:
Two Kafka Clusters (g10tMLohRLKthriTt0749g, lkc-lo0o9)
One Kafka Connect Cluster (g10tMLohRLKthriTt0749g)
One Schema Registry (a2f06a916672d71d675f)
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
Effects
Specify Allow, Deny or Stage to indicate whether the policy allows or denies access to a resource. View Staged mutations documentation to learn about the Stage effect.
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.
Role Evaluation
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.
User Access Governance
All actions are retained in the kPow Audit Log. See: Data Governance.
Role Mapping
To use RBAC you must configure User Authenticationand ensure users have assigned roles.
Integration Guides
Below are integration guides for common authentication providers: