# Configure RBAC for Control Center on Confluent Platform
Control Center supports [Use Role-Based Access Control (RBAC) for Authorization in Confluent Platform](/platform/current/security/authorization/rbac/overview.html#rbac-overview) (role-based access control (RBAC)). As of Confluent Platform version 5.3 and
later, RBAC provides a fine-grained security model across the platform
in a development environment. Prior versions of Control Center only provided
coarse-grained access control of either read-only or full access.
If RBAC is not enabled, or Control Center is running against Confluent Platform versions prior
to 5.3 and later, Control Center functions as it has before without restricted
access (unless access control feature flags have been turned off
in the `control-center-properties` files). When RBAC is not enabled,
Access Control settings (referred to as feature flags) in Control Center
configuration options can remove access for the features that have those flags;
such as ksqlDB, License Manager, Schema Registry, topic inspections,
broker configurations, and more. For more information on those available settings,
see [Access control settings](../installation/configuration.md#controlcenter-access-control-settings).
If RBAC is enabled,
[Features](../installation/configuration.md#controlcenter-access-control-settings) are superseded by RBAC
role permissions. RBAC works in conjunction with [ACLs](/platform/current/security/authorization/acls/overview.html#kafka-authorization)
and [LDAP](c3-auth-ldap.md#controlcenter-security-ldap) security.
In general, RBAC in Control Center enforces access for only a few resources for
which it manages; typically those resources for which it keeps internal state
(license management, broker metrics, and alerts). See
[Control Center resource access by role](#c3-feature-access-by-role) for more details. The remainder of
RBAC-enforced operations on resources managed by Control Center are delegated
downstream to Apache Kafka®, Schema Registry, Connect, and ksqlDB.
#### SEE ALSO
To get started, try the [automated RBAC example](/platform/current/security/authorization/rbac/cp-rbac-example.html#rbac-demo) that showcases the RBAC
functionality in Confluent Platform.
## Prerequisites
- The [Metadata Service](/platform/current/kafka/configure-mds/index.html#rbac-mds-config) must be configured. Generate the
public key and obtain the MDS URLs that are required for
[configuring](#c3-config-rbac-props) Control Center for RBAC.
- Configure RBAC for every component Control Center must interact with in your
environment, which can include:
- Schema Registry. See [Configure Role-Based Access Control for Schema Registry in Confluent Platform](/platform/current/schema-registry/security/rbac-schema-registry.html#schemaregistry-rbac).
- Kafka Connect and any connectors. See [Configure RBAC for a Connect Cluster](/platform/current/connect/rbac/connect-rbac-connect-cluster.html#connect-rbac-connect-cluster)
and [RBAC for self-managed connectors](/platform/current/connect/rbac/connect-rbac-connectors.html#connect-rbac-connectors).
- ksqlDB clusters. See [Deploy Secure ksqlDB with RBAC in Confluent Platform](/platform/current/security/authorization/rbac/ksql-rbac.html#ksql-rbac).
### Recommended Confluent Platform RBAC reading
Review the following documentation to gain a thorough understanding
of the RBAC feature in Confluent Platform:
- [Use Role-Based Access Control (RBAC) for Authorization in Confluent Platform](/platform/current/security/authorization/rbac/overview.html#rbac-overview)
- [Configure Metadata Service (MDS) in Confluent Platform](/platform/current/kafka/configure-mds/index.html#rbac-mds-config)
- [Use Predefined RBAC Roles in Confluent Platform](/platform/current/security/authorization/rbac/rbac-predefined-roles.html#rbac-predefined-roles)
- [RBAC role use cases](/platform/current/security/authorization/rbac/rbac-predefined-roles.html#rbac-roles-use-cases)
- [Role-Based Access Control for Confluent Platform Quick Start](/platform/current/security/authorization/rbac/rbac-cli-quickstart.html#rbac-cli-quickstart)
- [Configure Role-Based Access Control for Schema Registry in Confluent Platform](/platform/current/schema-registry/security/rbac-schema-registry.html#schemaregistry-rbac)
- [Deploy Secure ksqlDB with RBAC in Confluent Platform](/platform/current/security/authorization/rbac/ksql-rbac.html#ksql-rbac)
- [Configure RBAC for a Connect Cluster](/platform/current/connect/rbac/connect-rbac-connect-cluster.html#connect-rbac-connect-cluster)
## Limitations
- Control Center is limited to a single Metadata Service (MDS) instance.
- When RBAC is enabled, Control Center and ksqlDB cannot be used in conjunction with Kerberos
because Control Center cannot support any SASL mechanism other than `OAUTHBEARER`.
Browsers rely on authenticating using token-based impersonation.
#### NOTE
This limitation is not applicable to Connect or Schema Registry.
- When RBAC is enabled, the [Auto-update UI](../installation/auto-update-ui.md#c3-auto-update-ui) feature cannot be used.
## Control Center resource access by role
All of the other components besides Control Center (Kafka, Schema Registry, Connect, ksqlDB)
are being enforced with RBAC by those components themselves. The only resources
that Control Center directly enforces with RBAC are:
- [License management](../installation/license.md#controlcenter-licenses) (global operation on Confluent Platform).
- [Broker metrics](../brokers.md#controlcenter-userguide-brokers) (system health per cluster).
- [Alerts](#c3-rbac-alerts-access) (global view for all clusters in a Control Center instance).
| Role Scope | License management | Broker metrics | Alerts |
|---------------|--------------------------|------------------|--------------------------|
| SystemAdmin | Yes [1](#id3) | Yes | Yes |
| ClusterAdmin | No | Yes | Yes |
| Operator | No | Yes | Yes |
| ResourceOwner | No | No | Yes [2](#id4) |
* **[1]** To access license management, the `SystemAdmin` role must be granted on the Kafka cluster running MDS.
* **[2]** Resource owners on a topic or consumer group can create a trigger or an action for that resource. They can also view the fired alert in the Alerts History and the Alerts REST API pages.
### About alerts access
The [Alerts](../alerts/index.md#controlcenter-userguide-alerts) page is a global view of
triggers, actions, and alert history for all clusters. Unlike other features in
Control Center that are scoped to a single cluster, the Alerts feature
encompasses all clusters being managed by a Control Center instance.
Control Center alerts consist of three entities:
a trigger, an action, and an alert.
These entities have the following relationships:
- A trigger can have multiple clusters associated with it (1:m).
- An action can have multiple triggers associated with it (1:m).
- An alert that was fired has one trigger associated with it (1:1).
These relationships affect how filtering access is performed.
Access to each entity when RBAC is enabled is determined as follows:
- [Trigger](../alerts/triggers.md#trigger-mgmnt) - Some defined condition on a cluster or set of
clusters. The trigger types are Cluster, Broker, Topic, and Consumer Group.
Trigger access is all or nothing: Either you can read, write, create, and delete
a given trigger; or you have no access at all. There are no fine-grained
access levels for triggers.
#### IMPORTANT
The trigger is the base entity for RBAC enforcement of alerts.
- [Action](../alerts/actions.md#actions-mgmnt) - What action to take when a trigger condition is met:
Send an [email](../alerts/examples.md#alert-email-action); or notification to
[Slack](../alerts/examples.md#alert-slack-webhook-action) or
[PagerDuty](../alerts/examples.md#alert-pagerduty-webhook-action). Actions are only accessible
if a user has access to all triggers associated with an action and their corresponding
clusters because triggers can be associated with resources in different clusters.
Otherwise, the action cannot even be viewed.
- [Alert](../alerts/navigate.md#alert-history) - The result of an action performed after a
trigger fires. To appear in the Alert History page, the trigger for the alert must
be a type that populates alert history (topic trigger). Alert history is only
accessible if a user has a role with access to the trigger that fired. Users
can only view the alert history for those triggers to which they have access.
In RBAC preview version 5.3, the only user roles who could access the
Alerts UI were `SystemAdmin`, `ClusterAdmin`, `Operator`. In RBAC
version 5.4, all users can access the Alerts UI by clicking the Alerts icon;
however, what the users can view or configure depends on their level of alerts
access. There are two levels of alerting:
- **Cluster-level access:** Encompasses Cluster and Broker triggers. The cluster
level roles can use topic-pattern matching when creating a Topic trigger because
those roles (`SystemAdmin`, `ClusterAdmin`, `Operator`)
are guaranteed access to viewing all topics within a specific cluster in a Control Center
instance. Topic-pattern matching allows applying a trigger to multiple topics
that match a pattern you specify.
#### NOTE
If your assigned role provides Cluster-level alerts access, that includes
access to all four types of triggers.
- **Resource-level access:** Encompasses Consumer Group and Topic triggers. The
resource level roles cannot use topic-pattern matching when creating a topic
trigger because access to all topics on all clusters is required. Even if a user
has a `ResourceOwner` role on a topic, they cannot use the topic pattern matching
to apply the trigger to multiple topics that they might not have access to.
The `ResourceOwner` role can use literal topic name matching when creating a
topic trigger. The resource-level access role cannot set up Cluster or Broker triggers.
The following table summarizes alert access permissions by role:
#### Alerts trigger access levels
| Roles | Cluster trigger | Broker trigger | Consumer Group trigger | Topic trigger | Topic trigger pattern matching |
|---------------|-------------------|------------------|--------------------------|-----------------|----------------------------------|
| SystemAdmin | Yes | Yes | Yes | Yes | Yes |
| ClusterAdmin | Yes | Yes | Yes | Yes | Yes |
| Operator | Yes | Yes | Yes | Yes | Yes |
| ResourceOwner | No | No | Yes | Yes | Yes [3](#id6) |
* **[3]** Users with only a ResourceOwner role assigned can use literal topic matching only. No pattern topic matching.
## Configure RBAC for Control Center
Configuring RBAC in Control Center entails following these steps:
1. Set the relevant RBAC [configuration options](#c3-config-rbac-props) in
the Control Center properties file.
2. Add any additional clusters for Control Center to manage (optional). See
the [configuration example](#c3-config-rbac-props).
3. Add a role binding for the Control Center user to the Control Center cluster and any other clusters
managed by the Control Center instance. See [Add a role binding for the Control Center user](#c3-config-rbac-user-role-bindings).
4. Configure user privileges for the remaining services (Schema Registry topic management,
Connect, ksqlDB). Refer to the
[privileges by role tables](#c3-role-privs-by-service), and to the respective
documentation for each service.
#### IMPORTANT
There are additional configurations required for metrics reporters and
interceptors when RBAC is enabled. For more information, see
[Configure RBAC for the Confluent Metrics Reporter](/platform/current/monitor/metrics-reporter.html#rbac-metrics). Also review the
[known issue](#c3-ki-cluster-connections).
## Set RBAC configuration options in the Control Center properties file
The following example shows the settings required for configuring RBAC in
Control Center. See the [RBAC](../installation/configuration.md#c3-rbac-settings)
and other security categories in the [Control Center Configuration Reference for Confluent Platform](../installation/configuration.md#controlcenter-configuration)
for descriptions of each option. The RBAC configuration settings are present
in each Control Center properties file. For more information, see [Control Center Configuration Examples for Confluent Platform](../installation/properties.md#c3-properties-files).
Prerequisites:
: Obtain the path to the public key, the MDS URLs, and your username
and password for MDS from your administrator.
Determine the cluster IDs for any auxiliary clusters you need Control Center to
connect to for a multi-cluster environment. See [Cluster Identifiers in Confluent Platform](/platform/current/security/authorization/rbac/rbac-get-cluster-ids.html#rbac-get-cluster-ids).
#### IMPORTANT
If you configured Control Center for RBAC in the 5.3 preview
release, the configuration options have changed in Confluent Platform version
5.4 and later. You must update your configuration.
1. Uncomment the following lines for each configuration option in the
appropriate Control Center properties file for your environment
(`CONFLUENT_HOME/etc/confluent-control-center/control-center.properties`).
Replace the placeholder values with your actual values.
```RST
############################# Control Center RBAC Settings #############################
# Enable RBAC authorization in Control Center by providing a comma-separated list of Metadata Service (MDS) URLs
#confluent.metadata.bootstrap.server.urls=http://localhost:8090
# MDS credentials of an RBAC user for Control Center to act on behalf of
# NOTE: This user must be a SystemAdmin on each Apache Kafka cluster
#confluent.metadata.basic.auth.user.info=username:password
# Enable SASL-based authentication for each Apache Kafka cluster (SASL_PLAINTEXT or SASL_SSL required)
#confluent.controlcenter.streams.security.protocol=SASL_PLAINTEXT
#confluent.controlcenter.kafka..security.protocol=SASL_PLAINTEXT
# Enable authentication using a bearer token for Control Center's REST endpoints
#confluent.controlcenter.rest.authentication.method=BEARER
# NOTE: Must match the MDS public key
#public.key.path=/path/to/publickey.pem
```
**Line descriptions:**
- **Line 4:** MDS URL for authorizing resources. In a multiple MDS environment, separate
the URLs with a comma. The presence of the MDS URL is what indicates to Control Center that
RBAC is enabled.
- **Line 8:** Metadata Service (MDS) credentials of an RBAC user for Control Center to act on behalf of.
- **Line 11-12:** The confluent.controlcenter.streams prefix represents the Kafka streams application
(You can use the option in line 12 for another Kafka cluster) and all configurations you need to add
for setting up a Kafka cluster.
- **Line 15:** The authentication method required to talk to the Control Center
backend through the REST layer. The OAuth-style `BEARER` method is required.
The Control Center frontend acquires an access token on your behalf and keeps it
refreshed. HTTP Basic authentication headers are not accepted.
- **Line 18:** The path to the public key required for REST authentication. Must be the
same public key that resides on MDS. The public key checks the token and
makes sure that the user requesting access is a valid user in the system.
#### IMPORTANT
Additional clusters in a multi-cluster environment
require connections to Kafka with RBAC enabled due to
a [known issue](#c3-ki-cluster-connections).
You can no longer send only metrics to Control Center in
an RBAC-enabled environment; you must fully enable management.
For more information, see [Monitor Kafka with Metrics Reporter in Confluent Platform](/platform/current/monitor/metrics-reporter.html#metrics-reporter).
2. Restart Confluent Platform for the properties file configuration to take effect.
If you are using a Confluent Platform development environment with a [Confluent CLI](https://docs.confluent.io/confluent-cli/current/index.html), stop and start as follows:
```bash
confluent local stop
confluent local start
```
The `control-center-dev.properties` file is passed in automatically.
## Add a role binding for the Control Center user
Add a role binding to bind a role to the Control Center user. RBAC in Control Center
requires a user to persist Control Center state onto
a Kafka cluster, referred to as the Control Center cluster. Add the role binding for
each Kafka cluster in your environment.
Prerequisite:
: Determine the Kafka cluster ID for Control Center and all other Kafka clusters
managed by Control Center. See [Cluster Identifiers in Confluent Platform](/platform/current/security/authorization/rbac/rbac-get-cluster-ids.html#rbac-get-cluster-ids).
#### NOTE
Replace with cluster ID for Control Center in the following example.
Remove the backslashes from a copied and pasted command
to avoid syntax errors.
```bash
confluent iam rbac role-binding create \
--principal User: \
--role SystemAdmin \
--kafka-cluster
```
#### IMPORTANT
Due to a [known issue](#c3-ki-service-account), the role must be `SystemAdmin`.
## Role privileges
Use the role privileges tables below as a guideline for the permissions
you need to grant to users.
### Topic management privileges by role in Control Center
The [Topics](../topics/index.md#controlcenter-userguide-topics) management area in Control Center
contains multiple features:
- [Overview](../brokers.md#c3-brokers-overview-metrics): Access to [Production](../brokers.md#c3-brokers-production-metrics) and
[Consumption](../brokers.md#c3-brokers-consumption-metrics) metrics for a topic. Users can view metrics if they have access to a topic and
the appropriate role for broker metrics. See [Control Center resource access by role](#c3-feature-access-by-role).
- [Message browser](../topics/messages.md#c3-topic-message-browser): Users can browse messages if
they have read access on a topic.
- [Schema](/platform/current/control-center/topics/schema.html#topicschema): Access is based on the privileges to read, write, and describe a subject.
- [Configuration](../topics/edit.md#c3-edit-topic): The `Describe configs` privilege allows access to the Configuration page.
Topics, schema subjects, and consumer groups are filtered in Control Center based on
the principal’s access.
Schema Registry provides a `/permissions` API endpoint that describes subject operations
that a user has; such as Read, Write, Delete, and so forth.
#### NOTE
The ability to add a topic is enforced by the
topic name. Topic creation is gated at form submission. This means that
users can click the Add topic button but will not know their privilege
ahead of time because the button is visible at all times due to the
topic name restriction.
Topic inspect (also referred to as the message browser) WebSocket connections
are proxied.
#### Topic management (cluster scope)
| Roles | Create | Delete | Read | Write | Describe | Describe configs | Alter | Alter configs | Describe access | Alter access |
|---------------|----------|----------|--------|---------|------------|--------------------|---------|-----------------|-------------------|----------------|
| super.user | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| SystemAdmin | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| UserAdmin | No | No | No | No | No | No | No | No | No | No |
| ClusterAdmin | Yes | Yes | No | No | Yes | Yes | Yes | Yes | No | No |
| Operator | No | No | No | No | No | No | No | No | Yes | No |
| SecurityAdmin | No | No | No | No | No | No | No | No | Yes | No |
#### Topic management (resource scope)
| Roles | Create | Delete | Read | Write | Describe | Describe configs | Alter | Alter configs | Describe access | Alter access |
|-----------------|----------|----------|--------|---------|------------|--------------------|---------|-----------------|-------------------|----------------|
| ResourceOwner | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| DeveloperRead | No | No | Yes | No | Yes | No | No | No | No | No |
| DeveloperWrite | No | No | No | Yes | Yes | No | No | No | No | No |
| DeveloperManage | Yes | Yes | No | No | Yes | Yes | No | No | No | No |
#### NOTE
RBAC security roles are additive in nature. Any user assigned
multiple roles has a union of the privileges associated with all of their assigned roles.
### Topic role binding examples
**Add read access to a topic for a user:**
```bash
confluent iam rbac role-binding create \
--principal User: \
--role DeveloperRead \
--resource Topic: \
--kafka-cluster
```
The user can view the topic in the [All topics](../topics/overview.md#c3-all-topics) page.
**Delete read access to a topic for a user:**
```bash
confluent iam rbac role-binding delete \
--principal User: \
--role DeveloperRead \
--resource Topic: \
--kafka-cluster
```
The user can no longer view the topic in the All topics page.
### Connector privileges by role in Control Center
Connectors are filtered in Control Center based on the principal’s access.
As of Confluent Platform version 5.3 and later,
Kafka Connect requests are now proxied by Control Center.
Connect provides a `/permissions` API endpoint that informs Control Center of
everything a user can perform based on their token scope. That permissions endpoint
determines the ability to [add](../connect.md#c3-add-connector),
[pause and resume](../connect.md#c3-pause-resume-connector),
and [delete a connector](../connect.md#c3-delete-connector) in the Control Center web interface.
The ability to add a connector is enforced by the connector name.
Scaling a connector is accomplished by editing a connector configuration, which is
controlled by the ability to describe or alter a connector
configuration. Control Center does not check the ability to scale until the
configuration changes are submitted
(that is, launched).
#### NOTE
There is not currently a read-only view of connector configurations in
Control Center when RBAC is enabled.
#### Connector privileges by role (cluster scope)
| Roles | Create | Read config | Read status | Pause | Resume | Scale | Delete | Configure | Describe access | Alter access |
|---------------|----------|---------------|---------------|---------|----------|---------|----------|-------------|-------------------|----------------|
| super.user | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| SystemAdmin | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| UserAdmin | No | No | No | No | No | No | No | No | No | No |
| ClusterAdmin | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | No | No |
| Operator | No | No | Yes | Yes | Yes | Yes | No | No | No | No |
| SecurityAdmin | No | No | No | No | No | No | No | No | Yes | No |
#### Connector privileges by role (resource scope)
| Roles | Create | Read config | Read status | Pause | Resume | Scale | Delete | Configure | Describe access | Alter access |
|-----------------|----------|---------------|---------------|---------|----------|---------|----------|-------------|-------------------|----------------|
| ResourceOwner | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| DeveloperRead | No | Yes | Yes | No | No | No | No | No | No | No |
| DeveloperWrite | No | No | Yes | No | No | No | No | Yes | No | No |
| DeveloperManage | Yes | No | Yes | Yes | Yes | Yes | No | No | No | No |
For more information about RBAC in Connect, see [Configure RBAC for a Connect Cluster](/platform/current/connect/rbac/connect-rbac-connect-cluster.html#connect-rbac-connect-cluster)
and [RBAC for self-managed connectors](/platform/current/connect/rbac/connect-rbac-connectors.html#connect-rbac-connectors).
### Connector role binding examples
**Add read access to a connector for a user:**
```bash
confluent iam rbac role-binding create \
--principal User: \
--role DeveloperRead \
--resource Connector: \
--kafka-cluster \
--connect-cluster-id
```
The user can view the connector in the [Connectors](../connect.md#c3-connectors-page) page.
**Delete read access to a connector for a user:**
```bash
confluent iam rbac role-binding delete \
--principal User: \
--role DeveloperRead \
--resource Connector: \
--kafka-cluster \
--connect-cluster-id
```
The user can no longer view the connector in the Connectors page.
**Grant access to the connect-statuses internal topic**
#### IMPORTANT
If users don’t have permission on the
Kafka cluster but they’d like to use Connect in Control Center,
granting the `DeveloperRead` role on the internal
`connect-statuses` topic is recommended. Review the
[known issue](#c3-ki-ksql-connect) for details.
```bash
confluent iam rbac role-binding create \
--principal User: \
--role DeveloperRead \
--resource Topic:connect-statuses \
--kafka-cluster
```
### Add a connector in Control Center fields considerations
When RBAC is enabled in Control Center, there are additional fields (such as JAAS
configurations) required to configure connectors that are not currently available
as default fields. The **Additional Properties** pane allows
adding any needed properties when [adding a connector](../connect.md#c3-add-connector).
#### NOTE
Users can type a topic name in the **topics** field (in the
**Which topics do you want to get data from?**
pane) even if they do not have permissions for that topic, which
allows users to configure a connector under those circumstances.
### ksqlDB privileges by role in Control Center
Access to the [ksqlDB GUI](../ksql.md#controlcenter-userguide-ksql) in Control Center is
determined by the `CONTRIBUTE` operation on
a ksqlDB cluster. `CONTRIBUTE` grants the ability to connect to a ksqlDB cluster.
HTTP requests in Control Center are proxied down to the ksqlDB server. The subsequent
WebSocket connection is directly to ksqlDB.
**ksqlDB contribute privileges by role (cluster scope)**
| Roles | Contribute |
|---------------|--------------|
| super.user | Yes |
| SystemAdmin | Yes |
| UserAdmin | No |
| ClusterAdmin | Yes |
| Operator | No |
| SecurityAdmin | No |
**ksqlDB contribute privileges by role (resource scope)**
| Roles | Contribute |
|-----------------|--------------|
| ResourceOwner | Yes |
| DeveloperRead | No |
| DeveloperWrite | Yes |
| DeveloperManage | No |
For information about ksqlDB RBAC, see [Deploy Secure ksqlDB with RBAC in Confluent Platform](/platform/current/security/authorization/rbac/ksql-rbac.html#ksql-rbac).
### ksqlDB role binding example
**Add DeveloperWrite access to a ksqlDB cluster for a user:**
```bash
confluent iam rbac role-binding create \
--principal User: \
--role DeveloperWrite \
--kafka-cluster \
--ksql-cluster-id \
--resource KsqlCluster:ksql-cluster
```
For more role binding examples for ksqlDB, see
[Assign roles for starting ksqlDB Server](/platform/current/security/authorization/rbac/ksql-rbac.html#ksql-rbac-assign-startup-roles) and [Assign roles for contributing to a ksqlDB application](/platform/current/security/authorization/rbac/ksql-rbac.html#ksql-rbac-assign-roles-to-contribute).
#### IMPORTANT
Grant users access to the topics they want to query. Review the
[known issue](#c3-ki-ksql-connect) for
details.
### Access schema using Control Center example
**Grant access to schemas from the Control Center UI**
To provide minimal access to the Schema Registry for Control Center users, grant the
`DeveloperRead` role on the internal `_schemas` topic.
```bash
confluent iam rbac role-binding create \
--principal User: \
--resource Subject: \
--role DeveloperRead \
--kafka-cluster \
--schema-registry-cluster-id
```
## Known issues with RBAC in Control Center
### Control Center connections to external clusters
**Direct access to each external cluster is required**
When RBAC is enabled, Control Center requires management to be enabled on each
cluster. This means that metrics reporters and interceptors that are configured
must have a direct connection for Control Center to operate properly in an RBAC
environment. This limitation requires setting
`confluent.controlcenter.kafka..bootstrap.servers`
and `confluent.controlcenter.kafka..security.protocol` for each external
cluster as shown in the [configuration example](#c3-config-rbac-props).
#### IMPORTANT
There are additional configurations required for metrics reporters
and interceptors when RBAC is enabled. For more information,
see [Configure RBAC for the Confluent Metrics Reporter](/platform/current/monitor/metrics-reporter.html#rbac-metrics).
### Control Center service principal role
**The principal for Control Center requires SystemAdmin access**
The Control Center user must be set up as a privileged user `SystemAdmin` on each cluster.
Due to the underlying architecture for consumer lag, elevated privileges are required
to guarantee users access to all consumer groups and continued support for [consumer group
alerts for consumer lag](../alerts/examples.md#consumer-lag-trigger). The consumer lag offsets are currently not obtained
from metrics reporters.
### Connect and ksqlDB clusters user access
**Connect and ksqlDB require at least minimal user access to the underlying Kafka clusters**
When RBAC is enabled, to see [Connect](../connect.md#controlcenter-userguide-connect)
or [ksqlDB](../ksql.md#controlcenter-userguide-ksql) in Control Center,
a user requires access to
the backing Kafka clusters:
- If users don’t have permission on the
Kafka cluster and they’d like to use Connect in Control Center,
granting the `DeveloperRead` role on the internal `connect-statuses` topic is recommended.
- To run a SQL query, users require some level of access to the Kafka cluster. To
be able to view ksqlDB in the Control Center web interface, grant users
access to the topics they need to query.
In both these cases, granting users access to the backing Kafka clusters
allows them to access the Connect and ksqlDB pages in Control Center.
## Troubleshoot RBAC in Control Center
**Issue:** Get an access message when trying to view streams monitoring data
in the **Topics** -> [Consumption panel](../topics/view.md#c3-view-topic-consume-metrics). This applies to
the % message consumed chart and the end-to-end latency chart.
**Background:** A user attempts to view stream monitoring data on a topic.
The user has access to the topic, but does not have
full access to all consumer groups reading from a topic.
**Remedy:** Grant the user access to all consumer groups reading from a topic if
the user should have said access.
## Disable RBAC
All components interacting with Control Center in your environment must disable RBAC.
To disable RBAC in Control Center, comment out the `confluent.metadata.bootstrap.server.urls`
setting and restart Control Center.