# Use Role-Based Access Control (RBAC) for Authorization in Confluent Platform Role-based access control (RBAC) controls system access based on the roles you assign to users in an organization. A role is a collection of permissions, and RBAC is built around [predefined roles](rbac-predefined-roles.md#rbac-predefined-roles). You bind a role to a resource to grant the role’s privileges on that resource, and you grant the role to a principal at the same time. Binding a role to a principal and a resource creates a **role binding**. With RBAC, you control who can access specific Confluent Platform resources and which actions users can perform on them. RBAC uses the Confluent Platform [Metadata Service](#metadata-service) (MDS) to manage role bindings from a single, centralized configuration context, which simplifies access management across Confluent Platform resources. Before you set up RBAC, assess the security needs of the users in your organization and group them into roles based on the resources they need to do their work. As a best practice, grant each user the minimum role required to complete their tasks. For an example of this planning, see [RBAC role use cases](rbac-predefined-roles.md#rbac-roles-use-cases). Like access control lists (ACLs), RBAC uses principals. You can associate the principal that a client uses with an RBAC role. The Confluent Server Authorizer authorizes that principal to communicate with both RBAC and ACLs. For details about the Confluent Server Authorizer, see [Configure Confluent Server Authorizer in Confluent Platform](../../csa-introduction.md#confluent-server-authorizer). RBAC roles do not support `DENY` rules. If you already use locally managed Kafka ACLs, you create and use them the same way when you also use RBAC. If you plan to continue using Kafka ACLs, Confluent recommends that you migrate to [centralized ACLs](authorization-acl-with-mds.md#authorization-acl-with-mds), which, like role bindings, store ACL information in MDS. For details about enabling and configuring RBAC, see [Metadata Service Configuration Settings](../../../kafka/configure-mds/mds-configuration.md#mds-configuration-options) and [Configure Metadata Service (MDS) in Confluent Platform](../../../kafka/configure-mds/index.md#rbac-mds-config). ## RBAC benefits RBAC simplifies authorization in Confluent Platform by providing centralized, role-based access control across all components. Key benefits include: * Manage security access across Confluent Platform, including Kafka, ksqlDB, Connect, Schema Registry, Confluent Control Center, and Confluent Platform for Apache Flink® by using granular permissions to control user and group access. For example, with RBAC you can specify permissions for each connector or Flink job in a cluster, making it easier to get multiple workloads up and running. * Manage authorization at scale. Administrators can centrally manage the assignment of predefined roles, and also delegate the responsibility of managing access and permissions to the different departments or business units who are the true owners and most familiar with those resources. * Centrally manage authentication and authorization for multiple clusters, which includes: MDS, Kafka clusters, Connect, ksqlDB, Schema Registry clusters, Confluent Platform for Apache Flink applications, and a single Confluent Control Center. ## How RBAC works Predefined role assignments determine who can access specific Confluent Platform resources, and what actions an individual user can perform within that resource. An administrator assigns predefined roles to users and groups on various resources. Each user can be assigned multiple roles on each resource. Certain privileged users (such as the `UserAdmin` or `SystemAdmin`) assign roles to users and groups, and then map specific resources to those user roles. For example, a `ResourceOwner` in the finance department can grant department members access to all topics that use the prefix `finance_`, which makes it easier for them to manage the resources that they are the most familiar with. User administrators can manage users and groups from LDAP or an OAuth/OpenID Connect (OIDC) identity provider, which simplifies centralized configuration of authentication and authorization for Confluent Platform resources used in an organization.  With RBAC, the user administrator can map roles to users and groups that are scoped to specific resources (role binding). After a role binding is set using the Confluent CLI [confluent iam rbac role-binding create](https://docs.confluent.io/confluent-cli/current/command-reference/iam/rbac/role-binding/confluent_iam_rbac_role-binding_create.html) command, users can’t go to an API or Confluent Control Center to bypass and get access to resources. Binding roles to groups enables client administrators to avoid having to grant explicit access to each user across every component. For details about viewing role bindings, refer to Confluent CLI [confluent iam rbac role-binding list](https://docs.confluent.io/confluent-cli/current/command-reference/iam/rbac/role-binding/confluent_iam_rbac_role-binding_list.html) command. Note that role binding does not support wildcard matching in principal names. For details, refer to [Wildcard principals](../acls/overview.md#acl-wildcard-principals). #### NOTE When setting up role bindings (`confluent iam rbac role-binding create`), if you need to troubleshoot, you can view audit logs to identify authorization events for specific principals, resources, or operations. For details, refer to [View audit logs on the fly](../../compliance/audit-logs/audit-logs-properties-config.md#view-audit-logs-on-the-fly). Confluent Platform cluster registry provides a way for cluster administrators to centrally register Kafka clusters in MDS to enable a more user-friendly RBAC role binding experience. For details, refer to [Cluster Registry in Confluent Platform](../../cluster-registry.md#cluster-registry). ## Confluent Platform Metadata Service Metadata Service (MDS) is the centralized authorization service that implements RBAC in Confluent Platform. MDS provides a single configuration context for managing role bindings across Kafka clusters, connectors, schemas, and Flink resources, which saves administrators from the complex and time-consuming task of defining and assigning roles for each resource. The Confluent Platform MDS binds and enforces a Kafka cluster configuration across different resources such as topics, connectors, schemas, and across different Flink resources such as `FlinkApplications`, `FlinkEnvironments`, and more. MDS acts as the central authority for all authorization and authentication data, ensuring consistent enforcement of permissions across the entire Confluent ecosystem. You must configure every Kafka broker in the MDS-managed cluster to use that MDS instance, which also controls access to integrated services like Flink. Running on a Confluent Server broker, MDS authenticates users and provides refreshable bearer tokens for impersonation. MDS can get user and group information from LDAP, an OAuth/OIDC identity provider, or both. MDS also serves as the system of record for role bindings. For details about configuring LDAP with RBAC, see [Configure LDAP Group-Based Authorization in Confluent Platform](../ldap/configure.md#kafka-ldap-config) and [Configure LDAP Authentication](../../../kafka/configure-mds/ldap-auth-mds.md#ldap-auth-mds). For details about configuring MDS to use OAuth, see [Configure Metadata Service (MDS) for OAuth Authentication in Confluent Platform](../../authentication/oauth-oidc/configure-mds.md#configure-mds-for-oauth). For details about configuring MDS, see [Configure Metadata Service (MDS) in Confluent Platform](../../../kafka/configure-mds/index.md#rbac-mds-config). ## RBAC and ACLs RBAC serves as an additional authorization enforcement layer on top of [ACLs](../acls/overview.md#kafka-authorization), and does not change the way ACLs are created or managed. The following table summarizes when to use each approach. | Scenario | Recommended approach | |----------------------------------------------------------|-----------------------------------------------------| | Default access control | RBAC (centralized, easier to manage at scale) | | Granular per-resource access control | ACLs | | Explicit deny rules | ACLs | | Connector access control | RBAC (required; ACLs cannot grant connector access) | | Consistent auth across all Confluent Platform components | RBAC | For example, you could use RBAC to allow access for a group of users, but an ACL to deny access for a particular member of that group. RBAC adds an additional authorization mechanism that addresses the following authorization challenges when using ACLs: * Without RBAC, you cannot use ACLs to grant access to connectors. With RBAC, each connector has its own principal that identifies access to resources. Users have access only to connectors on which they have explicitly been granted permission. If you require connector access control, RBAC is essential. * RBAC provides the ability to offer Confluent Control Center users granular access to resources. Before RBAC, any user with access to Confluent Control Center had full or read-only access to topics and resources. If granular access control in Confluent Control Center is a requirement, RBAC is recommended. * RBAC provides a consistent authentication and authorization mechanism for users access across the entire Confluent Platform, including Flink SQL applications and jobs, which is not possible if solely using ACLs. * Before RBAC, the creation and management of ACLs could be difficult to manage and maintain, and in organizations with thousands of resources and users, ACL setup could take a long time. With RBAC, the delegation of responsibility to various resources is managed using the `ResourceOwner` role. For example, say you are responsible for managing user access to 1000 topics. Using RBAC, you could grant `ResourceOwner` to other users to manage the topics owned by specific business units, and in turn, those users could manage access for others within their own teams. Using ACLs in this scenario, you would need to centrally manage access to all the topics, which would be a time and resource-intensive task. * Finally, if you are managing multiple Flink jobs or SQL endpoints, RBAC enables you to delegate job-level control to team leads or data engineers while maintaining centralized oversight. This is something not feasible with ACLs alone. ## RBAC authentication options The authentication method you use with RBAC depends on the Confluent Platform component, as described in this section. The authentication options in use before implementing RBAC might require additional configuration, or you might need to use a different authentication method altogether. #### IMPORTANT Confluent Platform components that have a REST endpoint (such as Schema Registry and Confluent Control Center), don’t support using a principal derived from mutual TLS (mTLS) authentication when using RBAC. So if you relied on TLS/SSL certificate authentication across Confluent Platform before configuring RBAC, when using RBAC you must also provide HTTP Basic Auth credentials (such as LDAP user) to authenticate against other components or REST API endpoints. HTTP Basic Auth presents login credentials to other Confluent Platform components and the component uses those credentials to get an OAuth token for the user with MDS (which validates the credentials against LDAP) and then the component uses the OAuth token to make authorization requests to MDS. You must specify the bearer token for [Use HTTP Basic Authentication in Confluent Platform](../../authentication/http-basic-auth/overview.md#http-basic-auth) and more specifically, must specify `basic.auth.user.info` and `basic.auth.credentials.source`. When configuring Confluent Platform components (for example, Confluent Control Center, ksqlDB, and REST Proxy) for RBAC, use OAuth for authentication with MDS and Kafka clusters. For authentication with other Confluent Platform components such as Confluent Platform for Apache Flink, see [Use HTTP Basic Authentication in Confluent Platform](../../authentication/http-basic-auth/overview.md#http-basic-auth). For Confluent Platform components with REST endpoints (such as Schema Registry and Confluent Control Center), you must use HTTP Basic Authentication to authenticate with MDS. For details, refer to [Configure RBAC using the REST API in Confluent Platform](rbac-config-using-rest-api.md#rbac-config-using-rest-api). You cannot use [principal propagation](../../../kafka-rest/production-deployment/rest-proxy/security.md#kafka-rest-security-propagation) with Confluent Platform components (for example, REST Proxy) that have a REST endpoint that requires RBAC. When using RBAC with Schema Registry and Connect, you can use any of the [authentication methods](../../authentication/overview.md#authentication-overview) supported by Confluent Platform to communicate with Kafka clusters and MDS. For authentication with other Confluent Platform components, see [Use HTTP Basic Authentication in Confluent Platform](../../authentication/http-basic-auth/overview.md#http-basic-auth). When using RBAC with Kafka clients, you can use any of the [authentication methods](../../authentication/overview.md#authentication-overview) supported by Confluent Platform *except OAUTHBEARER*. For details, refer to [Configure Clients for SASL/OAUTHBEARER Authentication in Confluent Platform](../../authentication/sasl/oauthbearer/configure-clients.md#security-sasl-rbac-oauthbearer-clientconfig).  ## Terminology The following terms are used in RBAC: Role-based access control (RBAC) : With RBAC, permissions are associated with roles, and users or groups are assigned to appropriate roles. Roles are defined according to job competency, authority, and responsibility within the enterprise. Users and groups are easily reassigned from one role to another. Permissions assigned to roles tend to change relatively slowly compared with changes in user membership of roles. Access control : Access is the ability of an individual user or application to perform a specific task, such as view, create, or modify a resource (for example, topics). Access control enables secure access to Confluent Platform services and resources. Principal : The identity of a user or software requesting permission to perform a specific action on a specific resource. Principals can be authenticated or non-authenticated (ANONYMOUS). User principal : A single identity tied to a specific user or piece of software. Group principal : A shared identity that groups together a list of user principals or other group principals. Role : A Confluent-defined job function that is assigned a set of permissions required to perform specific actions or operations on Confluent resources. Each role is bound to a principal and Confluent resources. Resource : A resource can be an Apache Kafka® topic, consumer group, transactionalID, cluster, Schema Registry, ksqlDB, and any other Confluent Platform component. Role binding : A principal-role-resource combination that allows a principal to perform operations on a resource or set of resources as defined by the role. ## RBAC limitations RBAC has recommended limits on role bindings and API calls. Exceeding these limits can degrade performance. | Resource | Limit | |-------------------------------------------------------------------------------|------------------------| | Role bindings | 1000 (soft limit) | | Requests per second (RPS) API calls to add, remove, or look up role bindings | 15 | | [Centralized ACLs](authorization-acl-with-mds.md#centralized-acl-limitations) | Up to 1000 per cluster | #### IMPORTANT The user ID specified in group role bindings is case-specific, and must match the case specified in the AD record. Also note that when logging in as a super user, the login ID is also case-specific and must match the case specified for the user ID in role bindings. ## RBAC error codes The following user access HTTP error codes are in use for RBAC: #### NOTE In some cases when a user’s credentials are correct, but the user does not have the correct permissions, you would expect a 404 error when querying a nonexistent resource. In such cases, error code 403 is returned to avoid exposing details about specific resources. 401 : User login failed because of missing or insufficient credentials (user lacks sufficient permissions). 403 : User credentials might be correct, but login failed because user does not have required permissions for a specific resource (such as Schema Registry or Connect). 404 : Not Found: user has correct credentials and access to a resource (for example, the user has the `ResourceOwner` role), but the resource (such as Connect) doesn’t exist. 502 : MDS is unreachable. Contact your security administrator. Schema Registry has many granular error codes that extend beyond the context of RBAC. See [Schema Registry API Reference for Confluent Platform](../../../schema-registry/develop/api.md#schemaregistry-api) for descriptions of Schema Registry HTTP errors (for example, 40401) not covered here. ## RBAC implementation checklist Use this checklist to install and configure RBAC in Confluent Platform. Ansible offers a simpler way to configure and deploy RBAC and MDS. Refer to [Ansible RBAC settings](https://docs.confluent.io/ansible/current/ansible-authorize.html) for details. To set up RBAC: * [Install Confluent Platform](../../../installation/overview.md#installation), including the `confluent-server` commercial component. For more information, see [Migrate Confluent Platform to Confluent Server](../../../installation/migrate-confluent-server.md#migrate-confluent-server). * Work with your security team to evaluate the needs of the users in your organization and, based on the resources they require to perform their duties, identify which roles should be assigned to users and groups. For a description of some typical use cases and required roles for each, refer to [RBAC role use cases](rbac-predefined-roles.md#rbac-roles-use-cases). To bootstrap RBAC, you must identify an ACL-level `super.user` in the Confluent Server broker’s `server.properties` file on the cluster that hosts MDS. This `super.user` can then assign the SystemAdmin role to another user who can create the required clusters and scope the required role bindings for users and groups. Be sure to identify which user will serve as a bootstrap `super.user`. For details, refer to [Use Predefined RBAC Roles in Confluent Platform](rbac-predefined-roles.md#rbac-predefined-roles). * [Configure the Metadata Service (MDS)](../../../kafka/configure-mds/index.md#rbac-mds-config). MDS implements the core RBAC capabilities and communicates with [LDAP](../../../kafka/configure-mds/ldap-auth-mds.md#ldap-auth-mds) or an OAuth/OIDC identity provider (see [Configure Metadata Service (MDS) for OAuth Authentication in Confluent Platform](../../authentication/oauth-oidc/configure-mds.md#configure-mds-for-oauth)) to get user and group information and authenticate users. After configuring MDS, you can perform role bindings and configure other Confluent Platform components. Refer to [Configure the LDAP identity provider](../../../kafka/configure-mds/index.md#mds-id-provider-settings) to view an LDAP configuration for MDS. * After you have determined which roles must be assigned to users and groups, create the appropriate [role bindings](rbac-cli-quickstart.md#rbac-rolebinding-sysadmin-role) for users to access the resources (for example, Schema Registry, ksqlDB, Connect, and Confluent Control Center) they require to perform their duties. * Confirm the user and group roles you defined using the [confluent iam rbac role-binding list](https://docs.confluent.io/confluent-cli/current/command-reference/iam/rbac/role-binding/confluent_iam_rbac_role-binding_list.html) command. * Configure Confluent Platform components to communicate with MDS for authentication and authorization. For details, see: * [Configure RBAC for Control Center on Confluent Platform](/control-center/current/security/c3-rbac.html) * [Kafka Connect and RBAC for Confluent Platform](../../../connect/rbac-index.md#connect-rbac-index) * [Deploy Secure ksqlDB with RBAC in Confluent Platform](ksql-rbac.md#ksql-rbac) * [Configure Role-Based Access Control for Schema Registry in Confluent Platform](../../../schema-registry/security/rbac-schema-registry.md#schemaregistry-rbac) * [Configure RBAC for REST Proxy](../../../kafka-rest/production-deployment/rest-proxy/security.md#rbac-rest-proxy-security) * [Configure RBAC using the REST API in Confluent Platform](rbac-config-using-rest-api.md#rbac-config-using-rest-api) ## RBAC demo for Confluent Platform To see a working example of RBAC, check out [Confluent Platform demo](../../../tutorials/cp-demo/index.md#cp-demo). This demo and accompanying tutorial show users how to deploy an Apache Kafka® event streaming application. All the components in the demo have security enabled end-to-end, including RBAC.