Role-based access control (RBAC) in Confluent Control Center¶
Control Center supports Authorization using Role-Based Access Control (RBAC). As of Confluent Platform version 5.3 and later, role-based access control (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 read-only or full access.
Important
This feature is available as a preview feature. A preview feature is a component of Confluent Platform that is being introduced to gain early feedback from developers. This feature can be used for evaluation and non-production testing purposes or to provide feedback to Confluent.
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 KSQL, License Manager, Schema Registry, topic inspections,
broker configurations, and more. See Access control settings
for more information on those available
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 KSQL.
Tip
To get started, try the RBAC automated demo that showcases the RBAC functionality in Confluent Platform.
Prerequisites¶
- The Metadata Service must be configured. Generate the public key and obtain the MDS URLs that are required for configuring Control Center for RBAC.
- Configure RBAC for every component Control Center must interact with in your
environment, which can include:
- Schema Registry. See Configuring Role-Based Access Control for Schema Registry.
- Kafka Connect and any connectors. See Configuring RBAC for a Connect cluster and Configuring RBAC for connectors.
- KSQL clusters. See KSQL and role-based access control (RBAC).
Limitations¶
When RBAC is enabled, Control Center 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.
Recommended Confluent Platform RBAC reading¶
Review the following documentation to gain a thorough understanding of the RBAC feature in Confluent Platform:
- Authorization using Role-Based Access Control.
- Configure Metadata Service (MDS).
- Role-Based Access Control Predefined Roles and RBAC role use cases.
- Role-Based Access Control Quick Start.
- Configuring Role-Based Access Control for Schema Registry.
- KSQL and role-based access control (RBAC).
- Configuring RBAC for a Connect cluster.
Control Center resource access by role¶
All of the other components besides Control Center (Kafka, Schema Registry, Connect, KSQL) are being enforced with RBAC by those components themselves. The only resources that Control Center directly enforces with RBAC are:
- License management (global operation on Confluent Platform).
- Broker metrics (system health per cluster).
- Alerts (global view for all clusters in a Control Center instance).
| Role Scope | License management | Broker metrics | Alerts |
|---|---|---|---|
| SystemAdmin | Yes [1] | Yes | Yes |
| ClusterAdmin | No | Yes | Yes |
| Operator | No | Yes | Yes |
| [1] | To access license management, the SystemAdmin role must be granted on the Kafka cluster running MDS. |
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.
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 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. Only accessible (read, write, create, delete, and so forth) if a user has Alerts access to all clusters associated with that trigger. The trigger is the base entity for RBAC enforcement of alerts.
- Action - What to do when a trigger condition is met: Send an email; or notification to Slack or PagerDuty. Only accessible if a user has access to all triggers and their corresponding clusters because triggers can be associated with different clusters. Otherwise, the action cannot even be viewed.
- Alert - The result of an action performed after a trigger fires. The alert must be a type that populates alert history. Only accessible if a user has access to the trigger (and all its associated clusters) that fired.
Configure RBAC for Control Center¶
Configuring RBAC in Control Center entails following these steps:
- Set the relevant RBAC configuration options in the Control Center properties file.
- Add any additional clusters for Control Center to manage (optional). See lines 18 and 19 in the configuration example.
- 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.
- Configure user privileges for the remaining services (Schema Registry topic management, Connect, KSQL). 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.
- 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.
Add the following lines to the appropriate Control Center properties file for your environment (
<path-to-confluent>/etc/confluent-control-center/control-center.properties). Replace the placeholder values shown in <brackets> with your actual values.1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
#REST authentication method (must be BEARER for RBAC) confluent.controlcenter.rest.authentication.method=BEARER #Must be the same public key that MDS uses REQUIRED confluent.controlcenter.auth.bearer.public.key.path=</filepath/to/public.key> #Set security protocol; you can use other SASL mechanisms too confluent.controlcenter.streams.security.protocol=SASL_PLAINTEXT #MDS username/password for the Confluent Control Center (C3) service principal confluent.controlcenter.metadata.username=<c3-principal> confluent.controlcenter.metadata.password=<c3-password> #MDS URLs confluent.controlcenter.metadata.urls=<http://mds-host:8090> #Schema Registry confluent.controlcenter.schema.registry.basic.auth.credentials.source=USER_INFO confluent.controlcenter.schema.registry.basic.auth.user.info=<c3-user>:<c3-password> #Must configure these settings for each external cluster confluent.controlcenter.kafka.<name>.bootstrap.servers<kafka-name>:9092 confluent.controlcenter.kafka.<name>.security.protocol=SASL_PLAINTEXT
Line descriptions (single cluster environment):
- Line 2: The authentication method required to talk to the Control Center backend through the
REST layer. The OAuth-style
BEARERmethod is required. The Control Center frontend acquires an access token on your behalf and keeps it refreshed. Basic auth headers are not accepted; you cannot cURL to the Control Center backend because that requires a token and that access is handled for you by the frontend bearer token. - Line 5: 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.
- Line 8: The
confluent.controlcenter.streamsprefix represents the Kafka streams application and all configurations you need to add for setting up a Kafka cluster. This example uses theSASL_PLAINTEXTsecurity protocol for connections from Control Center to the underlying Kafka cluster instance. Other SASL mechanisms such asSASL_SSLare also supported. - Lines 11 and 12: Username and password for MDS as a Control Center service principal.
- Line 15: 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.
- Lines 17 and 18 The Schema Registry basic auth credentials.
Line descriptions (additional settings for multi-cluster environment):
- Line 22: The name and port of the bootstrap servers for an additional
Kafka cluster being monitored by Control Center.
These settings use the
confluent.controlcenter.kafkaprefix. Replacenamewith the name of the cluster. That name appears in the cluster navigation bar. For more details, see bootstrap servers. - Line 23: Specify the security protocol for each additional cluster. A SASL protocol must be used for lines 8 and 19.
Note
Additional clusters 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. See Confluent Metrics Reporter.
- Line 2: The authentication method required to talk to the Control Center backend through the
REST layer. The OAuth-style
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.propertiesfile 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.
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:
- Overview: Access to Production and Consumption 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.
- Message browser: Users can browse messages if they have read access on a topic.
- Schema: Access is based on the privileges to read, write, and describe a subject.
- Configuration: The
Describe configsprivilege 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.
| 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 |
| 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.
Schema Registry in Control Center¶
Grant the ClusterAdmin role to Control Center principal on the Schema Registry cluster.
confluent iam rolebinding create \
--principal User:<c3-principal> \
--role ClusterAdmin \
--kafka-cluster-id <kafka_cluster_id> \
--schema-registry-cluster-id <schema-registry-group-id>
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,
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.
| 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 |
| 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
The topics field (in the Which topics do you want to get data from? pane) allows typing a topic name that a user does not have permissions to so as to at least allow the user to configure a connector.
KSQL privileges by role in Control Center¶
Access to the KSQL GUI in Control Center is
determined by the CONTRIBUTE operation on
a KSQL cluster. CONTRIBUTE grants the ability to connect to a KSQL cluster.
HTTP requests in Control Center are proxied down to the KSQL server. The subsequent WebSocket connection is directly to KSQL.
KSQL contribute privileges by role (cluster scope)
| Roles | Contribute |
|---|---|
| super.user | Yes |
| SystemAdmin | Yes |
| UserAdmin | No |
| ClusterAdmin | Yes |
| Operator | No |
| SecurityAdmin | No |
KSQL contribute privileges by role (resource scope)
| Roles | Contribute |
|---|---|
| ResourceOwner | Yes |
| DeveloperRead | No |
| DeveloperWrite | Yes |
| DeveloperManage | No |
For information about KSQL RBAC, see KSQL and role-based access control (RBAC).
KSQL role binding example¶
Add DeveloperWrite access to a KSQL 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 KSQL, see Assign roles for starting KSQL Server and Assign roles for contributing to a KSQL 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 at this time.
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 KSQL clusters user access¶
Connect and KSQL require at least minimal user access to the underlying Kafka clusters (MMA-4756).
When RBAC is enabled, to see Connect or 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
DeveloperReadrole on the internalconnect-statusestopic is recommended. - To run a KSQL query, users require some level of access to the Kafka cluster. To be able to view KSQL 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 KSQL 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 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.