.. _controlcenter_security_rbac: ################################################## Configure |rbac| for |c3-short| ################################################## .. meta:: :title: Confluent Control Center Role-Based Access Control (RBAC) :description: This document describes the RBAC feature for Confluent Control Center. Configure RBAC for Control Center. :keywords: Confluent Control Center, RBAC, role-based access control, alerts, actions, triggers |c3-short| supports :ref:`rbac-overview` (|rbac-long|). As of |cp| version 5.3 and later, |rbac| provides a fine-grained security model across the platform in a development environment. Prior versions of |c3-short| only provided coarse-grained access control of either read-only or full access. If |rbac| is not enabled, or |c3-short| is running against |cp| versions prior to 5.3 and later, |c3-short| 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 |c3-short| configuration options can remove access for the features that have those flags; such as |ksqldb|, License Manager, |sr|, topic inspections, broker configurations, and more. For more information on those available settings, see :ref:`Access control settings `. If |rbac| is enabled, :ref:`controlcenter_access_control_settings` are superseded by |rbac| role permissions. |rbac| works in conjunction with :ref:`ACLs ` and :ref:`LDAP ` security. In general, |rbac| in |c3-short| 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 :ref:`c3_feature_access_by_role` for more details. The remainder of |rbac|-enforced operations on resources managed by |c3-short| are delegated downstream to |ak-tm|, |sr|, |kconnect|, and |ksqldb|. .. include:: ../../includes/rbac-demo.rst .. _c3_rbac_prereqs: Prerequisites ############# - The :ref:`Metadata Service ` must be configured. Generate the public key and obtain the MDS URLs that are required for :ref:`configuring ` |c3-short| for |rbac|. - Configure |rbac| for every component |c3-short| must interact with in your environment, which can include: - |sr|. See :ref:`schemaregistry_rbac`. - |kconnect-long| and any connectors. See :ref:`connect-rbac-connect-cluster` and :ref:`connect-rbac-connectors`. - |ksqldb| clusters. See :ref:`ksql-rbac`. .. _c3_rbac_reading: Recommended |cp| |rbac| reading ------------------------------- Review the following documentation to gain a thorough understanding of the |rbac| feature in |cp|: - :ref:`rbac-overview`. - :ref:`rbac-mds-config`. - :ref:`rbac-predefined-roles` and :ref:`rbac-roles-use-cases`. - :ref:`rbac-cli-quickstart`. - :ref:`schemaregistry_rbac`. - :ref:`ksql-rbac`. - :ref:`connect-rbac-connect-cluster`. .. _c3_rbac_limitations: Limitations ########### - |c3-short| is limited to a single |mds-long| instance. - When |rbac| is enabled, |c3-short| and |ksqldb| cannot be used in conjunction with Kerberos because |c3-short| cannot support any SASL mechanism other than ``OAUTHBEARER``. Browsers rely on authenticating using token-based impersonation. .. note:: This limitation is not applicable to |kconnect| or |sr|. - When |rbac| is enabled, the :ref:`Auto-update UI ` feature cannot be used. .. _c3_feature_access_by_role: |c3-short| resource access by role ################################## All of the other components besides |c3-short| (|ak|, |sr|, |kconnect|, |ksqldb|) are being enforced with |rbac| by those components themselves. The only resources that |c3-short| directly enforces with |rbac| are: - :ref:`License management ` (global operation on |cp|). - :ref:`Broker metrics ` (system health per cluster). - :ref:`Alerts ` (global view for all clusters in a |c3-short| instance). =============== ================== ============== ======== 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 |ak| 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. .. _c3_rbac_alerts_access: About alerts access ------------------- The :ref:`Alerts ` page is a global view of triggers, actions, and alert history for all clusters. Unlike other features in |c3-short| that are scoped to a single cluster, the Alerts feature encompasses all clusters being managed by a |c3-short| instance. |c3-short| alerts consist of three entities: a trigger, an action, and an alert. .. figure:: ../../images/c3-alert-entities.png :width: 600px :alt: 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: - :ref:`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. - :ref:`Action ` - What action to take when a trigger condition is met: Send an :ref:`email`; or notification to :ref:`Slack ` or :ref:`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. - :ref:`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 |c3-short| 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: .. csv-table:: Alerts trigger access levels :align: left :header: "Roles", "Cluster trigger", "Broker trigger", "Consumer Group trigger", "Topic trigger", "Topic trigger pattern matching" :widths: 20, 20, 20, 20, 20, 30 "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. .. _c3_config_rbac: Configure |rbac| for |c3-short| ############################### Configuring |rbac| in |c3-short| entails following these steps: #. Set the relevant |rbac| :ref:`configuration options ` in the |c3-short| properties file. #. Add any additional clusters for |c3-short| to manage (optional). See the :ref:`configuration example `. #. Add a role binding for the |c3-short| user to the |c3-short| cluster and any other clusters managed by the |c3-short| instance. See :ref:`c3_config_rbac_user_role_bindings`. #. Configure user privileges for the remaining services (Schema Registry topic management, Connect, |ksqldb|). Refer to the :ref:`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 :ref:`Configure RBAC for the Confluent Metrics Reporter ` and :ref:`interceptor_rbac`. Also review the :ref:`known issue `. .. _c3_config_rbac_props: Set |rbac| configuration options in the |c3-short| properties file ################################################################## The following example shows the settings required for configuring |rbac| in |c3-short|. See the :ref:`c3_RBAC_settings` and other security categories in the :ref:`controlcenter_configuration` for descriptions of each option. The |rbac| configuration settings are present in each |c3-short| properties file. For more information, see :ref:`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 |c3-short| to connect to for a multi-cluster environment. See :ref:`rbac-get-cluster-ids`. .. important:: If you configured |c3-short| for |rbac| in the 5.3 preview release, the configuration options have changed in |cp| version 5.4 and later. You must update your configuration. #. Uncomment the following lines for each configuration option in the appropriate |c3-short| properties file for your environment (``CONFLUENT_HOME/etc/confluent-control-center/control-center.properties``). Replace the placeholder values with your actual values. .. code-block:: RST :linenos: ############################# 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 |c3-short| that |rbac| is enabled. - **Line 8:** |mds-long| credentials of an RBAC user for |c3-short| 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 |ak| cluster) and all configurations you need to add for setting up a Kafka cluster. - **Line 15:** The authentication method required to talk to the |c3-short| backend through the REST layer. The OAuth-style ``BEARER`` method is required. The |c3-short| 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 |ak| with |rbac| enabled due to a :ref:`known issue `. You can no longer send only metrics to |c3-short| in an |rbac|-enabled environment; you must fully enable management. For more information, see :ref:`metrics_reporter`. #. Restart |cp| for the properties file configuration to take effect. If you are using a |cp| development environment with a :confluent-cli:`Confluent CLI|index.html`, stop and start as follows: .. codewithvars:: bash |confluent_stop| |confluent_start| The ``control-center-dev.properties`` file is passed in automatically. .. _c3_config_rbac_user_role_bindings: Add a role binding for the |c3-short| user ########################################## Add a role binding to bind a role to the |c3-short| user. |rbac| in |c3-short| requires a user to persist |c3-short| state onto a |ak| cluster, referred to as the |c3-short| cluster. Add the role binding for each |ak| cluster in your environment. Prerequisite: Determine the |ak| cluster ID for |c3-short| and all other |ak| clusters managed by |c3-short|. See :ref:`rbac-get-cluster-ids`. .. note:: Replace with cluster ID for |c3-short| in the following example. Remove the backslashes from a copied and pasted command to avoid syntax errors. .. code:: bash confluent iam rbac role-binding create \ --principal User: \ --role SystemAdmin \ --kafka-cluster-id .. important:: Due to a :ref:`known issue `, the role must be ``SystemAdmin``. .. tip:: :ref:`Add a role assignment ` or :ref:`Delete a role assignment ` using the |c3-short| UI rather than the CLI. .. _c3_role_privs_by_service: Role privileges ############### Use the role privileges tables below as a guideline for the permissions you need to grant to users. .. _c3_rbac_topic_mgmnt: Topic management privileges by role in |c3-short| ------------------------------------------------- The :ref:`Topics ` management area in |c3-short| contains multiple features: - :ref:`Overview `: Access to :ref:`Production ` and :ref:`Consumption ` metrics for a topic. Users can view metrics if they have access to a topic and the appropriate role for broker metrics. See :ref:`c3_feature_access_by_role`. - :ref:`Message browser `: Users can browse messages if they have read access on a topic. - :ref:`Schema `: Access is based on the privileges to read, write, and describe a subject. - :ref:`Configuration `: The ``Describe configs`` privilege allows access to the Configuration page. Topics, schema subjects, and consumer groups are filtered in |c3-short| based on the principal's access. |sr| 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. .. csv-table:: Topic management (cluster scope) :align: left :header: "Roles", "Create", "Delete", "Read", "Write", "Describe", "Describe configs", "Alter", "Alter configs", "Describe access", "Alter access" :widths: 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20 "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" .. csv-table:: Topic management (resource scope) :align: left :header: "Roles", "Create", "Delete", "Read", "Write", "Describe", "Describe configs", "Alter", "Alter configs", "Describe access", "Alter access" :widths: 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20 "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. .. _c3_topic_rolebinding_ex: Topic role binding examples --------------------------- **Add read access to a topic for a user:** .. code:: bash confluent iam rbac role-binding create \ --principal User: \ --role DeveloperRead \ --resource Topic: \ --kafka-cluster-id The user can view the topic in the :ref:`All topics ` page. **Delete read access to a topic for a user:** .. code:: bash confluent iam rbac role-binding delete \ --principal User: \ --role DeveloperRead \ --resource Topic: \ --kafka-cluster-id The user can no longer view the topic in the All topics page. .. _c3_rbac_connect: Connector privileges by role in |c3-short| ------------------------------------------ Connectors are filtered in |c3-short| based on the principal's access. As of |cp| version 5.3 and later, |kconnect-long| requests are now proxied by |c3-short|. |kconnect| provides a ``/permissions`` API endpoint that informs |c3-short| of everything a user can perform based on their token scope. That permissions endpoint determines the ability to :ref:`add `, :ref:`pause and resume `, and :ref:`delete a connector ` in the |c3-short| 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. |c3-short| 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 |c3-short| when |rbac| is enabled. .. csv-table:: Connector privileges by role (cluster scope) :header: "Roles", "Create", "Read config", "Read status", "Pause", "Resume", "Scale", "Delete", "Configure", "Describe access", "Alter access" :widths: 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20 "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" .. csv-table:: Connector privileges by role (resource scope) :header: "Roles", "Create", "Read config", "Read status", "Pause", "Resume", "Scale", "Delete", "Configure", "Describe access", "Alter access" :widths: 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20 "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 |kconnect|, see :ref:`connect-rbac-connect-cluster` and :ref:`connect-rbac-connectors`. .. _c3_connector_rolebinding_ex: Connector role binding examples ------------------------------- **Add read access to a connector for a user:** .. code:: bash confluent iam rbac role-binding create \ --principal User: \ --role DeveloperRead \ --resource Connector: \ --kafka-cluster-id \ --connect-cluster-id The user can view the connector in the :ref:`Connectors ` page. **Delete read access to a connector for a user:** .. code:: bash confluent iam rbac role-binding delete \ --principal User: \ --role DeveloperRead \ --resource Connector: \ --kafka-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 |ak| cluster but they'd like to use |kconnect| in |c3-short|, granting the ``DeveloperRead`` role on the internal ``connect-statuses`` topic is recommended. Review the :ref:`known issue ` for details. .. code:: bash confluent iam rbac role-binding create \ --principal User: \ --role DeveloperRead \ --resource Topic:connect-statuses \ --kafka-cluster-id .. _c3_add_connector_rbac: Add a connector in |c3-short| fields considerations --------------------------------------------------- When |rbac| is enabled in |c3-short|, 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 :ref:`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. .. these UX issues above are slated for UX improvements (ongoing, iterative) .. tip:: As of |cp| version 5.4 and later, adding a connector in |c3-short| has been improved. For more information, see :ref:`c3-add-connector-rbac-workflow`. .. _c3_rbac_ksql: |ksqldb| privileges by role in |c3-short| ----------------------------------------- Access to the :ref:`ksqlDB GUI ` in |c3-short| is determined by the ``CONTRIBUTE`` operation on a |ksqldb| cluster. ``CONTRIBUTE`` grants the ability to connect to a |ksqldb| cluster. HTTP requests in |c3-short| are proxied down to the |ksqldb| server. The subsequent WebSocket connection is directly to |ksqldb|. **ksqlDB contribute privileges by role (cluster scope)** .. csv-table:: :header: "Roles", "Contribute" :widths: 20, 20 "super.user", "Yes" "SystemAdmin", "Yes" "UserAdmin", "No" "ClusterAdmin", "Yes" "Operator", "No" "SecurityAdmin", "No" **ksqlDB contribute privileges by role (resource scope)** .. csv-table:: :header: "Roles", "Contribute" :widths: 20, 20 "ResourceOwner", "Yes" "DeveloperRead", "No" "DeveloperWrite", "Yes" "DeveloperManage", "No" For information about |ksqldb| |rbac|, see :ref:`ksql-rbac`. .. _c3_ksql_rolebinding_ex: |ksqldb| role binding example ----------------------------- **Add DeveloperWrite access to a ksqlDB cluster for a user:** .. code:: bash confluent iam rbac role-binding create \ --principal User: \ --role DeveloperWrite \ --kafka-cluster-id \ --ksql-cluster-id \ --resource KsqlCluster:ksql-cluster For more role binding examples for |ksqldb|, see :ref:`ksql-rbac-assign-startup-roles` and :ref:`ksql-rbac-assign-roles-to-contribute`. .. important:: Grant users access to the topics they want to query. Review the :ref:`known issue ` for details. .. _c3_access_schema: Access schema using |c3-short| example -------------------------------------- **Grant access to schemas from the Control Center UI** To provide minimal access to the |sr| for |c3-short| users, grant the ``DeveloperRead`` role on the internal ``_schemas`` topic. .. code:: bash confluent iam rbac role-binding create \ --principal User: \ --resource Subject: \ --role DeveloperRead \ --kafka-cluster-id \ --schema-registry-cluster-id .. _c3_rbac_known_issues: Known issues with |rbac| in |c3-short| ###################################### .. _c3_KI_cluster connections: |c3-short| connections to external clusters ------------------------------------------- **Direct access to each external cluster is required** When |rbac| is enabled, |c3-short| requires management to be enabled on each cluster. This means that metrics reporters and interceptors that are configured must have a direct connection for |c3-short| 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 :ref:`configuration example `. .. important:: There are additional configurations required for metrics reporters and interceptors when |rbac| is enabled. For more information, see :ref:`Configure RBAC for the Confluent Metrics Reporter ` and :ref:`interceptor_rbac`. .. _c3_KI_service_account: |c3-short| |rbac-sa| role ------------------------- **The principal for Control Center requires SystemAdmin access** The |c3-short| 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 :ref:`consumer group alerts for consumer lag `. The consumer lag offsets are currently not obtained from metrics reporters. .. _c3_KI_ksql_connect: |kconnect| 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 :ref:`Connect ` or :ref:`ksqlDB ` in |c3-short|, a user requires access to the backing |ak| clusters: - If users don't have permission on the |ak| cluster and they'd like to use |kconnect| in |c3-short|, 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 |ak| cluster. To be able to view |ksqldb| in the |c3-short| web interface, grant users access to the topics they need to query. In both these cases, granting users access to the backing |ak| clusters allows them to access the |kconnect| and |ksqldb| pages in |c3-short|. .. _c3_trouble_rbac: Troubleshoot |rbac| in |c3-short| ################################# **Issue:** Get an access message when trying to view streams monitoring data in the **Topics** -> :ref:`Consumption panel `. This applies to the % message consumed chart and the end-to-end latency chart. .. figure:: ../../images/c3-rbac-cg-chart-perms.png :scale: 50 :alt: 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. .. _c3_disable_rbac: Disable |rbac| ############## All components interacting with |c3-short| in your environment must disable |rbac|. To disable |rbac| in |c3-short|, comment out the ``confluent.controlcenter.metadata.urls`` setting and restart |c3-short|.