<a id="cloud-rbac-roles"></a>

<a id="predefined-rbac-roles"></a>

# 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](../../../_glossary.md#term-principal) can be assigned multiple roles. Note the
following:

* When SSO is enabled for an organization, a default [group mapping](../../../_glossary.md#term-group-mapping) (`all-sso-users`)
  is applied to all SSO user accounts and binds them to two predefined RBAC roles
  ([FlinkDeveloper](#flinkdeveloper-role) and [DataDiscovery](#datadiscovery-role))
  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](../../authenticate/user-identities/user-accounts/manage-sso-user-accounts.md#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, Dedicated, and Freight 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.

<a id="cloud-rbac-limitations"></a>

## 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](#operator-role)
  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](../../authenticate/workload-identities/service-accounts/api-keys/best-practices-api-keys.md#cleaning-up-api-keys).

**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](../../../_glossary.md#term-principal) [granular](../../../_glossary.md#term-granularity)
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](manage-role-bindings.md#manage-rbac-role-bindings).

### Role categories

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

#### Administration roles

* [AccountAdmin](#accountadmin-role)
* [BillingAdmin](#billingadmin-role)
* [CloudClusterAdmin](#cloudclusteradmin-role)
* [ConnectManager](#connectmanager-role)
* [DataSteward](#datasteward-role)
* [EnvironmentAdmin](#environmentadmin-role)
* [FlinkAdmin](#flinkadmin-role)
* [KsqlAdmin](#ksqladmin-role)
* [NetworkAdmin](#networkadmin-role)
* [OrganizationAdmin](#organizationadmin-role)
* [ResourceKeyAdmin](#resourcekeyadmin-role)
* [ResourceOwner](#resourceowner-role)

#### Application development roles

* [DeveloperManage](#developermanage-role)
* [DeveloperRead](#developerread-role)
* [DeveloperWrite](#developerwrite-role)
* [FlinkDeveloper](#flinkdeveloper-role)
* [FlinkFunctionDeveloper](#flinkfunctiondeveloper-role)
* [MetricsViewer](#metricsviewer-role)
* [Operator](#operator-role)
* [ResourceOwner](#resourceowner-role)

---

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

<a id="accountadmin-role"></a>

### 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.
* Alter, Create, Delete, and Describe operations for [identity pool](../../authenticate/workload-identities/identity-providers/oauth/identity-pools.md#add-oauth-identity-pools)
  (`IdentityPool`) and [group mapping](../../authenticate/user-identities/user-idps/sso/group-mapping/overview.md#group-mapping) (`GroupMapping`)
  resources.
* 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](#organizationadmin-role)), 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.

<a id="assigner-role"></a>

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

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

<a id="billingadmin-role"></a>

### 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)](https://docs.confluent.io/cloud/current/ccloud/costs-billing-v-1/).
- 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**.

<a id="cloudclusteradmin-role"></a>

### CloudClusterAdmin

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

- Full access to manage the specified cluster.
- Cannot view [Data portal](../../../stream-governance/data-portal.md#stream-gov-data-portal) or resources in the [Global search](../../../stream-governance/stream-catalog.md#catalog-global-search) bar on the Cloud Console UI.
- 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](#cloud-rbac-limitations).

The CloudClusterAdmin role allows principals to perform the following actions
within clusters specified for the role and for service accounts in the organization:

- Grant and revoke access within the cluster.
- Full access to manage access control lists (ACLs) for the cluster.
- Service accounts: Create and Describe (list and view).
- Identity pools (OAuth and certificate): Create and Describe (list and view).
- Invite users.
- Create and configure ksqlDB clusters.
- Create and configure connectors.
- Create, view, update, and list [connections](../../../integrations/connections/overview.md#connections-overview) to
  external services.
- View and manipulate topics through the Confluent Cloud Console and Confluent CLI.
- Create and manage Kafka resources, including topics, consumer groups, and transactional IDs.
- Reset consumer offsets. For more information, see [Reset Consumer Offsets in Confluent Cloud](../../../client-apps/offsets-consumer.md#offset-consumer-manage).
- Assign role bindings on Kafka resources, including topics, consumer groups, and transactional IDs,
  on  Standard, Enterprise, Dedicated, and Freight Kafka clusters, but not on Basic Kafka clusters.
- For [AI model inference for Apache Flink](../../../ai/ai-model-inference.md#flink-sql-ai-model), create,
  drop, list, and describe models, invoke models for prediction, and grant
  permissions on models. Also, see [RBAC for model inference](../../../ai/confluent-intelligence/overview.md#ai-model-inference-rbac).
- No access to view or manage cluster networking configurations.
- No access to view or manage schema subjects.

<a id="connectmanager-role"></a>

### ConnectManager

Principals granted the ConnectManager role on a connector have the following
permissions:

Connector Operations

- View and describe connector details.
- Pause, restart, and resume connector operations.
- Read the configuration for the connector.

Monitoring

- Monitor connector status and throughput metrics.
- View the cluster containing the connector.

<a id="datadiscovery-role"></a>

### 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](../../../_glossary.md#term-Schema-Registry),
[Stream Catalog](../../../_glossary.md#term-Stream-Catalog), and [Stream Lineage](../../../_glossary.md#term-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](../../authenticate/user-identities/user-accounts/manage-sso-user-accounts.md#default-user-permissions).

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

Allowed operations for [Schema Registry](../../../sr/index.md#schemaregistry-intro) include:

- Read access to all [schema subjects](/platform/current/schema-registry/index.html#schemas-subjects-and-topics)
  within an organization or environment.
- Read access to [schema compatibility](/cloud/current/sr/fundamentals/schema-evolution.html#schema-evolution-and-compatibility)
- For more RBAC details, see [Access control (RBAC) for Confluent Cloud Schema Registry](../../../sr/schemas-manage.md#cloud-sr-rbac).

Allowed operations for [Stream Catalog](../../../stream-governance/stream-catalog.md#cloud-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](../../../stream-governance/stream-catalog.md#data-discovery-search).
- For more RBAC details, see [Access control (RBAC) for Stream Catalog](../../../stream-governance/stream-catalog.md#stream-catalog-rbac) and [Stream Catalog business metadata](../../../stream-governance/stream-catalog.md#stream-catalog-rbac):

Allowed operations for [Stream Lineage](../../../stream-governance/stream-lineage.md#cloud-stream-lineage):

- Read access to Stream Lineage views.
- For more RBAC details, see [Access control (RBAC) for Stream Lineage](../../../stream-governance/stream-lineage.md#stream-lineage-rbac).

Allowed operations for Flink [compute pools](../../../flink/concepts/compute-pools.md#flink-sql-compute-pools):

- View compute pools, but not the statements they contain.

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.

#### IMPORTANT
When the DataDiscovery role is assigned to Kafka Streams applications, metadata
for all topics is retrieved, potentially leading to an increase in network traffic.
This is because the role grants view access to all topics within an environment,
which requires metadata retrieval across the cluster.

<a id="datasteward-role"></a>

### DataSteward

The DataSteward role grants access permissions specific to [Schema Registry](../../../sr/schemas-manage.md#cloud-sr-rbac),
[Stream Catalog](../../../stream-governance/stream-catalog.md#stream-catalog-rbac), and [Stream Lineage](../../../stream-governance/stream-lineage.md#stream-lineage-rbac) resources.
For [Stream Catalog](../../../stream-governance/stream-catalog.md#cloud-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](/platform/current/schema-registry/index.html#schemas-subjects-and-topics),
[schema compatibility](/cloud/current/sr/fundamentals/schema-evolution.html#schema-evolution-and-compatibility),
and [Stream Catalog business metadata](../../../stream-governance/stream-catalog.md#stream-catalog-rbac):

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

#### IMPORTANT
When the DataSteward role is assigned to Kafka Streams applications, metadata
for all topics is retrieved, potentially leading to an increase in network traffic.
This is because the role grants view access to all topics within an environment,
which requires metadata retrieval across the cluster.

<a id="developermanage-role"></a>

### 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.
- Can delete consumer groups and consumer offsets.
- For [AI model inference for Apache Flink](../../../ai/ai-model-inference.md#flink-sql-ai-model), create,
  drop, list, and describe models. Also, see [RBAC for model inference](../../../ai/confluent-intelligence/overview.md#ai-model-inference-rbac).
- Cannot view [Data portal](../../../stream-governance/data-portal.md#stream-gov-data-portal) or resources in the [Global search](../../../stream-governance/stream-catalog.md#catalog-global-search) bar on the Cloud Console.
- Cannot change the configuration of the resource. Updating the configuration
  requires the [CloudClusterAdmin](#cloudclusteradmin-role).
- Cannot manage access to the resource.
- No access to Stream Lineage views.
- For temporary limitations that you should be aware of, review
  [Limitations](#cloud-rbac-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.

<a id="developerread-role"></a>

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

- For [AI model inference for Apache Flink](../../../ai/ai-model-inference.md#flink-sql-ai-model), list/describe models
  and invoke models for prediction. Also, see [RBAC for model inference](../../../ai/confluent-intelligence/overview.md#ai-model-inference-rbac).
- Read-only access to the resource
  - When granted read-only access on a topic, read permission is also required on
    a consumer group in order to subscribe to the topic. This is not necessary if the
    consumer does manual partition assignment.
  - 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](https://docs.confluent.io/confluent-cli/current/command-reference/kafka/topic/confluent_kafka_topic_consume.html).
- Cannot view [Data portal](../../../stream-governance/data-portal.md#stream-gov-data-portal) or resources in the [Global search](../../../stream-governance/stream-catalog.md#catalog-global-search) bar on the Cloud Console UI.
- No access to Stream Lineage views.
- Reset consumer offset when this role is scoped to the topic and consumer
  group. For more information, see [Reset Consumer Offsets in Confluent Cloud](../../../client-apps/offsets-consumer.md#offset-consumer-manage).
- For temporary limitations that you should be aware of, review
  [Limitations](#cloud-rbac-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.

<a id="developerwrite-role"></a>

### DeveloperWrite

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

- For [AI model inference for Apache Flink](../../../ai/ai-model-inference.md#flink-sql-ai-model), create and
  list/describe models, invoke models for prediction. Also, see
  [RBAC for model inference](../../../ai/confluent-intelligence/overview.md#ai-model-inference-rbac).
- Write-only access to the resource
- Cannot view [Data portal](../../../stream-governance/data-portal.md#stream-gov-data-portal) or resources in the [Global search](../../../stream-governance/stream-catalog.md#catalog-global-search) bar on the Cloud Console UI.
- Reset consumer offsets when scoped to both the topic and consumer group.
  For more information, see [Reset Consumer Offsets in Confluent Cloud](../../../client-apps/offsets-consumer.md#offset-consumer-manage).
- 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
- For temporary limitations that you should be aware of, review
  [Limitations](#cloud-rbac-limitations).

<a id="environmentadmin-role"></a>

### 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](../hierarchy/cloud-environments.md#cloud-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.
- Service accounts: Create and Describe (list and view).
- Identity pools (OAuth and certificate): Create and Describe (list and view).
- Create, describe, and delete BYOK keys.
- Create, view, update, and list [connections](../../../integrations/connections/overview.md#connections-overview) to
  external services.
- 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.
- Reset consumer offsets. For more information, see [Reset Consumer Offsets in Confluent Cloud](../../../client-apps/offsets-consumer.md#offset-consumer-manage).
- Manage all Flink resources within the environment, including creating and managing
  compute pools, and creating and running Flink SQL statements.
- For [AI model inference for Apache Flink](../../../ai/ai-model-inference.md#flink-sql-ai-model), create,
  drop, list, and describe models, invoke models for prediction, and grant
  permissions on models. Also, see [RBAC for model inference](../../../ai/confluent-intelligence/overview.md#ai-model-inference-rbac).
- 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, Dedicated, and Freight Kafka clusters, but not on Basic Kafka clusters.
- Full access to Stream Lineage views.
- Create and manage ksqlDB clusters.
- Create and manage connectors.

<a id="flinkadmin-role"></a>

### 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.
* Service accounts: Describe (list and view).
* Identity pools (OAuth and certificate): Describe (list and view).
* 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.
* Create, view, update, delete, and list artifacts in the environment.
* Create, view, delete, and list user defined functions in the environment.
* Create, view, update, and list [connections](../../../integrations/connections/overview.md#connections-overview) to
  external services.

<a id="flinkdeveloper-role"></a>

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

If bound to a [compute pool](../../../flink/concepts/compute-pools.md#flink-sql-compute-pools), the FlinkDeveloper
role controls access to the compute pool and access to all statements running
in the compute pool.

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](../../authenticate/user-identities/user-accounts/manage-sso-user-accounts.md#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.
* Create, view, update, and list [connections](../../../integrations/connections/overview.md#connections-overview) to
  external services.
* View, alter, or delete Flink SQL workspaces by the principal.
* Create, view, update, delete, and list artifacts in the environment.
* Create, view, delete, and list user defined functions in the environment.

If the FlinkDeveloper role is bound to a compute pool, it can perform the
following operations:

* Get and describe the compute pool, and create statements on the compute pool
  they are assigned to. It does not have permissions to create, delete, or
  modify the compute pool.
* Have visibility of statements running or previously run in the pool, like
  viewing metadata and SQL text.
* Control any action on these statements, like starting, stopping, resuming, and
  deleting.

<a id="flinkfunctiondeveloper-role"></a>

### FlinkFunctionDeveloper

The FlinkFunctionDeveloper role is an environment-level role that is optional
for Flink developers. Assign the FlinkFunctionDeveloper role when a developer
needs access to user-defined function (UDF) artifacts or external connectivity.
This role is separate from FlinkDeveloper because these resources are defined
at the environment level.

The FlinkFunctionDeveloper role can perform the following operations:

* Create, view, update, and list [connections](../../../integrations/connections/overview.md#connections-overview) to
  external services.
* Create, view, update, delete, and list artifacts in the environment.
* Create, view, delete, and list user-defined functions (UDFs) in the
  environment.

<a id="ksqladmin-role"></a>

### 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.
- Service accounts: Create and Describe (list and view).
- Identity pools (OAuth and certificate): Create and Describe (list and view).

For more information, see [Grant Role-Based Access to ksqlDB on Confluent Cloud](../../../ksqldb/ksqldb-ccloud-rbac.md#ksqldb-ccloud-rbac).

<a id="metricsviewer-role"></a>

### MetricsViewer

The MetricsViewer role is intended to allow service accounts to access the
[Confluent Cloud Metrics](../../../monitoring/metrics-api.md#metrics-api) in order to integrate with customer metrics platforms.
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](../../../monitoring/metrics-api.md#metrics-api) 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 [Create an API key to authenticate to the Metrics API](../../../monitoring/metrics-api.md#ccloud-add-metricsviewer-role-to-new-service-account).

<a id="networkadmin-role"></a>

### NetworkAdmin

The NetworkAdmin role enables network administrators to manage the lifecycle of
Confluent Cloud [networks](../../../networking/overview.md#cloud-networking) 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.

<a id="operator-role"></a>

### Operator

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

- Describe resources. This role can view basic information,
  or metadata, about the resources in the organization, including environments,
  clusters, connectors, topics, and consumer groups.
- Describe schema subjects through the [GraphQL APIs](../../../stream-governance/graphql.md#catalog-graphql) or searches on the
  [Confluent Cloud Console](../../../sr/schemas-manage.md#sr-prv). To learn more about RBAC and Schema Registry, see [Access control (RBAC) for Confluent Cloud Schema Registry](../../../sr/schemas-manage.md#cloud-sr-rbac).
- Describe [RBAC role bindings](manage-role-bindings.md) to resources.
- Describe topics and consumer groups, but cannot read the messages in the topics.
- Has metadata access to Flink tables, databases, and catalogs.
- Describe [API keys](../../authenticate/workload-identities/service-accounts/api-keys/overview.md#cloud-api-keys) (for Kafka, Schema Registry,
  Flink, and ksqlDB) that are not owned by the principal.
- Describe, Create, Alter, or Delete [API keys](../../authenticate/workload-identities/service-accounts/api-keys/overview.md#cloud-api-keys)
  (for Kafka, Schema Registry, Flink, and ksqlDB) that are owned by the principal.
- Describe 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.

<a id="organizationadmin-role"></a>

### 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).
- For [AI model inference for Apache Flink](../../../ai/ai-model-inference.md#flink-sql-ai-model), create,
  drop, list/describe models, invoke models for prediction, and grant
  permissions on models. Also, see [RBAC for model inference](../../../ai/confluent-intelligence/overview.md#ai-model-inference-rbac).
- 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.
- Manage SSO group mappings (Create, Update, Delete, Describe, and List). For details,
  see [Manage Group Mappings on Confluent Cloud](../../authenticate/user-identities/user-idps/sso/group-mapping/manage-group-mappings.md#manage-group-mappings).
- Invite and delete users. To delete a user or service account, you requires a
  role binding with the OrganizationAdmin or [AccountAdmin](#accountadmin-role) 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.
- Identity pools (OAuth and certificate): Create, describe (list and view), update (alter), and delete.
- Service accounts: Create, describe (list and view), update (alter), and delete.
- 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.
- Reset consumer offsets. For more information, see [Reset Consumer Offsets in Confluent Cloud](../../../client-apps/offsets-consumer.md#offset-consumer-manage).
- 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, Dedicated, and Freight Kafka clusters, but not on Basic Kafka clusters.
- Full access to Stream Lineage views.
- Create and manage ksqlDB clusters.
- Create and manage connectors.
- Create, view, update, and list [connections](../../../integrations/connections/overview.md#connections-overview) to
  external services.

#### Notification of new OrganizationAdmin role bindings

When a new [principal](../../../_glossary.md#term-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](../../../monitoring/audit-logging/event-methods/rbac.md#bindroleforprincipal-examples)
  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. Confluent Cloud audit logs are available only for organizations that have at
  least one Standard, Enterprise, Dedicated, or
  Freight cluster provisioned. Basic clusters don’t include
  audit logs.

<a id="resourcekeyadmin-role"></a>

### 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](#organizationadmin-role) 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.

<a id="resourceowner-role"></a>

### 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, service account, identity pool, provider integration, or group mapping:

- Create resources when the new resource name matches a literal, prefix, or
  wildcard expression in the role binding.
- Read and write access to the resource.
- For [AI model inference for Apache Flink](../../../ai/ai-model-inference.md#flink-sql-ai-model), create,
  drop, list, and describe models, invoke models for prediction, and grant
  permissions on models. Also, see [RBAC for model inference](../../../ai/confluent-intelligence/overview.md#ai-model-inference-rbac).
- Update, delete, and manage access on the target resource.
- Grant and revoke access permissions for the target resource.
- Change the configuration of the resource.
- Reset consumer offsets when scoped to both the topic and consumer group.
  For more information, see [Reset Consumer Offsets in Confluent Cloud](../../../client-apps/offsets-consumer.md#offset-consumer-manage).
- 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.
- For ResourceOwner on a service account, create, describe, update, and delete API keys tied to the service account. On the Cloud Console, these API keys can be managed from the [API keys page](https://confluent.cloud/settings/api-keys).
- No access to Stream Lineage views.
- Cannot view [Data portal](../../../stream-governance/data-portal.md#stream-gov-data-portal) or resources in the [Global search](../../../stream-governance/stream-catalog.md#catalog-global-search) bar on the Cloud Console UI.
- For temporary limitations that you should be aware of, review
  [Limitations](#cloud-rbac-limitations).

You can restrict the scope of the access permissions to a
specified resource. For some specified resources, you can restrict
the scope of the access permissions to all resources of a specific type
or all resources of a specific type with a given prefix based.

Principals granted the ResourceOwner role in Confluent Cloud also have the following
access permissions related to workload identities:

- Create service accounts, OAuth identity pools, certificate identity pools.
  After creating an identity, grant it permissions only on resources that the
  ResourceOwner owns, unless the ResourceOwner holds other roles
  that grant broader permissions.
- Cannot create or manage user accounts.

#### IMPORTANT
Because the ResourceOwner role on any resource grants the ability to create
identity resources, review your role bindings before assigning ResourceOwner to
avoid unintentionally granting broader privileges. If
you want a principal to manage only a specific existing identity, scope the
role binding to that identity. Be aware that the principal can still
create new identities.

For details, see [Manage Workload Identities](../../authenticate/workload-identities/manage-workload-identities.md#manage-workload-identities).

## Related content

* [Role-Based Access Control (overview)](overview.md#cloud-rbac)
* [Manage RBAC role bindings](manage-role-bindings.md#manage-rbac-role-bindings)
* [Manage Workload Identities](../../authenticate/workload-identities/manage-workload-identities.md#manage-workload-identities)
* [RBAC for components](manage-role-bindings.md#cloud-rbac-resources-per-components)
* [Use ACLs with RBAC](use-acls-with-rbac.md#using-acls-with-rbac)
* [Confluent Cloud Security: RBAC and ACL module](https://developer.confluent.io/learn-kafka/cloud-security/rbac-and-acls/) [Confluent Developer]

#### NOTE
Client-side field level encryption (CSFLE)

- Permissions for CSFLE are scoped to the KEK by name (`Kek:<kekName>`) on Schema Registry. You do not bind roles on DEKs.
- DEK encryption and decryption are governed by your cloud KMS IAM, not by Confluent Cloud RBAC.
- See [Use Client-Side Field Level Encryption in Confluent Cloud](../../encrypt/csfle/client-side.md#use-client-side-field-level-encryption) for setup and examples.