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) 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.

Important

For details about the impact of RBAC on user and service accounts of existing organizations, see Recommendations for managing RBAC roles in existing organizations.

The following concepts are important to understand before using RBAC:

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.
  • Role bindings are limited to 1,000 per organization.
  • 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.
    • Any user granted the MetricsViewer role bound on a scope that includes a ksqlDB cluster has full access to queries within the ksqlDB cluster. This is subject to change and you must not rely on this access.
    • Any user granted the Operator role has no access to ksqlDB clusters and cannot see any information related to ksqlDB clusters.
  • Metrics
    • Any user granted access to a cluster, or resources within it, can see all of the metrics for the cluster. This is subject to change and you must not rely on this access. If metrics access is required by a service account, grant the the MetricsViewer role. If metrics access is required by a user account, grant the Operator role.
  • Schema Registry
    • If you remove role bindings for a user with an Organization or Environment scope that includes Schema Registry resource access, the user’s API keys are not automatically deleted. A user with an administrator role binding (OrganizationAdmin or EnvironmentAdmin) can create an API key for a Schema Registry 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 Schema Registry clusters. As a best practice, when you remove role bindings, make sure to remove any corresponding API keys.
    • Any user granted the CloudClusterAdmin or MetricsViewer role has full access to schema subjects in the environment where their role applies. This is subject to change and you must not rely on this behavior.
    • Any user granted the Operator role has no access to Schema Registry and cannot see any information related to Schema Registry.

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 role bindings for user and service accounts.
  • Both ACLs and role bindings that grant granular access to resources can now be used with service accounts.

Order of precedence

In Confluent Cloud, ACLs and RBAC 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, Schema Registry Specified Cluster, Topics, ksqlDB applications, Connectors, Schema Subjects
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, Consumer Group, or Transactional ID)
DeveloperManage Organization, Environment, Cluster Specified Resource (Topic, Consumer Group, or Transactional ID)
DeveloperRead Organization, Environment, Cluster Specified Resource (Topic, Consumer Group, Connector, or Transactional ID)
DeveloperWrite Organization, Environment, Cluster Specified Resource (Topic, Consumer Group, Connector, or Transactional ID)

Warning

Assigning the MetricsViewer role to users is strongly discouraged because these users have unrestricted access to ksqlDB clusters and Schema Registry. Users granted the MetricsViewer role can create and delete ksqlDB queries and Schema Registry subjects.

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.

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 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
  • Manage schemas in existing schema registries
  • View and manipulate topics through the Confluent Cloud Console and Confluent CLI
  • No access to view or manage cluster networking configurations

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
  • 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 for all clusters in an organization
  • Can import metrics into third-party metrics platforms
  • Full access to stream lineage views
  • For temporary limitations that you should be aware of, review Role limitations by resource.

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.

Warning

Assigning the MetricsViewer role to users is strongly discouraged because these users have unrestricted access to ksqlDB clusters and Schema Registry. Users granted the MetricsViewer role can create and delete ksqlDB queries and Schema Registry subjects.

ResourceOwner

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

  • Read and write access to the resource
  • Grant and revoke 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 permissions on 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

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
  • Change the configuration of the resource
  • 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, 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, 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

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 viewing the permissions for principals
  • By looking the 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:

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:

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
  • 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.

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 admin 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.

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"
       ...
    }

Recommendations for managing RBAC roles in existing organizations

With the introduction of Confluent Cloud RBAC, all existing principals with Confluent Cloud API keys were granted the OrganizationAdmin role in all existing organizations. Consequently, these principals were given the same access level to Confluent Cloud and the Confluent CLI that they previously had prior to the release of RBAC. Deleted user accounts and invited (pending) user accounts were not assigned any roles.

Unless OrganizationAdmin access is required, Confluent recommends that you downgrade principals from the OrganizationAdmin role. If a user requires access to inspect a cluster, or to use the Confluent Cloud Console to inspect topics and view messages in them, then grant that user account the CloudClusterAdmin role. If they only need access to specific topics, consider the ResourceOwner or Developer roles instead.