Role-Based Access Control Predefined Roles¶
This feature is available as a preview feature. A preview feature is a component of Confluent Platform that is being introduced to gain early feedback from developers. This feature can be used for evaluation and non-production testing purposes or to provide feedback to Confluent.
A role is an aggregation of permissions that define the tasks a user can perform. Confluent Platform provides predefined roles to help implement granular permissions for specific resources and to simplify access control across the Confluent Platform. You can’t create or define new roles, nor can you modify the permissions for predefined roles. Users can have multiple roles assigned to them. You cannot use a predefined role to override denial-of-access (DENY) that is configured in an ACL.
Confluent Platform provides the following predefined roles:
Cluster-level (Kafka cluster, KSQL cluster, or Schema Registry cluster) means that
users assigned this role have access to all resources in a cluster.
There are corresponding resource types for each cluster type.
For example, you can assign
ResourceOwner role to the
to provide a user all the
ResourceOwner privileges for a KSQL or Kafka
Resource-level means that users assigned this role only have access to specific resources as defined in the role binding.
For Operator Resource Manage, Operators can pause, resume, and scale Connectors.
Resources can be an Apache Kafka® topic, consumer group, transactionalID, cluster, Schema Registry, KSQL, Confluent Control Center, and any other Confluent Platform component.
|Role Name||Role Scope||View Role Bindings||Manage Role Bindings||Monitor||Resource Read||Resource Write||Resource Manage|
The purpose of
super.useris to have a bootstrap user who can initially grant another user the
super.useris not a predefined role. It is a
server.propertiesattribute that defines a user who has full access to all resources within a Metadata Service (MDS) cluster. A
super.userhas no access to resources in other clusters (unless also configured as a
super.useron other clusters). The primary use of super.user is to bootstrap Confluent Platform and assign a SystemAdmin. On MDS clusters,
super.usercan create role bindings for all other clusters. Permissions granted by
super.userapply only to the broker where the
super.userattribute is specified, and not to other brokers, clusters, or Confluent Platform components. No authorization is enforced on users defined as
super.user. It is strongly recommended that this role is assigned only to a limited number of users (for example, 1-2 users who are responsible for bootstrapping).
Provides full access to all scoped resources in the cluster (KSQL cluster, Kafka cluster, or Schema Registry cluster).
It is strongly recommended that this role is assigned only to a limited number of users (one or two per cluster) who need full permission for initial setup or to address urgent issues when absolutely necessary in production instances. You may wish to assign this role more liberally in small test and development use cases, or when working in KSQL clusters that are primarily single tenant. Otherwise, it is recommended that you do not assign this role.
Sets up clusters (KSQL cluster, Kafka cluster, or Schema Registry cluster).
Responsible for setting up and managing Kafka clusters, brokers, networking, KSQL clusters, Connect clusters, and adding or removing nodes and performing upgrades. The
ClusterAdmintypically creates topics and sets the properties of those topics, for example performance and capacity, but cannot read or write to topics, and has no access to data. For monitoring applications, it is recommended that this role is delegated to the operator who monitors your applications. Typically, the
ClusterAdminuser does not possess knowledge about the content of the cluster data and he/she delegates the ownership responsibility of those resources to users assigned the
ResourceOwnerrole. For example, after creating topics the
ClusterAdmincan set ownership to a specific user familiar with the topic data.
Manages role bindings for users and groups in all clusters managed by MDS.
Manages users and groups in a cluster, including the mapping of users and groups to roles. Has no access to any other resources. Typically, users with the
UserAdminrole are tasked with setting up access to resources. Users granted this role should be extremely trustworthy because they can grant roles to themselves and others. You can monitor the actions of the
UserAdminusing audit logs.
Enables management of platform-wide security initiatives.
Sets up security-related features (for example, encryption, tracking of audit logs, and watching for abnormal behavior). Provides a dedicated set of users for the initial setup and ongoing management of security functions.
Provides operational management of clusters and scale applications as needed.
Monitors the health of applications and clusters, including monitoring uptime. This role cannot create applications or see the content of the topics.
Transfers the ownership of critical resources and to scale the ability to manage authorizations for those resources.
Owns the resource and has full access to it, including read, write, and list. ResourceOwner can grant permission to others who need access to resources. Owner cannot change some of the configurations, for example the number of partitions. Must own the resource to grant others access to it. Enables scaling of authorization for critical resources.
- DeveloperRead, DeveloperWrite, DeveloperManage
- Allows developers to drive the implementation of applications they are working on and manage the content within, especially in development, test, and staging environments.
RBAC role use cases¶
These use cases are based on a new project where security is managed using RBAC predefined roles as follows:
|super.user||Sam is granted full access to all project resources and operations. He will create the initial set of roles for the project.|
|ResourceOwner||Ryan will own all topics with the prefix
|UserAdmin||Uri will manage the users and groups for the project.|
|Operator||Olivia will be responsible for the operational and health management of the platform and applications.|
|ClusterAdmin||Cindy is a member of the Kafka cluster central team.|
|DeveloperRead, DeveloperWrite, DeveloperManage||David will be responsible for developing and managing the application.|
The use cases below guide you through the application of predefined roles to illustrate one possible way you can leverage and use RBAC predefined roles.
|Project started by super.user||During the initial configuration, Sam is granted super.user access through the configuration file. Now Sam has access to all the resources within the Kafka cluster that is hosting MDS, and also can create role bindings to any resource managed by MDS.||super.user|
|Invite (using corporate tools like JIRA) users to build Confluent Platform platform||
Sam sets up role bindings for users and groups:
|UserAdmin defines and assigns roles||
Uri takes the following actions:
|UserAdmin, ResourceOwner, ClusterAdmin, Operator|
|ClusterAdmin creates topics and other resources||
Cindy joins the project to manage a Kafka cluster. She:
|Data governance is implemented||
|Developer creates applications||
David needs to create a new application that produces
to a topic (
|DeveloperWrite, DeveloperRead, DeveloperManage|
|Monitor health of the cluster and take proper actions||Olivia is responsible for managing the health of the resources in the cluster and takes actions when necessary. For example, if a connector has performance issues then she can increase the number of instances or scale them up.||Operator|