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.
- The AuditAdmin role provides sufficient access for creating and managing the audit log configuration.
- For Operator Resource Manage, Operators can only pause, resume, and scale
The purpose of
super.user is to have a bootstrap user who can initially
grant another user the
super.user is not a predefined role. It is a
server.properties attribute that defines a user who has full access to all
resources within a Metadata Service (MDS) cluster. A
has no access to resources in other clusters (unless also configured as a
other clusters). The primary use of super.user is to bootstrap
Confluent Platform and assign a SystemAdmin. On MDS clusters,
super.user can create role
bindings for all other clusters. Permissions granted by
only to the broker where the
super.user attribute 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 (ksqlDB 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 ksqlDB
clusters that are primarily single tenant. Otherwise, it is recommended that
you do not assign this role.
Sets up clusters (ksqlDB cluster, Kafka cluster, or Schema Registry cluster).
Responsible for setting up and managing Kafka clusters, brokers, networking,
ksqlDB clusters, Connect clusters, and adding or removing nodes and
performing upgrades. The
ClusterAdmin typically 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
ClusterAdmin user 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
For example, after creating topics the
ClusterAdmin can 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
UserAdmin role 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
using 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.
- Users or groups assigned this role on the MDS cluster and every
registered Kafka cluster can manage the audit log configuration using
the Confluent Metadata API.
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, nor does it allow you to view or edit
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
RBAC role use cases
These use cases are based on a new project where security is managed using
RBAC predefined roles as follows:
||Sam is granted full access to all project
resources and operations. He will create the
initial set of roles for the project.
||Ryan will own all topics with the prefix
finance_. He can grant others permission to
access and use this resource. In this use case,
he is the ResourceOwner for the finance topics.
||Uri will manage the users and groups for
||Olivia will be responsible for the operational
and health management of the platform and
||Cindy is a member of the Kafka cluster central
|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
||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.
|Invite (using corporate tools
like JIRA) users to build Confluent Platform
Sam sets up role bindings for users and groups:
- Uri: Granted UserAdmin role to manage users/groups
- If needed, Sam can grant the SystemAdmin role for the
cluster to others (only if absolutely necessary).
|UserAdmin defines and assigns
Uri takes the following actions:
- If needed, Uri creates new groups in corporate LDAP
(for example, Kafka developer group) making it easier
to manage role bindings for multiple users at the same
- Grants Ryan ResourceOwner role on topics that use
- Grants Olivia Operator role on a Connect cluster
so she can manage operations.
- Grants Cindy the ClusterAdmin role. Now Cindy can
|ClusterAdmin creates topics
and other resources
Cindy joins the project to manage a Kafka cluster. She:
- Manages brokers and updates configurations as needed.
- Receives a request to create topics for the finance
- She creates topics with the
- She cannot read or write to these topics.
|Data governance is implemented
- Ryan has ResourceOwner rights to all the topics
finance_, so he can view all these
- Ryan grants appropriate access rights for all topics
with the prefix
- Ryan is notified through the existing corporate
workflow that there is a request for access to
topics and other critical resources to which he
can grant or deny access.
|Developer creates applications
David needs to create a new application that produces
to a topic (
- If David has not already been added as a developer
(through user/group mapping by Uri), then he must
request access from Ryan .
- Ryan (ResourceOwner) grants David the DeveloperWrite
role on the topic``finance_report``.
- Ryan (ResourceOwner) can grant David the DeveloperRead
or DeveloperManage roles too, depending on what kind
of operations David’s application needs to perform.
|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.