Configure Role-Based Access Control

This feature requires an enterprise license. To get a trial license key or extend your trial period, generate a new trial license key. To purchase a license, contact Redpanda Sales.

If Redpanda has enterprise features enabled and it cannot find a valid license, restrictions apply.

Role-based access control (RBAC) provides a way to configure permissions for provisioned users at scale, and provides a streamlined interface to manage user access to many resources. RBAC works in conjunction with all supported authentication methods.

RBAC overview

RBAC is designed to address the critical challenge of access management at scale. It alleviates the process of manually maintaining and verifying a set of raw permissions (access control lists, or ACLs) for a user base that could contain thousands of users. RBAC provides a method to onboard new employees easier, audit accesses faster, and adapt more readily to evolutions of usage and compliance needs.

Using RBAC, you can define roles to reflect organizational structure or job duties. This approach decouples users and permissions through the assignment of roles. RBAC allows a one-to-many mapping of a given role to many users, dramatically reducing the number of custom policies needed for a resource from one per user, to one per group of users.

RBAC terminology

Under the RBAC framework, you create roles, grant permissions to those roles, and assign the roles to users. When you change the permissions for a given role, all users with that role automatically gain the modified permissions. You grant or deny permissions for a role by creating an ACL and specifying the RBAC role as either allowed or denied respectively.

Redpanda treats all users as security principals and defines them with the Type:Name syntax (for example, User:mike). You can omit the Type when defining a principal and Redpanda will assume the User: type. All examples here use the full syntax for clarity.

See access control lists for more information on defining ACLs and working with principals.

Roles

A role is a named collection of ACLs which may have users (security principals) assigned to it. You can assign any number of roles to a given user. When installing a new Redpanda cluster, no roles are provisioned by default.

If you want to use RBAC, you must create your first roles using your superuser account, which enables you to create additional roles and assign appropriate ACLs as necessary. See configure authentication for more information on creating and managing superusers.

When performing an upgrade from older versions of Redpanda, all existing SASL/SCRAM users are assigned to the placeholder Users role to help you more readily migrate away from pure ACLs. As a security measure, this default role has no assigned ACLs.

Policy conflicts

You can assign a combination of ACLs and roles to any given principal. ACLs allow permissions, deny permissions, or specify a combination of both. As a result, users may at times have role assignments with conflicting policies. If this situation arises, the user is permitted to perform an operation if and only if:

  • There does not exist a DENY permission matching the operation.

  • There exists an ALLOW permission matching the operation.

RBAC example

Consider a scenario where your software engineers use a set of private topics to publish application update information to users. All your private topics begin with the prefix private-. You might create a new SoftwareEng role to represent the software engineers with write access to these private topics. You would then assign the SoftwareEng role as the allowed role for a new ACL specifying read and write permissions to private-*. Using a wildcard includes all existing private topics and any new ones you might create later. You then assign the new role to John and Jane, your two software engineers who will write messages to this topic. The rpk commands to accomplish this are:

rpk security role create SoftwareEng &&
rpk security acl create --operation read --operation write --topic private-* --allow-role SoftwareEng &&
rpk security role assign SoftwareEng --principal User:john,User:jane
bash

This diagram shows the relationships between users, roles, and ACLs:

RBAC role assignments

Consider the situation where you want to create a new topic, private-software-versions, where users self-report the version of a component they are using. If you were using the ACL authorization mechanism, you would need to assign this ACL to every user in your Redpanda installation. Using RBAC allows you to make one update and apply it to everyone with that role. Adding the write permissions for this topic to the User role means everyone with that role (all authenticated users in the diagram) gains the authorization immediately. For example:

rpk security acl create --operation write --topic private-software-versions --allow-role User
bash

Manage users and roles

Administrators can manage RBAC configurations with rpk, the Redpanda Admin API, or Redpanda Console.

Create a role

Creating a new role is a two-step process. First you define the role, giving it a unique and descriptive name. Second, you assign one or more ACLs to allow or deny access for the new role. This defines the permissions that are inherited by all users assigned to the role. It is possible to have an empty role with no ACLs assigned.

To create a new role, run:

rpk security role create <role_name>
bash

After the role is created, administrators create new ACLs and assign this role either allow or deny permissions. For example:

rpk security acl create ... --allow-role <role_name>
bash

Example of creating a new role named red:

rpk security role create red
bash
Successfully created role "red"
bash

Delete a role

When a role is deleted, Redpanda carries out the following actions automatically:

  • All role ACLs are deleted.

  • All users' assignments to the role are removed.

Redpanda lists all impacted ACLs and role assignments when running this command. You receive a prompt to confirm the deletion action. The delete operation is irreversible.

To delete a role, run:

rpk security role delete <role-name>
bash

Example of deleting a role named red:

rpk security role delete red
bash
PERMISSIONS
===========
PRINCIPAL         HOST  RESOURCE-TYPE  RESOURCE-NAME  RESOURCE-PATTERN-TYPE  OPERATION  PERMISSION  ERROR
RedpandaRole:red  *     TOPIC          books          LITERAL                ALL        ALLOW
RedpandaRole:red  *     TOPIC          videos         LITERAL                ALL        ALLOW

PRINCIPALS
==============
NAME   TYPE
panda  User
? Confirm deletion of role "red"?  This action will remove all associated ACLs and unassign role members Yes
Successfully deleted role "red"
bash

Assign a role

You can assign a role to any security principal. Principals are referred to using the format: Type:Name. Redpanda currently supports only the User type. If you omit the type, Redpanda assumes the User type by default. With this command, you can assign the role to multiple principals at the same time by using a comma separator between each principal.

To assign a role to a principal, run:

rpk security role assign <role-name> --principal <principals>
bash

Example of assigning a role named red:

rpk security role assign red --principal bear,panda
bash
Successfully assigned role "red" to
NAME   PRINCIPAL-TYPE
bear   User
panda  User
bash

Unassign a role

You can remove a role assignment from a security principal without deleting the role. Principals are referred to using the format: Type:Name. Redpanda currently supports only the User type. If you omit the type, Redpanda assumes the User type by default. With this command, you can remove the role from multiple principals at the same time by using a comma separator between each principal.

To remove a role assignment from a principal, run:

rpk security role unassign <role_name> --principal <principals>
bash

Example of unassigning a role named red:

rpk security role unassign red --principal panda
bash
Successfully unassigned role "red" from
NAME   PRINCIPAL-TYPE
panda  User
bash

Edit role permissions

You can add or remove ACLs from any of the roles you have previously created.

To modify an existing role by adding additional ACLs to it, run:

rpk security acl create ... --allow-role <role_name>
bash
rpk security acl create ... --deny-role <role_name>
bash

To use rpk to remove ACLs from a role, run:

rpk security acl delete ... --allow-role <role_name>
rpk security acl delete ... --deny-role <role_name>
bash

When you run rpk security acl delete, Redpanda deletes all ACLs matching the parameters supplied. Make sure to match the exact ACL you want to delete. If you supply only the --allow-role flag, for example, Redpanda will delete every ACL granting that role authorization to a resource.

To list all the ACLs associated with a role, run:

rpk security acl list --allow-role <role_name> --deny-role <role_name>
bash

See also:

List all roles

Redpanda lets you view a list of all existing roles.

To view a list of all actives roles, run:

rpk security role list
bash

Example of listing all roles:

rpk security role list
bash
NAME
red
bash

Describe a role

When managing roles, you may need to review the ACLs the role grants or the list of principals assigned to the role.

To view the details of a given role, run:

rpk security role describe <role_name>
bash

Example of describing a role named red:

rpk security role describe red
bash
PERMISSIONS
===========
PRINCIPAL         HOST  RESOURCE-TYPE  RESOURCE-NAME  RESOURCE-PATTERN-TYPE  OPERATION  PERMISSION  ERROR
RedpandaRole:red  *     TOPIC          books          LITERAL                ALL        ALLOW
RedpandaRole:red  *     TOPIC          videos         LITERAL                ALL        ALLOW

PRINCIPALS
==============
NAME  TYPE
panda User
bash

Suggested reading

Suggested labs

Search all labs