Confluent Cloud role-based access control (RBAC) provides a method to control access to
an organization, environment, or cluster configuration using predefined roles.
RBAC enables enterprises to protect their production environment by isolating
user and service account access and allowing for the delegation of authorization
to the appropriate business units and teams.
To control access to specific resources within a cluster, such as Kafka topics or
ksqlDB applications, continue to use ACLs.
For details about how RBAC impacts users and service accounts for
existing organizations, refer to Recommendations for Managing RBAC Roles for Existing Organizations.
The following terms are used throughout this topic. You should be familiar
The following limitations exist for Confluent Cloud RBAC:
Confluent Cloud RBAC roles help you to control access to an
organization, environments, and clusters within those environments. A user
can be assigned multiple roles. The following table shows the available roles and
the controls over resources provided by each.
Any new Confluent Cloud user who has not been granted an RBAC role cannot access
clusters or cluster data in the Confluent Cloud user interface. Hence, users who are
not yet assigned an RBAC role cannot inspect a cluster or use Confluent Cloud
to inspect topics or view messages in those topics.
You can also see this when viewing the options displayed in the top-right
hamburger menu (☰) in the upper-right corner of the Confluent Cloud user interface
(also referred to as ADMINISTRATION in task navigation paths below). For example,
the options available to users assigned the OrganizationAdmin role reflect the
actions granted by the role, and differ from those shown for users assigned the
EnvironmentAdmin and CloudClusterAdmin roles.
Additional details about each role appear below.
A new user who has not been granted one of the roles below cannot use the
Confluent Cloud user interface or Confluent Cloud CLI. If you want a user to view a cluster
to inspect topics and see messages in them using the Confluent Cloud user interface,
then you must grant (minimally) that user the CloudClusterAdmin role.
Provides the ability to manage access for all the resources (environments and
clusters) within an organization (including role bindings and ACLs) in
Confluent Cloud. The first user created in an organization is granted OrganizationAdmin
permissions so that he or she can bootstrap the appropriate roles to other users
in the organization.
Users assigned the OrganizationAdmin role can:
To delete a user, you must have the OrganizationAdmin role; it is the only
role that allows for the deletion of users in an organization.
Also, there must be at least one user with the OrganizationAdmin role. Do
not remove your own role binding if you are the only OrganizationAdmin. If
you do, then you must submit a support ticket to Confluent to promote
another user to OrganizationAdmin.
Provides the ability to manage resources (clusters) and roles for a specified
For details about how to create or rename an environment, refer to
Confluent Cloud Environments.
Users assigned the EnvironmentAdmin role can perform the following actions
within the environment specified for the role:
Provides the ability to manage specified clusters. Users with this
role cannot view or manage any other clusters or environments for which
they have not been assigned a role.
Users assigned the CloudClusterAdmin role can perform the following actions
within clusters specified for the role:
Provides service account access to the Confluent Cloud Metrics API for all clusters in
an organization. This role also enables service accounts to import metrics
into third-party metrics platforms.
Refer to Adding the MetricsViewer role to a new service account
in the Metrics API for
details about how to assign the MetricsViewer role binding to a new or existing
You can also assign the MetricsViewer role to users who need to view
metrics, but be aware that users assigned this role have unrestricted
access at the cluster level. Service account permissions within clusters
are limited by ACLs, but user permissions are not. Hence, users assigned
this role can perform actions such as creating and reading from topics.
Service accounts assigned the MetricsViewer role can perform the following
Users assigned the MetricsViewer role can perform the following actions:
Any admin user in an organization can invite other users to join by clicking the
+ Add user button while in the Accounts tab.
When inviting new users, you are prompted to specify roles for them. You are not
required to assign a role when inviting another user, and you can assign roles to
users at a later date. However, if you don’t specify a role, then the invitee
will be unable to use the Confluent Cloud user interface. You cannot grant a role that
is more general than the role(s) that you have. For example, a user with the
EnvironmentAdmin role cannot grant someone else the OrganizationAdmin role, and
a CloudClusterAdmin on one cluster cannot grant another user the CloudClusterAdmin
on a different cluster.
To join an organization, a user must be invited by another user already in the
organization. If a colleague attempts to sign up for Confluent Cloud at confluent.io
or confluent.cloud and specifies the same organization name on the sign-up page,
Confluent Cloud signs that user up and creates a new organization for her. This user
will not appear in your organization.
When adding a new user, you can assign that user multiple roles at the same time.
Note that when assigning the EnvironmentAdmin and CloudClusterAdmin roles, you
must also specify the scope (the cluster or environment name) for the role.
When finished, click Review to ensure you have entered the correct email
address and role assignments. When satisfied, click Create.
To delete users in an organization, you must be assigned the OrganizationAdmin
To delete a user from an organization:
This section explains the tasks associated with viewing and managing user and
service account roles in Confluent Cloud cluster RBAC, which includes:
In the navigation tree, boldface text indicates that the navigation tree
node you are viewing is expandable, and that it contains other
resources–for example, a cluster resides within the environment. Greyed out
text for individual resources indicates that the selected user or
service account has no role bindings on the selected resource.
To view all users in an organization, navigate to ADMINISTRATION -> Accounts &
access. The Accounts tab is displayed by default. All users listed here have
an account in the organization, regardless of whether or not they have been assigned
To view all service accounts in the organization, click the Services tab.
All service accounts in the organization are displayed, regardless of whether or
not they have been assigned a role.
To view the role bindings for all users in an organization navigate to
ADMINISTRATION -> Accounts & access. The Users tab is displayed by default.
Click the Access tab to view the role bindings for all users in your
organization. Upon expansion of the navigation tree, you can see whether or not
a user has an explicit role binding for any of the environments or clusters in
To view the role bindings for a specific user click the user’s name, then click
the Access tab. Expand the navigation tree to view the user’s role bindings
for each resource.
To view the role bindings for a specific service account, click the Services
tab, then click the Access tab. Expand the navigation tree to view the
service account’s role bindings for each resource.
To add a role binding for a user:
Navigate to ADMINISTRATION -> Accounts & access and select the user
for whom you want to add the role binding, then click the Access tab.
Click the specific resource (organization, environment, or cluster) for which
to create the role binding, and click +Add role assignment.
The only roles displayed when you click the Access tab for a user
are those that have been explicitly assigned to that user for a specific
resource. However, it is important to note that all users who are assigned
the OrganizationAdmin and EnvironmentAdmin roles also have access to the
clusters. If you are attempting to identify all users with access to a
cluster, be sure to include all users with an admin role in the organization
Also note that users assigned the EnvironmentAdmin role in one environment
cannot view accounts or resources in a different environment.
Select the tile for the role binding you want to create and click Save. When
subsequently viewing the Access tab for this user, the resources where this
role binding was added appear in boldface type.
To add a role binding for a service account:
To remove a role binding for a user:
There must always be at least one user with the OrganizationAdmin role. Do not
remove your own role binding if you are the only OrganizationAdmin. If you do,
then you must submit a support ticket to Confluent to promote another user to
To remove a role binding for a service account:
This section explains how to perform the tasks associated with viewing and
managing resources in Confluent Cloud cluster RBAC, which includes:
See also: Add the MetricsViewer role to a new service account in the UI.
You can view all Confluent Cloud resources in the same place. Resources in the scope of
Confluent Cloud RBAC include:
To view all resources to which your user account has access, navigate
to ADMINISTRATION -> Accounts & access and click the Access tab.
To view which users or service accounts have role bindings on specific resources:
To add a role binding to a resource:
To remove a role binding from a resource:
When you remove a user’s role assignment on a cluster for which the user created
an API key, that API key will continue to work even after the user’s role
assignment has been removed. For example:
In such cases, if the API key allows unintended access, you must delete it:
# List the API keys owned by Bob
ccloud api-key list --"Bob"
# Delete the API key that Bob created
ccloud api-key delete <api-key>
You must have the Confluent Cloud CLI installed.
Before assigning roles, you may want to first identify which users have access
to specific resources.
To list all the environments:
ccloud environment list
Id | Name
* env-nx5jd | RBAC_DEV
env-r0onp | kunal_rbac_test
env-qjdrd | AL_Ded
env-0d1z2 | Peter-Prod
env-m20ww | Peter-Dev
To list all Kafka clusters:
ccloud kafka cluster list
Id | Name | Type | Provider | Region | Availability | Status
lkc-xyxmz | cluster_0 | STANDARD | aws | us-east-2 | single-zone | UP
To list all users:
ccloud admin user list
Resource ID | Email | First Name | Last Name | Status
u-l772kw | email@example.com | Fred | Jones | Active
u-l772dp | firstname.lastname@example.org | Jane | Smith | Active
To list all service accounts (and locate the service account resource ID for role bindings):
ccloud service-account list
Id | Resource ID | Name | Description
441804 | sa-mvz5y7 | sa_org_admin | Service Account with Org Admin
445655 | sa-k8j1j2 | Metrics-Data |
447311 | sa-zm6vgz | MetricsImporter | A service account to import
| | | Confluent Cloud metrics into
| | | our monitoring system
To view details about a specific user:
ccloud admin user describe <user-ID>
| Resource ID | u-a01bcd |
| Email | email@example.com |
| First Name | Maria |
| Last Name | Developer |
| Status | Active |
The user ID used for this example is u-a01bcd.
To list all the role bindings that include the OrganizationAdmin role:
ccloud iam rolebinding list --role OrganizationAdmin
To grant the CloudClusterAdmin role to the principal u-e03vqq in the
environment env-nx5jd for the Kafka cluster lkc-xyxmz:
ccloud iam rolebinding create --principal User:u-a03bcd --role CloudClusterAdmin --environment env-nx5jd --cloud-cluster lkc-xyxmz
| Principal | User:u-a03bcd |
| Role | CloudClusterAdmin |
| ResourceType | Cluster |
To grant the MetricsViewer role to the service account sa-zm6vgz:
ccloud iam rolebinding create --role MetricsViewer --principal User:sa-zm6vgz
| Principal | User:sa-zm6vgz |
| Role | MetricsViewer |
| ResourceType | Cluster |
To view the role bindings for a specific user:
ccloud iam rolebinding list --principal User:<account-ID>
Principal | Role | ResourceType | Name | PatternType
User:u-4y8qjp | CloudClusterAdmin | Cluster | lkc-122yoj |
User:u-4y8qjp | CloudClusterAdmin | Cluster | lkc-222yqo |
User:u-4y8qjp | CloudClusterAdmin | Cluster | lkc-9kkdrv |
User:u-4y8qjp | CloudClusterAdmin | Cluster | lkc-mvv6y1 |
User:u-4y8qjp | CloudClusterAdmin | Cluster | lkc-nvv63k |
User:u-4y8qjp | CloudClusterAdmin | Cluster | lkc-pgg61o |
User:u-4y8qjp | EnvironmentAdmin | Environment | env-620o3 |
You can also use User:<email> to identify the principal in cloud iam
With the introduction of Confluent Cloud RBAC, all existing users and any service
accounts with Confluent Cloud API keys are granted the OrganizationAdmin role in all
existing organizations. Consequently, these users and service accounts will have
the same access level to Confluent Cloud and the Confluent Cloud CLI that they previously had
prior to the release of RBAC. Deactivated users or pending users who have not
clicked the invitation acceptance link in their email will not be assigned any
Unless OrganizationAdmin level of access is required, Confluent recommends
that you downgrade users and service accounts from the OrganizationAdmin role. If
a user requires access to inspect a cluster, or to use the Confluent Cloud UI to inspect
topics and view messages in them, grant that user the CloudClusterAdmin role.
Be sure to keep at least one OrganizationAdmin user account. If you remove the last
OrganizationAdmin user, then you will require a support ticket to Confluent to
promote another existing user to the OrganizationAdmin role.