Configure RBAC for Control Center

Control Center supports Authorization using Role-Based Access Control (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.

If RBAC is enabled, Access Control Settings are superseded by RBAC role permissions. RBAC works in conjunction with ACLs and 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 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 demo that showcases the RBAC functionality in Confluent Platform.

Prerequisites

Limitations

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

Role Scope License management Broker metrics Alerts
SystemAdmin Yes [1] Yes Yes
ClusterAdmin No Yes Yes
Operator No Yes Yes
ResourceOwner No No Yes [2]
[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 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.

Control Center alert entities and relationships

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 - 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 - What action to take when a trigger condition is met: Send an email; or notification to Slack or PagerDuty. 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 - 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]
[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 in the Control Center properties file.
  2. Add any additional clusters for Control Center to manage (optional). See the configuration example.
  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.
  4. Configure user privileges for the remaining services (Schema Registry topic management, Connect, ksqlDB). Refer to the privileges by role tables, 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 and Set up interceptors for RBAC. Also review the known issue.

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 Settings and other security categories in the Control Center Configuration Reference for descriptions of each option. The RBAC configuration settings are present in each Control Center properties file. For more information, see Control Center 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 Discover Identifiers for Clusters.

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 (<path-to-confluent>/etc/confluent-control-center/control-center.properties). Replace the placeholder values with your actual values.

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    ############################# 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.<name>.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: The confluent.controlcenter.streams prefix represents the Kafka streams application and all configurations you need to add for setting up a Kafka cluster. This example uses the SASL_PLAINTEXT security protocol for connections from Control Center to the underlying Kafka cluster instance. Other SASL mechanisms such as SASL_SSL are also supported.
    • Line 12: The name and port of the bootstrap servers for each additional Kafka cluster being monitored by Control Center. These settings use the confluent.controlcenter.kafka prefix. Replace <name> with the name of the cluster. That name appears in the cluster navigation bar in the Control Center UI. For more details, see bootstrap servers.
    • 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. 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. You can no longer send only metrics to Control Center in an RBAC-enabled environment; you must fully enable management. For more information, see Confluent 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, stop and start as follows:

    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 Discover Identifiers for Clusters.

Note

Replace <kafka-id> with cluster ID for Control Center in the following example. Remove the backslashes from a copied and pasted command to avoid syntax errors.

confluent iam rolebinding create \
--principal User:<c3-principal> \
--role SystemAdmin \
--kafka-cluster-id <kafka-id>

Important

Due to a known issue, the role must be SystemAdmin.

Tip

Add a role assignment or Delete a role assignment using the Control Center UI rather than the CLI.

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 management area in Control Center contains multiple features:

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

confluent iam rolebinding create \
--principal User:<user-name> \
--role DeveloperRead \
--resource Topic:<topic_name> \
--kafka-cluster-id <kafka_cluster_id>

The user can view the topic in the All topics page.

Delete read access to a topic for a user:

confluent iam rolebinding delete \
--principal User:<user-name> \
--role DeveloperRead \
--resource Topic:<topic_name> \
--kafka-cluster-id <kafka_cluster_id>

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 usercan perform based on their token scope. That permissions endpoint determines the ability to add, pause and resume, and delete a 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 Configuring RBAC for a Connect cluster and Configuring RBAC for connectors.

Connector role binding examples

Add read access to a connector for a user:

confluent iam rolebinding create \
--principal User:<user-name> \
--role DeveloperRead \
--resource Connector:<connector_name> \
--kafka-cluster-id <kafka_cluster_id> \
--connect-cluster-id <connect_cluster_id>

The user can view the connector in the Connectors page.

Delete read access to a connector for a user:

confluent iam rolebinding delete \
--principal User:<user-name> \
--role DeveloperRead \
--resource Connector:<connector_name> \
--kafka-cluster-id <kafka_cluster_id> \
--connect-cluster-id <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 for details.

confluent iam rolebinding create \
--principal User:<user-name> \
--role DeveloperRead \
--resource Topic:connect-statuses \
--kafka-cluster-id <kafka_cluster_id>

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.

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.

Tip

As of Confluent Platform version 5.4 and later, adding a connector in Control Center has been improved. For more information, see Add a connector (RBAC environment).

ksqlDB privileges by role in Control Center

Access to the ksqlDB GUI 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 ksqlDB and role-based access control (RBAC).

ksqlDB role binding example

Add DeveloperWrite access to a |ksqldb| cluster for a user:

confluent iam rolebinding create \
--principal User:<sam> \
--role DeveloperWrite \
--kafka-cluster-id <kafka-id>  \
--ksql-cluster-id <ksql-id>  \
--resource KsqlCluster:ksql-cluster

For more role binding examples for ksqlDB, see Assign roles for starting ksqlDB Server and Assign roles for contributing to a ksqlDB application.

Important

Grant users access to the topics they want to query. Review the known issue for details.

Known issues with RBAC in Control Center

Control Center connections to external clusters

Direct access to each external cluster is required. (SEC-239, MMA-4394). 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.<name>.bootstrap.servers and confluent.controlcenter.kafka.<name>.security.protocol for each external cluster as shown in the configuration example.

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 and Set up interceptors for RBAC.

Control Center service principal role

The service principal for Control Center requires SystemAdmin access (MMA-4634, MMA-4650). 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. The consumer lag offsets are currently not obtained from metrics reporters.

Control Center deprecated views

Deprecated views for System Health and Data Streams cannot be accessed with RBAC enabled. When RBAC is enabled, the deprecated views for System Health and Data Streams cannot be accessed. RBAC must be disabled to view them. The deprecated views can be re-enabled by setting confluent.controlcenter.deprecated.views.enable to true in the appropriate Control Center properties file. Deprecated features will eventually be removed from the software.

Connect and ksqlDB clusters user access

Connect and |ksqldb| require at least minimal user access to the underlying Kafka clusters (MMA-4756).

When RBAC is enabled, to see Connect or ksqlDB 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. This applies to the % message consumed chart and the end-to-end latency chart.

RBAC

RBAC message need access to a topic and all its consumer groups to view a 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.controlcenter.metadata.urls setting and restart Control Center.