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

Confluent Cloud role-based access control (RBAC) provides a method to control access to an organization, environment, cluster, or granular Kafka resources (topics, consumer groups, and transactional IDs) 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.

重要

For details about how RBAC impacts user and service accounts for existing organizations, refer to Recommendations for managing RBAC roles in existing organizations.

このトピックには、次の用語が使用されています。正しく理解しておくようにしてください。

制限¶

Confluent Cloud RBAC には、次の制限があります。

Granular Kafka RBAC is available only on Standard and Dedicated clusters.
Role bindings are limited to 1,000 per organization. If more are required, contact Confluent Support.
If a user account is deleted, both API keys and role bindings for that user are also deleted.
To create service accounts, you must be assigned the OrganizationAdmin role. All the other cluster administration roles (EnvironmentAdmin and CloudClusterAdmin) can grant or revoke permissions for existing service accounts on the resources that they control.
User and service accounts with DeveloperRead, DeveloperWrite, DeveloperManage, and ResourceOwner roles on resources within a Kafka cluster can see all of the Metrics within that cluster. We are actively working to block this access.
Any user with access to a resource in a cluster can see all of the consumers and producers of a cluster, regardless of which topic on the cluster the consumer consumes from. Engineering is actively working to block this access.
Some users might receive email notifications related to Connector create operations, even if they are not directly related to or involved in these operations. If a user receives a notification email message, they cannot access the connector unless they have been assigned the required roles. Engineering is working to resolve this issue.
For Confluent CLI, use the latest version (v. 2.8.1 or later).

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:

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

ロール	表示スコープ	管理スコープ
OrganizationAdmin	All	All
EnvironmentAdmin	組織、サポートプラン、ユーザー	環境、スキーマレジストリ、クラスターネットワーク内のすべてのクラスター
CloudClusterAdmin	組織、環境、サポートプラン、ユーザー、スキーマレジストリ	Specified Cluster, Topics, ksqlDB applicaitons, connectors, Schema Subjects
Operator	組織、環境、クラスター	該当なし
MetricsViewer	組織、環境、クラスター	該当なし
ResourceOwner	組織、環境、クラスター	Specified Resource (Topic, Consumer Group, or Transactional ID)
DeveloperManage	組織、環境、クラスター	Specified Resource (Topic, Consumer Group, or Transactional ID)
DeveloperRead	組織、環境、クラスター	Specified Resource (Topic, Consumer Group, or Transactional ID)
DeveloperWrite	組織、環境、クラスター	Specified Resource (Topic, Consumer Group, or Transactional ID)

重要

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 top-right Administation menu (☰) of the Confluent Cloud user interface. 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.

注意

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 assigned the OrganizationAdmin role have full access to manage all resources within an organization (including environments, clusters, topics, groups, transactional IDs, ksqlDB applications, connectors, schema registries, role bindings, and ACLs) in Confluent Cloud. 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.

Principals assigned the OrganizationAdmin role can:

Grant and revoke access throughout the organization
ユーザーの招待と削除
サービスアカウントの作成
請求の管理
サポートプランの管理
スキーマレジストリのセットアップ
環境の作成と管理
クラスターの作成と管理
すべての環境のすべてのクラスターに対するクラスターネットワーク構成の管理
Create and manage Kafka resources like topics, consumer groups, and transactional IDs
Full access to stream lineage views
Create and manage ksqlDB applications
Create and manage connectors

注釈

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 have full access to manage all resources for the specified environment. Principals granted this role cannot view or manage any environments or any resources in other environments in which they are not assigned a role.

環境を作成したりその名前を変更したりする方法の詳細については、「Environments」を参照してください。

Principals assigned the EnvironmentAdmin role can perform the following actions within the environment specified for the role:

Grant and revoke access within their environment
ユーザーの招待
スキーマレジストリのセットアップ
クラスターの作成と管理
Manage cluster networking configurations for all clusters
Create and manage Kafka resources like topics, consumer groups, and transactional IDs
Full access to stream lineage views
Create and manage ksqlDB applications
Create and manage connectors

CloudClusterAdmin¶

Principals granted the CloudClusterAdmin role have full access to manage the specified cluster. Principals granted the CloudClusterAdmin role cannot view or manage any other clusters, environments, or networking configurations for which they are not assigned a role.

Principals assigned the CloudClusterAdmin role can perform the following actions within clusters specified for the role:

Grant and revoke access within the cluster
ユーザーの招待
Create and configure ksqlDB applications
Create and configure connectors
既存のスキーマレジストリにあるスキーマの管理
Create and manage Kafka resources like topics, consumer groups, and transactional IDs
Full access to stream lineage views

Operator¶

Principals granted the Operator role have "read-only" or "viewer" access on everything within the specified organization, environment, or cluster. Operator is the only role that can be bound at multiple scopes (for example, on the entire organization, or a specific environment or cluster).

Principals assigned the Operator role can 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¶

Principals granted the MetricsViewer role can access the Confluent Cloud Metrics for all clusters in an organization. This role also allows user or service accounts to import metrics into third-party metrics platforms and fulle 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 have full access to the specified Kafka resource, including the ability to create and delete the resource, read data, write data, change configurations, and manage access on the resource. This role cannot access stream lineage views.

You can grant the ResourceOwner role on a single named resource, all resources of a specific type whose names start with a given prefix, or all resources of a specific type. The supported resource types are topic, consumer group, and transactional ID.

DeveloperManage¶

Principals granted the DeveloperManage role have access to create and delete the specified Kafka resource, and to change configurations for designated resources, but cannot manage access. This role cannot access stream lineage views.

You can grant the DeveloperManage role on a single named resource, all resources of a specific type whose names start with a given prefix, or all resources of a specific type. The supported resource types are topic, consumer group, and transactional ID.

DeveloperRead¶

Principals granted the DeveloperRead role have access to read data within the specified Kafka resource, but cannot manage access. This role cannot access stream lineage views.

You can grant the DeveloperRead role on a single named resource, all resources of a specific type whose names start with a given prefix, or all resources of a specific type. The supported types are topic, consumer group, and transactional ID.

DeveloperWrite¶

Principals granted the DeveloperWrite role have access to write data within the Kafka resource, but cannot manage access. This role cannot access stream lineage views.

You can grant the DeveloperWrite role on a single named resource, all resources of a specific type whose names start with a given prefix, or all resources of a specific type. The supported types are topic, consumer group, and transactional ID.

Manage RBAC using Confluent Cloud Console¶

Add a user account¶

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

重要

組織に参加するためには、"ユーザーは、既にその組織に存在する他のユーザーから招待してもらう必要があります"。同僚が confluent.io または confluent.cloud から Confluent Cloud へのサインアップを試み、同じ組織名をサインアップページで指定した場合、Confluent Cloud は、そのユーザーのサインアップ処理を行い、そのユーザーのために新しい組織を作成します。このユーザーは、意図した組織には表示 "されません"。

When adding a new user, you can assign that user multiple roles at the same time. Note that when assigning all roles except OrganizationAdmin and MetricsViewer, you must also specify the resource and the scope (cluster or environment name) for the role.

完了したら、Review をクリックし、入力したメールアドレスとロールの割り当てが正しいことを確認します。問題がなければ、Create をクリックします。

Delete a user account¶

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

To delete a user account from an organization:

In the Confluent Cloud Console, go to Administration > Accounts & access.
Select the user account to delete from the organization, and click Remove from organization.
In the Delete user, enter the user's name and click Confirm. Note that deleting a user 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:

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

注釈

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

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:

In the Confluent Cloud Console, go to Administration > Accounts & access. The User accounts tab is displayed by default. For service accounts, click Service accounts.
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.

注釈

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:

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.
Select the user or service account you want to add a role binding to.
Click the Access tab. Select the organization, environment, cluster, or Kafka resource for which to create the role binding, and click +Add role assignment.

注釈

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

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.
削除するロールの名前の上にカーソルを置き、ごみ箱アイコンをクリックします。
Confirm the role binding removal by entering the resource name and then click Delete.

View and manage resource access¶

このセクションでは、Confluent Cloud クラスターの RBAC におけるリソースの表示と管理に関連したタスクの実行方法について説明します。次のタスクについて取り上げます。

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

「Add the MetricsViewer role to a new service account in the Confluent Cloud Console」も参照してください。

注釈

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¶

Confluent Cloud のリソースはすべて同じ場所で表示できます。Confluent Cloud RBAC のスコープには、次のようなリソースがあります。

組織
環境
クラスター
ksqlDB applications
コネクター
トピック
コンシューマーグループ
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:

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

Add a role binding to a resource¶

リソースにロールバインディングを追加するには、次の手順に従います。

Navigate to Administration > Accounts & access and click the Access tab.
ロールバインディングを追加するリソースを選択し、+Add role assignment をクリックします。選択したリソースで利用できるロールが、Confluent Cloud のユーザーインターフェイスに表示されます。
Save をクリックします。

Remove a role binding from a resource¶

リソースからロールバインディングを削除するには、次の手順に従います。

Navigate to Administration > Accounts & access and click the Access tab.
ロールバインディングを削除するリソースを選択します。表示された名前の一覧で、アクセス権を削除するユーザーの名前の上にカーソルを置いて、ごみ箱アイコンをクリックします。
リソース名を入力し、Delete をクリックして、ロールバインディングの削除を確定します。

Manage RBAC using the Confluent CLI¶

Confluent CLI をインストールしておく必要があります。

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

重要

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 rolebinding 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

すべての Kafka クラスターを一覧表示するには、次のようにします。

confluent kafka cluster list

      Id      |   Name    |   Type    | Provider |  Region   | Availability | Status
+-------------+-----------+-----------+----------+-----------+--------------+--------+
    lkc-xyxmz | cluster_0 | STANDARD  | aws      | us-east-2 | single-zone  | UP

すべてのユーザーを一覧表示するには、次のようにします。

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

すべてのサービスアカウントを一覧表示（さらに、ロールバインディングに使用されるサービスアカウントのリソース ID を特定）するには、次のようにします。

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 rolebinding 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        |
+----------------+----------------+

重要

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:

重要

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

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

制限¶

Use ACLs with RBAC¶

Order of precedence¶

Confluent Cloud RBAC roles¶

OrganizationAdmin¶

EnvironmentAdmin¶

CloudClusterAdmin¶

Operator¶

MetricsViewer¶

ResourceOwner¶

DeveloperManage¶

DeveloperRead¶

DeveloperWrite¶

Manage RBAC using Confluent Cloud Console¶

Add a user account¶

Delete a user account¶

View and manage role bindings¶

View user and service accounts in an organization¶

View role bindings¶

Add a role binding¶

Remove a role binding¶

View and manage resource access¶

View resources¶

View role bindings on resources¶

Add a role binding to a resource¶

Remove a role binding from a resource¶

Manage RBAC using the Confluent CLI¶

Identify principals with access to specific resources¶

Create role bindings¶

Delete a role binding¶

Manage Confluent Cloud RBAC using the Confluent Cloud API¶

Add a topic role binding¶

Recommendations for managing RBAC roles in existing organizations¶

Suggested reading¶