Predefined RBAC roles in 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

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.

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. To grant the FlinkDeveloper role on a compute pool, you must currently use the 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.

Operator

The Operator role cannot access ksqlDB clusters and cannot view any information related to ksqlDB clusters.

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

  • Alter, Create, Delete, or Invite user accounts within their organization.
  • Alter, Create, or Delete service accounts within their organization.
  • 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.

Usage examples

  • Create a dedicated account administrator for user and service accounts.
  • 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 query
  • 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 SQL statement, assigning the MarcusProjectSA service account to run it.

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

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

DataSteward

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

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

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
  • 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 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 in Confluent Cloud.

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

  • Grant and revoke access within their environment.
  • Grant and revoke access RBAC permissions for existing service accounts. To create service accounts, you must be granted the OrganizationAdmin.
  • Invite users.
  • Enable or disable Schema Registry and manage schemas.
  • Create and manage clusters.
  • Manage cluster networking configurations for all clusters.
  • Create and manage Kafka resources, including topics, consumer groups, and transactional IDs.
  • Manage all Flink resources within the environment, including creating and managing compute pools, and creating and running 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.

  • Create and run 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

    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 SQL workspaces in the environment.

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

FlinkDeveloper

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

The FlinkDeveloper role can perform the following operations:

  • Create and run SQL statements using the specified compute pool or, if the role is bound to the environment, create and run Flink statements using 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.

    Important

    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 statements that are running on the specified compute pool or, if the role is bound to the environment, stop Flink statements that are running on any compute pool in the environment.

  • Create SQL workspaces in the environment.

  • View, alter, or delete 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:

  • Read-only (or “viewer”) access to everything within the specified organization, environment, or cluster with the exception of listing schema subjects. Subject names and associated metadata will still be available to EnvironmentOperator through the GraphQL APIs or searches on the Confluent Cloud Console. To learn more about RBAC and Schema Registry, see Access control (RBAC) for Confluent Cloud Schema Registry.
  • 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 Limitations.

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

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, 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.
  • 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.
  • Manage all Flink resources within the environment, including creating and managing compute pools, and creating and running 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.

Note

To delete a user or service account, you must have a role binding with the OrganizationAdmin or AccountAdmin 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.

ResourceKeyAdmin

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

The ResourceKeyAdmin role grants permissions for the following operations:

  • Alter, Create, Delete, and Describe resource API keys for a Kafka, Schema Registry, 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.
  • 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, or all resources of a specific type.