Predefined RBAC Roles on Confluent Cloud

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. A principal can be assigned multiple roles. Note the following:

  • When SSO is enabled for an organization, a default group mapping (all-sso-users) is applied to all SSO user accounts and binds them to two predefined RBAC roles (FlinkDeveloper and DataDiscovery) that provide default user permissions to access Confluent Cloud resources in an SSO-enabled organization. These default user permissions can be customized by administrators. For more information, see Default user permissions.
  • To use the Confluent Cloud Console or Confluent CLI, a user must be assigned at least one role.
  • To allow a principal to inspect topics and view messages using the Confluent Cloud Console, you must minimally grant that account the DeveloperRead role.
  • RBAC permissions for operations on granular Kafka resources (topics, consumer groups, and transactional IDs) are supported only on Standard, Enterprise, and Dedicated clusters.
  • If a user or service account is deleted, all API keys and role bindings associated with that user or service account are also deleted.

Limitations

Listed here are temporary limitations for Confluent Cloud resources and role bindings that you need to be aware of.

Consumers and producers

  • Any principal granted access to a Kafka 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 enable viewing consumers and producers, grant the Operator role.

  • If you remove role bindings for a principal with an Organization, Environment, or Cluster scope that includes ksqlDB resource access, the principal’s API keys are not automatically deleted. A principal 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.

FlinkDeveloper

  • To grant the FlinkDeveloper role on an environment, you can use the Confluent Cloud Console, Confluent CLI, or the REST API.

KsqlAdmin

  • Principals granted the KsqlAdmin role cannot create ksqlDB clusters, but can list and terminate the specific ksqlDB cluster the role is granted to. Principals with the KsqlAdmin role for a ksqlDB cluster has full access to all resources on the cluster, like streams and persistent queries.
  • The KsqlAdmin role can create API keys that can access the ksqlDB cluster 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 role bindings assigned to that cluster are deleted.
  • The KsqlAdmin role cannot grant access to a Kafka cluster or the ability to view Kafka ACLs or role bindings. Use other RBAC roles to grant access to Kafka clusters and resources.

Predefined roles

Use predefined RBAC roles to grant principals granular access permissions to specific Confluent Cloud resources. A predefined role is a Confluent-defined job function assigned a set of permissions required to perform specific operations on Confluent resources bound to a principal and Confluent resources. The roles are updated as necessary when new resources or features are added to Confluent Cloud.

When you assign a role to a principal, the role is bound to both the principal and the resources. For details about role bindings, see Manage RBAC role bindings on Confluent Cloud.

Role categories

To help you focus on the roles that are relevant to your needs, here are listings of roles by category:

Application development roles

The predefined RBAC roles available in Confluent Cloud are listed alphabetically.

AccountAdmin

Principals granted the AccountAdmin role can:

  • Describe, Create, Delete, or Invite user accounts within their organization. By itself, this role cannot view or alter the roles of other user accounts. To view or alter the roles of other user accounts, you must additionally be granted other roles.
  • Describe, Alter, Create, or Delete service accounts within their organization. By itself, this role cannot view or alter the roles of other service accounts. To view or alter the roles of other user accounts, you must additionally be granted other roles.
  • When combined with other role bindings, this role can manage the end-to-end provisioning of user and service accounts for Confluent Cloud resources they have access to. You can use the AccountAdmin role to create a dedicated account administrator for user and service accounts, but their access is limited based on the roles (other than AccountAdmin) that are granted to them.

Usage example

Instead of requiring the user with full access to all Confluent Cloud resources for your organization (OrganizationAdmin), you can grant someone managing one of your Kafka clusters the AccountAdmin role. This lets you create a dedicated account administrator for that cluster, who can manage the end-to-end provisioning of user and service accounts for that cluster, including inviting users, granting access, and creating service accounts. This delegation of responsibility can help you manage access to your resources more effectively while maintaining security.

The following table shows the operations that can be performed on user and service accounts by a principal with only the AccountAdmin role, only the CloudClusterAdmin role, or both roles combined. The effective permissions are the union of the permissions granted by the two roles.

Role User account Service account
AccountAdmin Create, Delete Alter, Create, Delete
CloudClusterAdmin Alter Access, Create, Describe, Invite Alter Access, Describe, Describe Access
Combined Alter, Alter Access, Create, Delete, Describe, Describe Access, Invite Alter, Alter Access, Create, Delete, Describe, Describe Access
  • Allow a cloud cluster administrator (with the CloudClusterAdmin role) to manage users and service accounts for their cluster.

Assigner

Principals granted the Assigner role can:

  • Assign a specific service account to perform a task within Confluent Cloud, such as executing a Flink SQL statement
  • View the metadata about a service account.

The Assigner role is bound on a specific service account using the specified ID or all service accounts when using a wildcard (*).

Usage example

  1. Marcus, an OrganizationAdmin, creates a service account called MarcusProjectSA.
  2. Marcus grants data access permissions to his new MarcusProjectSA service account.
  3. Marcus grants the Assigner role on his service account to Alice.
  4. Alice runs a Flink SQL statement, assigning the MarcusProjectSA service account to run it.

BillingAdmin

Principals granted the BillingAdmin role have the following access permissions:

  • View billing information: promotion code claims, invoices, and payment information (next scheduled payment and payment method).
  • Update billing information: promotion code claim, payment method, and email address.
  • View support plan information.
  • View resources in the organization without access to data.
  • Access the Costs API (billing/v1/costs).
  • Use the Confluent Cloud Console to perform any of the following actions:
    • View Monthly usage for selected month and year.
    • View Charges by environment for selected environment.
    • View or download invoices.
    • View and copy Cloud Organization ID.
    • View Payments, Next scheduled payment, Payment method, and Email address.
    • Update Payment method and Email address.

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.
  • Full access to manage access control lists (ACLs) for the cluster.
  • Grant and revoke access permissions for existing service accounts. To create service accounts, you must be granted the OrganizationAdmin or the AccountAdmin.
  • Invite users.
  • Create and configure ksqlDB clusters.
  • Create and configure connectors.
  • View and manipulate topics through the Confluent Cloud Console and Confluent CLI.
  • Create and manage Kafka resources, including topics, consumer groups, and transactional IDs.
  • Assign role bindings on Kafka resources, including topics, consumer groups, and transactional IDs, on Standard, Enterprise, and Dedicated Kafka clusters, but not on Basic Kafka clusters.
  • No access to view or manage cluster networking configurations.
  • No access to view or manage schema subjects.

DataDiscovery

The DataDiscovery role is intended for users who need to discover and understand data in Confluent Cloud, but do not need to manage or evolve schemas, or manage business metadata. This role grants access permissions specific to Schema Registry, Stream Catalog, and Stream Lineage resources.

All SSO user accounts are included in the default all-sso-users group mapping that binds them to the DataDiscovery and FlinkDeveloper roles and provides the users with default user permissions to access Confluent Cloud resources across any environments in an SSO-enabled organization. For more information, see Default user permissions.

Principals granted the DataDiscovery role in Confluent Cloud have the following access.

Allowed operations for Schema Registry include:

Allowed operations for Stream Catalog include:

  • Read access to Stream Catalog tags and business metadata within an organization or environment. Tags and business metadata can apply to schemas, records, fields, topics, connectors, clusters, environments, pipelines, and Apache Flink® compute pools.
  • Read access to Stream Catalog search. This allows searching on schemas, schema subjects, records, fields, topics, tags, connectors, clusters, environments, pipelines, and Flink compute pools. For details, see Search entities and tags.
  • For more RBAC details, see Access control (RBAC) for Stream Catalog and Stream Catalog business metadata:

Allowed operations for Stream Lineage:

To perform the operations above, the DataDiscovery role grants view access to all topics within all environments in an organization, but does not grant read access to any data being produced or consumed.

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.

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

You can restrict the scope of the access permissions to a specified resource, all resources of a specific type, or all resources of a specific type whose names start with a given prefix.

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

You can restrict the scope of the access permissions to a specified resource, all resources of a specific type, or all resources of a specific type whose names start with a given prefix.

DeveloperWrite

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

  • Write-only access to the resource
  • No access to Stream Lineage views

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

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 on 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.
  • Create, describe, and delete BYOK keys.
  • 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.
  • Manage all Flink resources within the environment, including creating and managing compute pools, and creating and running Flink SQL statements.
  • View the result sets of statements run with their own permissions or that were run using a service account on which the principal has the Assigner role.
  • Assign role bindings on Kafka resources, including topics, consumer groups, and transactional IDs, on Standard, Enterprise, and Dedicated Kafka clusters, but not on Basic Kafka clusters.
  • Full access to Stream Lineage views.
  • Create and manage ksqlDB clusters.
  • Create and manage connectors.

FlinkAdmin

The FlinkAdmin role allows full access to Flink resources in an environment. It should be given to users who will manage the compute pools used by Flink in an environment.

The FlinkAdmin role grants permissions for the following operations:

  • Manage compute pools in the environment, including creating, deleting, and altering their settings.

  • View and list user and service accounts in the organization.

  • Create and run Flink SQL statements using any compute pool in the environment.

  • View the result sets of statements run with their own permissions or that were run using a service account on which the principal has the Assigner role.

    Important

    Flink SQL statements are not private within an environment. All principals with FlinkDeveloper or FlinkAdmin role bindings can see any statements in plaintext. Confluent recommends creating a separate environment for users who run sensitive queries.

  • Stop or delete statements in the environment.

  • Create Flink SQL workspaces in the environment.

  • View, alter, or delete Flink SQL workspaces created by a principal.

FlinkDeveloper

The FlinkDeveloper role grants limited access to Flink resources in an organization or environment. You should grant this role to principals who run Flink statements, but do not manage compute pools.

All SSO user accounts are included in the default all-sso-users group mapping that binds them to the DataDiscovery and FlinkDeveloper roles and provides the users with default user permissions to access Confluent Cloud resources across any environments in an SSO-enabled organization. For more information, see Default user permissions.

The FlinkDeveloper role can perform the following operations:

  • If the role is bound to the environment, create and run Flink SQL statements using any compute pool in the environment.
  • If the role is bound to the environment, stop and delete Flink SQL statements that are running on any compute pool in the environment.
  • View the result sets of statements run with their own permissions or run using a service account that the principal has the Assigner role.
  • Create Flink SQL workspaces in the environment.
  • View, alter, or delete Flink SQL workspaces by the principal.

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.

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.

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 Enterprise and Dedicated Kafka 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:

  • Describe resources within the organization. This role can view basic information, or metadata, about the resources in the organization, including environments, clusters, connectors, topics, and consumer groups, but not including ksqlDB.
  • Describe topics and consumer groups, but not cannot read the messages in the topics.
  • Describe API keys (for Kafka, Schema Registry, Flink, and ksqlDB) that are not owned by the principal.
  • Describe, Create, Alter, or Delete API keys (for Kafka, Schema Registry, Flink, and ksqlDB) that are owned by the principal.
  • Describe, Pause, and Resume managed connectors.
  • Describe and view pipelines.
  • View Stream Lineage.
  • View metrics for clusters (Kafka, Schema Registry, and KSQL) and connectors. Monitor the health of applications and clusters, including monitoring uptime.

You can bind the Operator role to the organization, an environment, or a cluster.

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, compute pools, Flink SQL statements, Flink workspaces, 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.

    • Create, describe, and delete BYOK keys.

  • Invite and delete users. To delete a user or service account, you requires a role binding with the OrganizationAdmin or AccountAdmin role.

    You cannot remove your own OrganizationAdmin role binding. If you need 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 user account assigned the OrganizationAdmin role.

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

  • Manage all Flink resources within the environment, including creating and managing compute pools, and creating and running Flink SQL statements.

  • View the result sets of statements run with their own permissions or that were run using any service account.

  • Assign role bindings on Kafka resources, including topics, consumer groups, and transactional IDs, on Standard, Enterprise, and Dedicated Kafka clusters, but not on Basic Kafka clusters.

  • Full access to Stream Lineage views.

  • Create and manage ksqlDB clusters.

  • Create and manage connectors.

Notification of new OrganizationAdmin role bindings

When a new principal is granted the privileged OrganizationAdmin role binding, the following actions occur:

  • An email notification is sent to all users with the OrganizationAdmin role-binding in the organization informing them that a new principal has been granted the OrganizationAdmin role. This email alerts existing administrators in case the operation was unintended.
  • A Confluent Cloud audit log entry is added, triggered by the BindRoleForPrincipal auditable event method. Any user with the OrganizationAdmin role can review the log entry record to see the principal who granted the OrganizationAdmin role and the principal who received the role, and when the role binding was added. Note that Confluent Cloud audit logs are available only for Standard, Enterprise, and Dedicated clusters.

ResourceKeyAdmin

Principals granted the ResourceKeyAdmin role can manage API keys for Kafka, Schema Registry, and ksqlDB clusters across their organization for service accounts. Only the OrganizationAdmin can manage API keys for Confluent Cloud resources.

The ResourceKeyAdmin role grants permissions for the following operations:

  • Alter, Create, Delete, and Describe API keys resource-scoped to a Kafka cluster, Schema Registry cluster, Flink region, or ksqlDB cluster.

Note that the ResourceKeyAdmin role cannot create API keys for itself, but can create API keys for other service accounts.

ResourceOwner

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

  • 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 or AccountAdmin.
  • Create and delete the resource.
  • Change the configuration of the resource.
  • Manage RBAC permissions on the resource. The ResourceOwner role cannot manage ACLs.
  • Manage API keys for clusters (Kafka, Schema Registry, Flink, and ksqlDB) owned by the principal.
  • No access to Stream Lineage views.
  • Cannot view Data portal or resources in the Global search bar on the Cloud Console UI.
  • For temporary limitations that you should be aware of, review Limitations.

You can restrict the scope of the access permissions to a specified resource, all resources of a specific type, or all resources of a specific type whose names start with a given prefix, or all resources of a specific type.

Related content