Authorization using Role-Based Access Control¶
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.
Role-based access control (RBAC) is a method for controlling system access based on roles assigned to users within an organization. RBAC is defined around predefined roles and the privileges associated with those roles (also known as role bindings). Roles are a collection of permissions that you can bind to a resource; this binding allows the privileges associated with that role to be performed on that resource. You must grant the role to a principal at the time you bind a resource to the role.
Using RBAC, you can manage who has access to specific Confluent Platform resources, and the actions a user can perform within that resource. RBAC leverages the Confluent Platform Metadata Service to configure and manage your RBAC implementation from a centralized configuration context, thereby simplifying access management across Confluent Platform resources.
Before implementing RBAC you should evaluate the security needs of the users in your organization and, based on the resources they require to perform their duties, group users into roles that satisfy those requirements. See RBAC Role Use Cases for an example of this planning task. It is a best practice to limit users to the minimum required role necessary for them to complete their assigned tasks.
Like ACLs, RBAC uses principals, so you can associate whatever principal a client is using with an RBAC role, which is authorized by the Confluent Server Authorizer to communicate with both RBAC and ACLs. For details about the Confluent Server Authorizer, see Confluent Server Authorizer. RBAC roles do not support DENY rules, and there is no difference in the way you create and use Kafka ACLs while also using RBAC; rather, RBAC serves as an additional enforcement layer.
RBAC helps you:
- Manage security access across the Confluent Platform (Kafka, KSQL, Connect, Schema Registry, Confluent Control Center) using granular permissions to control user and group access. For example, with RBAC you can specify permissions for each connector in a cluster, making it easier and quicker to get multiple connectors 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: the MDS, a Kafka cluster, Connect, KSQL, Schema Registry clusters, and a single instance of 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; each user can be assigned multiple roles. Certain
privileged users (such as the
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_, thereby making it easier for them to manage
the resources with which they are most familiar.
User administrators can add LDAP users and groups, making it quicker and easier to centrally configure authentication and authorization for the various Confluent Platform resources used in an organization.
With RBAC, the user administrator can map roles to LDAP users and groups that are scoped to specific resources (role binding). After a role binding is set using the CLI, 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.
Confluent Platform Metadata Service¶
MDS is the primary mechanism by which RBAC is implemented, and offers a single, centralized configuration context that once set up for a cluster, saves administrators from the complex and time-consuming task of defining and assigning roles for each resource on an individual basis. The Confluent Platform MDS binds and enforces a Kafka cluster configuration across different resources (such as topics, connectors, and schemas). The Metadata Service (MDS) acts as the central authority for all authorization and authentication data. You must configure each Kafka broker in the MDS cluster with MDS.
MDS provides ease of use and convenience in the implementation of role-based access control (RBAC); it can also scale so that you can use this same non-binding permissions model to offer other types of security.
Running on a Kafka broker, MDS is also integrated with LDAP to provide authentication and refreshable bearer tokens for impersonation. The MDS is also the master of record for role binding. For details about configuring LDAP integration with RBAC, see Configuring the LDAP Authorizer and Configuring Authentication Using LDAP. For details about configuring MDS, see Configure Metadata Service (MDS).
RBAC and ACLs¶
RBAC serves as an additional authorization enforcement layer on top of ACLs, and does not change the way ACLs are created or managed. When considering whether to use RBAC or ACLs for access control, it is suggested you use RBAC as the default because of its ease of use and manageability at scale, but for edge cases where you need to have more granular access control, or wish to explicitly deny access, ACLs may make more sense. 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; prior to 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, which is not possible if solely using ACLs.
Prior to 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
For example, say you are responsible for managing user access to 1000 topics. Using RBAC, you could grant
ResourceOwnerto 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.
The following terms are used in RBAC:
- 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 (e.g. topics). Access control enables secure access to Confluent Platform services and resources.
- User account
- A real user who can access Confluent Platform resources and has username, password, email address, and other information. This is tied to a specific user. Users can change or expand roles, or be terminated. A user can also have multiple roles.
- User group
- Groups are used to collect user accounts, computer accounts, and other groups into manageable units. Working with groups instead of with individual users helps simplify maintenance and administration.
- The identity (the user ID and password) of a user requesting permission to perform a specific action on a specific resource. Principals can be authenticated or non-authenticated (ANONYMOUS).
- A set of permissions that you can bind to a resource; this binding allows the privileges associated with that role to be performed on that resource. You must grant the role to a principal at the time you bind a resource to the role.
- 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.
- A resource can be a Apache Kafka® topic, consumer group, transactionalID, cluster, Schema Registry, KSQL, and any other Confluent Platform component.
RBAC Error Codes¶
The following user access HTTP error codes are in use for RBAC:
In some cases when a user’s credentials are correct, but the user does not have the correct permissions, you would expect a 403 error instead of a 404 error. In such cases, error code 403 is returned to avoid exposing details about specific resources.
- User login failed due to missing or insufficient credentials (user lacks sufficient permissions).
- User credentials may be correct, but login failed because user does not have required permissions for a specific resource (such as Schema Registry or Connect).
- Not Found: user has correct credentials and access to a resource (for example,
the user has the
ResourceOwnerrole), but the resource (such as Connect) doesn’t exist.
Schema Registry has many granular error codes that extend beyond the context of RBAC. See Schema Registry API Reference for descriptions of Schema Registry HTTP errors (for example, 40401) not covered here.