Use Role-Based Access Control (RBAC) in Confluent Cloud

Confluent Cloud role-based access control (RBAC) lets you control access to an organization, environment, cluster, or granular Kafka resources (topics, consumer groups, and transactional IDs), Schema Registry resources, and ksqlDB resources based on predefined roles and access permissions. Use RBAC to protect your Confluent Cloud resources and data by authorizing and restricting access of user and service accounts and by delegating access authorization to the appropriate business units and teams in your organization.

See also

• See the RBAC and ACL module of the free Confluent Cloud Security course to learn about RBAC, RBAC roles, and considerations to keep in mind when using RBAC in Confluent Cloud.
• See RBAC and Resources per Component for a summary list and links to specifics on how to use RBAC with each component.

The following concepts are important to understand before using RBAC:

• Organizations
• Environments
• User accounts
• Service accounts

• Networks

Limitations

The following limitations exist for Confluent Cloud RBAC:

• Granular Kafka RBAC is available only on Standard and Dedicated clusters.
• If a user account is deleted, all API keys and role bindings associated with that user are also deleted.
• To create service accounts, you must be granted the OrganizationAdmin role. All the other cluster administration roles (EnvironmentAdmin, CloudClusterAdmin, and ResourceOwner) can grant or revoke permissions for existing service accounts on the resources that they control.
• For service quotas for role bindings, see Service Quotas for Confluent Cloud.
• For Confluent CLI, use the latest version (v. 2.8.1 or later).

Role limitations by resource

Here are temporary limitations for Confluent Cloud resources that you should be aware of:

• Consumers and producers
  • Any user granted access to a cluster can view all of the consumers and producers of the cluster. This is subject to change and you must not rely on this access. To view consumers and producers, you should grant the Operator role.
• ksqlDB clusters
  • If you remove role bindings for a user with an Organization, Environment, or Cluster scope that includes ksqlDB resource access, the user’s API keys are not automatically deleted. A user with an administrator role binding (OrganizationAdmin, EnvironmentAdmin, or CloudClusterAdmin) can create an API key for a ksqlDB cluster while they are an administrator and continue using that key even after their administrator role binding is removed. The API key continues allowing full access to the ksqlDB clusters. As a best practice, when you remove role bindings, make sure to remove any corresponding API keys. To learn more, see Delete unneeded API keys and service accounts.
  • Any user granted the Operator role has no access to ksqlDB clusters and cannot see any information related to ksqlDB clusters.
  • Any user granted the KsqlAdmin role can’t create ksqlDB clusters, but they can list and terminate the specific cluster the role is granted to. A user who has the KsqlAdmin role for a ksqlDB cluster has full access to all resources on the cluster, like streams and persistent queries.
  • A KsqlAdmin can create API keys that can access the ksqlDB cluster the role has access to, as long as the role has access to those clusters. When the role binding is removed, access is revoked.
  • The KsqlAdmin role can be granted only by accounts that have the CloudClusterAdmin, EnvironmentAdmin, or OrganizationAdmin role.
  • When a ksqlDB cluster is deleted, all KsqlAdmin rolebindings assigned to that cluster are deleted.
  • The KsqlAdmin role does not automatically have access to the Kafka cluster or the ability to look at Kafka ACLs or role bindings.

Use ACLs with RBAC

You can use RBAC role bindings together with ACLs. Principals (user and service accounts) can be granted ACLs, RBAC role bindings, or a combination of the two. All of these grants are considered when deciding whether to allow access. For details on the interactions between ACL rules and RBAC roles, see Order of precedence below.

With RBAC available in the data plane for Kafka resources (topics, consumer groups, and transactional IDs):

• Users no longer have super.user access to Kafka clusters and only have permissions that have been explicitly granted.
• Grant granular access to resources using ACLs and RBAC role bindings for user and service accounts.
• Both ACLs and RBAC role bindings that grant granular access to resources can now be used with service accounts.

Order of precedence

In Confluent Cloud, ACLs and RBAC role bindings work together based on the following order of precedence:

1. ACL DENY rules are applied first. If an ACL DENY is applied, then access is denied regardless of any ACL ALLOW rules and RBAC role bindings.
2. ACL ALLOW and RBAC roles are applied. All RBAC roles are ALLOW.

When there are no ACL DENY rules that apply:

• If you only have an RBAC permission for a given resource, but not the ACL, then you have permissions for that resource.
• If you have only an ACL permission, you have permissions on the resource.
• If you have both an RBAC and ACL permission, then you have permissions on the resource.

Confluent Cloud RBAC roles

You can use Confluent Cloud RBAC roles to control access to an organization, its environments, the clusters within each environment, and the Kafka resources on those clusters. Principals can be assigned multiple roles.

The following table displays the hierarchy of available roles, ordered by their scope of access, from the broadest to the most restrictive. Unlike Confluent Platform, where all roles are bound at the cluster scope, role bindings in Confluent Cloud can occur at higher-level scopes.

Role	View Scope	Admin Scope
OrganizationAdmin	All	All
EnvironmentAdmin	Organization, Support Plan, Users	All clusters in the environment, Schema Registry, Networking
CloudClusterAdmin	Organization, Environment, Support Plan, Users	Specified Cluster, Topics, ksqlDB applications, Connectors
Operator	Organization, Environment, Cluster	N/A
NetworkAdmin	Organization, Environment, Cluster (read-only access; no access to cluster resource data), Networks	Networks (across all environments in an organization)
MetricsViewer	Organization, Environment, Cluster	N/A
ResourceOwner	Organization, Environment, Cluster	Specified Resource (Topic, Schema Subjects, Consumer Group, or Transactional ID)
DeveloperManage	Organization, Environment, Cluster	Specified Resource (Topic, Schema Subjects, Consumer Group, or Transactional ID)
DeveloperRead	Organization, Environment, Cluster	Specified Resource (Topic, Schema Subjects, Consumer Group, Connector, or Transactional ID)
DeveloperWrite	Organization, Environment, Cluster	Specified Resource (Topic, Schema Subjects, Consumer Group, Connector, or Transactional ID)
DataDiscovery	Organization, Environment, Cluster (no access to data being produced or consumed)	N/A
DataSteward	Organization, Environment, Cluster (no access to data being produced or consumed)	N/A
KsqlAdmin	ksqlDB cluster resources and associated Organization, Environment, Kafka Cluster (but not their resources)	Specified ksqlDB cluster (list/terminate cluster, streams, tables, queries, topics)

Important

Resource-specific role bindings change the way authorization works in Kafka, so users who previously had no role bindings but had valid API keys are being “grandfathered” in and granted the ResourceOwner role for all resources in their organization’s clusters (equivalent to Topic:*, Group:*, and TransactionalId:*). If you do not want such users to have the ResourceOwner role bindings for all topics and consumer groups in your organization, you must explicitly remove these role bindings.

You can also see this when viewing the options displayed in the sidebar menu of the Confluent Cloud Console. For example, the options available to principals assigned the OrganizationAdmin role reflect the actions granted by the role, and differ from those shown for principals assigned the EnvironmentAdmin and CloudClusterAdmin roles.

Details about each Confluent Cloud RBAC role are included below.

Caution

A new principal that has not been granted one of the roles below cannot use the Confluent Cloud Console or Confluent CLI. To allow a principal to inspect topics and view messages using the Confluent Cloud Console, you must minimally grant that account the DeveloperRead role.

OrganizationAdmin

Principals granted the OrganizationAdmin role in Confluent Cloud have the following access permissions:

• Full access to manage all resources within an organization (including environments, clusters, topics, consumer groups, transactional IDs, ksqlDB clusters, connectors, schema registries, role bindings, and ACLs).
• The first user account created in an organization is automatically granted the OrganizationAdmin role, which allows that user to start granting the appropriate roles to other principals in the organization.

The OrganizationAdmin role allows principals to perform the following actions:

• Grant and revoke access throughout the organization
• Invite and delete users
• Create service accounts
• Manage billing and support plans
• Enable or disable Schema Registry and manage schemas
• Create and manage environments
• Create and manage clusters
• Manage cluster network configurations for all clusters across all environments
• Access and manage audit logs.
• Create and manage Kafka resources, including topics, consumer groups, and transactional IDs
• Full access to stream lineage views
• Create and manage ksqlDB clusters
• Create and manage connectors

Note

To delete a user or service account, you must have a role binding with the OrganizationAdmin role.

You cannot remove your own OrganizationAdmin role binding. If you want to give up your administrative privileges, you must request that another user with the OrganizationAdmin role remove it for you. Each organization must have at least one principal assigned the OrganizationAdmin role.

EnvironmentAdmin

Principals granted the EnvironmentAdmin role in Confluent Cloud have the following access permissions:

• Full access to manage all resources for the specified environment
• Cannot view or manage any environments or resources in other environments in which they are not assigned a role

For details about how to create or rename an environment, refer to Environments for Confluent Cloud.

The EnvironmentAdmin role allows principals to perform the following actions within the environment specified for the role:

• Grant and revoke access within their environment
• Grant and revoke access RBAC permissions for existing service accounts. To create service accounts, you must be granted the OrganizationAdmin.
• Invite users
• Enable or disable Schema Registry and manage schemas
• Create and manage clusters
• Manage cluster networking configurations for all clusters
• Create and manage Kafka resources, including topics, consumer groups, and transactional IDs
• Full access to stream lineage views
• Create and manage ksqlDB clusters
• Create and manage connectors

CloudClusterAdmin

Principals granted the CloudClusterAdmin role in Confluent Cloud have the following access permissions:

• Full access to manage the specified cluster.
• Cannot view or manage any other clusters, environments, or networking configurations for which they are not assigned a role.
• For temporary limitations that you should be aware of, review Limitations.

The CloudClusterAdmin role allows principals to perform the following actions within clusters specified for the role:

• Grant and revoke access within the cluster
• Grant and revoke access permissions for existing service accounts. To create service accounts, you must be granted the OrganizationAdmin.
• Invite users
• Create and configure ksqlDB clusters
• Create and configure connectors
• View and manipulate topics through the Confluent Cloud Console and Confluent CLI
• No access to view or manage cluster networking configurations
• No access to view or manage schema subjects

NetworkAdmin

The NetworkAdmin role enables network administrators to manage the lifecycle of Confluent Cloud networks and network connections, and to provision access for dedicated clusters in Confluent Cloud networks.

Users assigned the NetworkAdmin role can:

• create and provision Confluent Cloud networks and network connections for all environments in an organization and make those networks available to the platform or infrastructure teams within the organization to deploy dedicated Confluent Cloud clusters.
• Full access to stream lineage views

Users assigned the NetworkAdmin role (typically, a dedicated network administrator) cannot access cluster resource data, such as topics, consumer groups, connectors, ksqlDB clusters, and Schema Registry.

Operator

Principals granted the Operator role in Confluent Cloud have the following access permissions:

• Read-only (or “viewer”) access to everything within the specified organization, environment, or cluster with the exception of schema subjects
• Can be bound at multiple scopes (for example, on the entire organization, a specific environment, or specific cluster)
• For temporary limitations that you should be aware of, review Role limitations by resource.

The Operator role allows principals to perform the following actions within the specified scope:

• View topics through the Confluent Cloud Console and Confluent CLI, but cannot produce or consume messages
• Monitor the health of applications and clusters, including monitoring uptime
• Full access to stream lineage views

MetricsViewer

The MetricsViewer role is intended to allow service accounts to access the Confluent Cloud Metrics in order to integrate with customer metrics platforms. It is not recommended to grant this role to users. For users who want interactive access to metrics, use the Operator role. Principals granted the MetricsViewer role in Confluent Cloud have the following access permissions:

• Access to the Confluent Cloud Metrics is applied at the Organization, Environment, or Cluster scope.
• Can import metrics into third-party metrics platforms
• Full access to stream lineage views

For details about how to assign the MetricsViewer role binding to a service account, see Add the MetricsViewer role to a new service account in the Confluent Cloud Console.

ResourceOwner

Principals granted the ResourceOwner role in Confluent Cloud have the following access permissions for the specified resource (topic, schema subject, consumer group, or transactional ID):

• Read and write access to the resource
• Grant and revoke RBAC access permissions for existing service accounts. To create service accounts, you must be granted the OrganizationAdmin.
• Create and delete the resource
• Change the configuration of the resource
• Manage RBAC permissions on the resource. The ResourceOwner role cannot manage ACLs.
• No access to stream lineage views
• For temporary limitations that you should be aware of, review Role limitations by resource.

You can restrict the scope of the access permissions to:

• a specified resource
• all resources of a specific type whose names start with a given prefix
• all resources of a specific type

DeveloperManage

Principals granted the DeveloperManage role in Confluent Cloud have the following access permissions for the specified resource (topic, consumer group, or transactional ID):

• Create and delete the resource (with the exception of schema subjects)
• No access to read, modify, or delete schemas
• Can change global and subject level compatibility mode
• Cannot change the configuration of the resource. Updating the configuration requires the CloudClusterAdmin.
• Cannot manage access to the resource
• No access to stream lineage views
• For temporary limitations that you should be aware of, review Role limitations by resource.

You can restrict the scope of the access permissions to:

• a specified resource
• all resources of a specific type whose names start with a given prefix
• all resources of a specific type

DeveloperRead

Principals granted the DeveloperRead role in Confluent Cloud have the following access permissions for the specified resource (topic, schema subject, consumer group, or transactional ID):

• Read-only access to the resource
  • When granted read-only access on a topic, read permission is also required on on a consumer group in order to subscribe to the topic. This is not necessary if the consumer does manual partition assignment. See also: Consumer groups.
  • When consuming from a topic using the Confluent CLI, the CLI will choose a consumer group name starting with confluent_cli_consumer_ by default, so the principal requires a DeveloperRead role binding on that prefix. Alternately, you can specify a consumer group with the --group flag and give a DeveloperRead role binding on your chosen group name. See confluent kafka topic consume.
• No access to stream lineage views
• For temporary limitations that you should be aware of, review Role limitations by resource.

You can restrict the scope of the access permissions to:

• a specified resource
• all resources of a specific type whose names start with a given prefix
• all resources of a specific type

DeveloperWrite

Principals granted the DeveloperWrite role in Confluent Cloud have the following access permissions for the specified resource (topic, schema subject, consumer group, or transactional ID):

• Write-only access to the resource
• No access to stream lineage views
• For temporary limitations that you should be aware of, review Role limitations by resource.

You can restrict the scope of the access permissions to:

• a specified resource
• all resources of a specific type whose names start with a given prefix
• all resources of a specific type

DataDiscovery

The DataDiscovery role grants access permissions specific to Schema Registry, Stream Catalog, and Stream Lineage resources. For Stream Catalog, tags and business metadata can apply to a schema, record, field, or topic. Principals granted the DataDiscovery role in Confluent Cloud have the following access permissions on Schema Registry subjects, schema compatibility, and Stream Catalog business metadata:

• Read access to all schema subjects within an environment
• Read access to Schema Registry compatibility
• Read access to Stream Catalog tags and business metadata within an environment
• Read access to Stream Catalog search (permissions to search the catalog)
• Read access to stream lineage views
• View access to all topics within an environment
• No access to data being produced or consumed within a topic

DataSteward

The DataSteward role grants access permissions specific to Schema Registry, Stream Catalog, and Stream Lineage resources. For Stream Catalog, tags and business metadata can apply to a schema, record, field, or topic. Principals granted the DataSteward role in Confluent Cloud have the following access permissions on Schema Registry subjects, schema compatibility, and Stream Catalog business metadata:

• Read, write (create or evolve schema) access to all schema subjects within an environment
• Can delete schema subject
• Read, write access to Schema Registry compatibility
• Can create, manage, read, write, and delete Stream Catalog business metadata
• Can create, manage, read, write, and delete tags
• Read access to Stream Catalog metadata
• Read access to Stream Catalog search (permissions to search the catalog)
• Read access to stream lineage views
• View access to all topics within an environment
• No access to data being produced or consumed within a topic

KsqlAdmin

The KsqlAdmin role grants access permissions to a specific ksqlDB cluster. Also, a KsqlAdmin can view the associated Organization, Environment, Kafka Cluster but not their resources.

Principals granted the KsqlAdmin role have the following access permissions on the ksqlDB cluster:

• List the cluster
• Terminate the cluster
• Create, manage, read, write, and delete ksqlDB streams, tables, and queries

For more information, see Grant Role-Based Access to ksqlDB on Confluent Cloud.

Manage RBAC using Confluent Cloud Console

Add a user account

Any administration user in an organization can invite other users to join by clicking + Add user while in the User accounts tab.

When inviting new users, you are prompted to specify roles for them. You are not required to grant a role when inviting another user, and you can grant 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 Console. You cannot grant a role that is broader in scope than the roles that you have. For example, a principal with the EnvironmentAdmin role cannot grant someone else the OrganizationAdmin role, and a principal granted the CloudClusterAdmin role on one cluster cannot grant another user the CloudClusterAdmin role on a different cluster.

Important

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 grant that user multiple roles at the same time. Note that when granting any role (except OrganizationAdmin and MetricsViewer), you must also specify the resource and the scope (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.

Delete a user account

To remove a user account from an organization, you must be granted the OrganizationAdmin role.

To delete a user account from an organization:

1. In the Confluent Cloud Console, go to Administration > Accounts & access.
2. Select the user account to delete from the organization, and click Remove from organization.
3. In the Delete user, enter the user’s name and click Confirm. Note that deleting a user account also deletes all of their role bindings and any associated API keys.

View and manage role bindings

The Confluent Cloud Console enables you to manage role bindings from two different points of view:

• By permissions for principals
• By permissions on resources

For example, when someone new joins the team, you might want to grant them a number of different permissions. Or, when you set up a new cluster, you might want to grant permission on it to a number of different users. This section provides details about these two approaches, and explains the tasks associated with viewing and managing RBAC role bindings in Confluent Cloud, which includes:

• View user and service accounts in an organization
• View role bindings
• Add a role binding
• Remove a role binding

Note

In the navigation menu, 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. Grayed-out text for individual resources indicates that the selected principal has no role bindings on the selected resource.

View user and service accounts in an organization

To view all user or service accounts in an organization:

1. Open the Confluent Cloud Console and go to Administration > Accounts & access. The Accounts tab opens, displaying User accounts by default. Click Service accounts to view all service accounts in the organization. All accounts are listed, even if there are no roles are assigned.

View role bindings

There are two views for role bindings in Accounts & access:

• Accounts tab: use to view what role bindings exist for a particular user or service account.
• Access tab: use to view what role bindings exist for a particular resource.

To view the role bindings for all user or service accounts in an organization:

1. In the Confluent Cloud Console, go to Administration > Accounts & access. The User accounts tab is displayed by default. For service accounts, click Service accounts.
2. Click the Access tab to view the role bindings for all user or service accounts in your organization. Expand the navigation tree to see explicit role bindings for any environment, cluster, Kafka resource in the organization.

To view the role bindings for a specific user account, 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 Service accounts tab, click the service account for which you wish to view role bindings, then click the Access tab. Expand the navigation tree to view the service account’s role bindings for each resource.

Note

In Accounts & access you may notice that there are two different Access tabs:

• Before you select a user, the first Access tab shows the role bindings for all users.
• After you’ve selected a user, the next Access tab shows the role bindings for the selected user only.

Add a role binding

You can add RBAC role bindings to any principal (user or service account).

To add a role binding for a user or service account:

1. In the Confluent Cloud Console, go to Administration > Accounts & access and select the user or service account that you want to add the role binding to. The User accounts tab is displayed by default. For service accounts, click Service accounts.

2. Select the user or service account you want to add a role binding to.

3. Click the Access tab. Select the organization, environment, cluster, or Kafka resource for which to create the role binding, and click +Add role assignment.

   Note

   When you click the Access tab for a user or service account, you can see all roles assigned to that account 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. To correctly identify all accounts with access to a cluster, be sure to include all accounts with an admin role in the organization and environment.

   Also, note that users assigned the EnvironmentAdmin role in one environment cannot view accounts or resources in a different environment.

4. Select the role binding you want to add and click Save. When subsequently viewing the Access tab for this account, the resources where this role binding was added appear in boldface type.

Remove a role binding

To remove a role binding for a principal (user or service account):

1. Navigate to Administration > Accounts & access and select the user or service account to remove the role binding, then click the Access tab. User accounts show by default. For a service account, click Service accounts.
2. Place your cursor over the name of the role to delete, and then click the trash can icon.
3. Confirm the role binding removal by entering the resource name and then click Delete.

View and manage resource access

This section explains how to perform the tasks associated with viewing and managing resources in Confluent Cloud cluster RBAC, which includes:

• View resources
• View role bindings on resources
• Add a role binding to a resource
• Remove a role binding from a resource

See also: Add the MetricsViewer role to a new service account in the Confluent Cloud Console.

Note

In the navigation tree, boldface text indicates that the navigation tree node you are viewing is expandable and includes 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.

View resources

You can view all Confluent Cloud resources in the same place. Resources in the scope of Confluent Cloud RBAC include:

• Organizations
• Environments
• Clusters
• ksqlDB clusters
• Schema Registry clusters
• Connectors
• Topics
• Consumer groups
• Transactional IDs

To view all resources to which your user account has access, navigate to Administration > Accounts & access and click the Access tab.

For a summary list of resources with RBAC support, see RBAC and Resources per Component.

View role bindings on resources

To view which user and service accounts have been granted role bindings on specific resources:

1. Navigate to Administration > Accounts & access and click the Access tab. All resources are displayed.
2. Click the environment, cluster, or Kafka resource to view all accounts assigned a role to the resource.

Add a role binding to a resource

To add a role binding to a resource:

1. Navigate to Administration > Accounts & access and click the Access tab.
2. Select the resource for which to add a role binding, and click +Add role assignment. The Confluent Cloud user interface displays the role available for the selected resource.
3. Click Save.

Remove a role binding from a resource

To remove a role binding from a resource:

1. Navigate to Administration > Accounts & access and click the Access tab.
2. Select the resource from which to remove the role binding. In the list of names shown, place your cursor over the name of the user whose access you want to remove, then click the trash can icon.
3. Confirm the role binding removal by entering the resource name and clicking Delete.

Manage RBAC using the Confluent CLI

You must have the Confluent CLI installed.

Identify principals with access to specific resources

Before assigning roles, you might want to first identify which principals have access to specific resources.

To list all environments:

confluent 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

Important

When you create, delete, or list role bindings on a Kafka resource (using --resource), you must include both the Kafka cluster (using --kafka-cluster-id) and the containing Confluent Cloud cluster (using --cloud-cluster).

To list all users with the role DeveloperRead for the resource Topic:connect-config in the Kafka cluster lkc-zyxmz:

confluent iam rbac role-binding list  --role DeveloperRead --kafka-cluster-id lkc-xyxmz --cloud-cluster lkc-xyxmz --environment env-nx5jd --resource Topic:connect-config
    Principal   |    Email
------------------------------------
  User:u-dk33dx | fred@acme.com
  User:u-7naodk | jane@acme.com

To list all Kafka clusters:

confluent 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:

confluent iam user list

  Resource ID |              Email              | First Name | Last Name | Status
+-------------+---------------------------------+------------+-----------+--------+
  u-l772kw    | fred@acme.com                   | Fred       | Jones     | Active
  u-l772dp    | jane@acme.com                   | Jane       | Smith     | Active

To list all service accounts (and locate the service account resource ID for role bindings):

confluent iam 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 u-a01bcd:

confluent iam user describe u-a01bcd


+-------------+---------------------------------+
| Resource ID | u-a01bcd                        |
| Email       | mariad@acme.com                 |
| First Name  | Maria                           |
| Last Name   | Developer                       |
| Status      | Active                          |
+-------------+---------------------------------+

To list all role bindings that grant the OrganizationAdmin role:

confluent iam rbac role-binding list --role OrganizationAdmin

 Principal
+---------------+
User:u-4321xy
User:u-1wx2yz
User:u-e01ef2
User:u-e0ab12
User:u-l00abc
User:u-l12ab2
User:u-l34d02

Create role bindings

To grant the role CloudClusterAdmin to the principal User:u-e03vqq in the environment env-nx5jd for the Kafka cluster lkc-xyxmz:

confluent iam rbac role-binding 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 role ResourceOwner to the principal User:u-e03vqq, in the environment env-nx5jd for the Kafka cluster lkc-xyxmz on the resource Topic:connect-config:

confluent iam rbac role-binding create --principal User:u-e03vqq --role ResourceOwner \
  --environment env-nx5jd --cloud-cluster lkc-xyxmz --kafka-cluster-id lkc-xyxmz \
  --resource Topic:connect-config
+----------------+----------------+
| Principal      | User:u-e03vqq  |
| Email          |                |
| Role           | ResourceOwner  |
| Environment    |                |
| CloudCluster   |                |
| ClusterType    |                |
| LogicalCluster |                |
| ResourceType   | Topic          |
| Name           | connect-config |
| PatternType    | LITERAL        |
+----------------+----------------+

Important

When you create, delete, or list role bindings on a Kafka resource (using --resource), you must include both the Kafka cluster (using --kafka-cluster-id) and the containing Confluent Cloud cluster (using --cloud-cluster).

To grant the role MetricsViewer to the principal sa-zm6vgz, a service account:

confluent iam rbac role-binding create --role MetricsViewer --principal User:sa-zm6vgz
+--------------+----------------+
| Principal    | User:sa-zm6vgz |
| Role         | MetricsViewer  |
| ResourceType | Cluster        |
+--------------+----------------+

To view the role bindings for a specific user account:

confluent iam rbac role-binding 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 confluent iam commands.

To grant the role ResourceOwner to the principal User:u-jw60zp to all subjects in the environment env-8vry97 for the Schema Registry lsrc-8g9k7m:

confluent iam rbac role-binding create --principal User:u-jw60zp --role ResourceOwner --environment env-8vry97 --schema-registry-cluster-id lsrc-8g9k7m --resource Subject:*


+------------------+----------------+
| Principal        | User:u-jw60zp  |
| Email            |                |
| Role             | ResourceOwner  |
| Environment      |                |
| CloudCluster     |                |
| ClusterType      |                |
| LogicalCluster   |                |
| ResourceType     | Subject        |
| Name             | *              |
| PatternType      | LITERAL        |
+------------------+----------------+

To grant the role ResourceOwner to the principal User:u-jw60zp to all subjects in the schema context schema_context in the environment env-8vry97 for the Schema Registry lsrc-8g9k7m:

confluent iam rbac role-binding create --principal User:u-jw60zp --role ResourceOwner --environment env-8vry97 --schema-registry-cluster-id lsrc-8g9k7m --resource Subject::.schema_context:*


+------------------+----------------------+
| Principal        | User:u-jw60zp        |
| Email            |                      |
| Role             | ResourceOwner        |
| Environment      |                      |
| CloudCluster     |                      |
| ClusterType      |                      |
| LogicalCluster   |                      |
| ResourceType     | Subject              |
| Name             | :.schema_context:*   |
| PatternType      | LITERAL              |
+------------------+----------------------+

Delete a role binding

To remove the role ResourceOwner for the resource Topic:connect-config on the Kafka cluster lkc-xyxmz:

Important

When you create, delete, or list role bindings on a Kafka resource (using --resource), you must include both the Kafka cluster (using --kafka-cluster-id) and the containing Confluent Cloud cluster (using --cloud-cluster).

confluent iam rbac role-binding delete --principal User:u-e03vqq --role ResourceOwner \
 --environment env-nx5jd --cloud-cluster lkc-xyxmz --kafka-cluster-id lkc-xyxmz \
 --resource Topic:connect-config
+----------------+----------------+
| Principal      | User:u-e03vqq  |
| Email          |                |
| Role           | ResourceOwner  |
| Environment    |                |
| CloudCluster   |                |
| ClusterType    |                |
| LogicalCluster |                |
| ResourceType   | Topic          |
| Name           | connect-config |
| PatternType    | LITERAL        |
+----------------+----------------+

Manage Confluent Cloud RBAC using the Confluent Cloud API

In addition to using the Confluent Cloud Console and Confluent CLI, you can also manage RBAC using the Confluent Cloud APIs.

Add a topic role binding

To add a role binding to a topic:

curl --request POST \
    --url https://api.confluent.cloud/iam/v2/role-bindings \
    --header 'Authorization: Basic TOKEN' \
    --header 'content-type: application/json' \
    --data '{"principal":"User:u-xyz789","role_name":"DeveloperRead", \
    "crn_pattern":"crn://confluent.cloud/organization=12345678-9012-3ab4-56cd-e78901234567/ \
    environment=env-abc123/cloud-cluster=lkc-def456/kafka=lkc-def456/topic=my-topic"}'

Abridged Response:

    {
       "api_version": "iam/v2",
       "kind": "RoleBinding",
       "id": "rb-klm456",
       "principal": "User:u-xyz789",
       "role_name": "DeveloperRead"
       ...
    }

RBAC and Resources per Component

For details on RBAC for specific Confluent Cloud components and resources, see the following sections.

Component	Documentation Section
Cluster Linking	Manage Security for Cluster Linking on Confluent Cloud
Connect	Role-Based Access Control for Managed Connectors on Confluent Cloud
Schema Linking	Role-Based Access Control for Schema Linking
Schema Registry	Role-Based Access Control for Schema Registry on Confluent Cloud
Stream Catalog	Role-Based Access Control for Stream Catalog
Stream Lineage	Role-Based Access Control for Stream Lineage
Stream Designer	Role-Based Access Control for PIpelines With Stream Designer on Confluent Cloud
ksqlDB	Role-Based Access Control for ksqlDB

Suggested reading

• Introducing Cluster Authorization Using RBAC, Audit Logs, and BYOK for Enterprise-Grade Security