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 addresses the challenge of access management at scale. Instead of managing individual ACLs for each user, RBAC groups permissions into roles that you can assign to multiple users. Roles can reflect organizational structure or job duties. This approach decouples users and permissions, allowing a one-to-many mapping that reduces the number of custom ACLs needed.

Benefits of RBAC:

  • Simplified management: Create roles once, assign to many users

  • Easier onboarding: New employees inherit permissions by role assignment

  • Faster audits: Review permissions by role rather than individual user

  • Better compliance: Roles align with organizational structure and job duties

  • Reduced errors: Fewer individual ACL assignments mean fewer mistakes

Manage roles

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

In Redpanda Console, select Security from the left navigation menu, and then select the Roles tab. After the role is created, you can add users/principals to it.

For rpk, use rpk security. For example, suppose you want to create a DataAnalysts role for users who need to read from analytics topics and write to reporting topics:

# 1. Create the role
rpk security role create DataAnalysts

# 2. Grant read access to analytics topics
rpk security acl create --operation read,describe \
  --topic 'analytics-*' --resource-pattern-type prefixed \
  --allow-role DataAnalysts

# 3. Grant write access to reporting topics
rpk security acl create --operation write,describe \
  --topic 'reports-*' --resource-pattern-type prefixed \
  --allow-role DataAnalysts

# 4. Assign users to the role
rpk security role assign DataAnalysts --principal alice,bob,charlie

# 5. Verify the setup
rpk security role describe DataAnalysts

All three users (alice, bob, charlie) now have identical permissions without managing individual ACLs for each user.

RBAC terminology

Understanding RBAC terminology is essential for effective role management:

Term Definition Example

Role

A named collection of ACLs that can be assigned to users

DataEngineers, ApplicationDevelopers, ReadOnlyUsers

Principal

A user account in the system (same as ACL principals)

User:alice, User:bob, User:analytics-service

Permission

An ACL rule that allows or denies specific operations

ALLOW READ on topic:sensor-data, DENY DELETE on cluster

Assignment

The association between a user and one or more roles

User alice has roles DataEngineers and TopicAdmins

RBAC workflow:

  1. Create roles: Define roles that match your organizational needs

  2. Grant permissions: Create ACLs specifying the role as allowed/denied

  3. Assign users: Associate users with appropriate roles

  4. Automatic inheritance: Users gain all permissions from their assigned roles

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

You can assign any number of roles to a given user. When installing a new Redpanda cluster, no roles are provisioned by default.

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 User 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.

Permission resolution rules:

A user is permitted to perform an operation if and only if:

  1. No DENY permission exists matching the operation

  2. An ALLOW permission exists matching the operation

Examples:

User’s direct ACLs Role-based ACLs Result Explanation

ALLOW READ topic:logs

Role has DENY READ topic:logs

❌ denied

DENY always takes precedence

DENY WRITE topic:sensitive

Role has ALLOW WRITE topic:*

❌ denied

Specific DENY blocks wildcard ALLOW

No direct ACLs

Role has ALLOW READ topic:data

✅ allowed

Role permission applies

ALLOW READ topic:public

No role ACLs for this topic

✅ allowed

Direct permission applies

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

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

RBAC best practices

Follow these recommendations for effective role-based access control:

Role design

  • Use descriptive names: Choose role names that clearly indicate their purpose (DataEngineers, ReadOnlyAnalysts)

  • Follow job functions: Align roles with actual job responsibilities and organizational structure

  • Keep roles focused: Create specific roles rather than overly broad ones (TopicReaders vs SuperUsers)

  • Plan for growth: Design roles that can accommodate new team members and evolving needs

Permission management

  • Start with minimal permissions: Grant only the access required for the role’s function

  • Use wildcards carefully: Prefixed patterns like analytics-* are useful but review regularly

  • Avoid DENY rules: Prefer specific ALLOW rules over complex DENY/ALLOW combinations

  • Document role purpose: Maintain clear documentation about what each role is intended for

Operational guidelines

  • Regular reviews: Audit roles and assignments quarterly to ensure they remain appropriate

  • Least privilege: Users should have the minimum roles needed for their current responsibilities

  • Temporary access: Create time-limited roles for contractors or temporary project access

  • Monitor usage: Track which roles and permissions are actively used vs. dormant

Manage users and roles

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

Common management tasks:

  • Create roles: Define new roles for organizational functions

  • Assign permissions: Add ACLs to roles to define what they can access

  • Assign users: Associate users with appropriate roles

  • Modify roles: Add or remove permissions from existing roles

  • Audit access: Review roles and assignments for compliance

Typical workflow:

  1. Create role

  2. Add ACL permissions

  3. Assign users

  4. Test access

  5. Monitor and adjust

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.

  • rpk

  • Redpanda Console

To create a new role, run:

rpk security role create <role_name>

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>

Example of creating a new role named red:

rpk security role create red
Successfully created role "red"

To create a new role:

  1. From Security on the left navigation menu, select the Roles tab.

  2. Click Create role.

  3. Provide a name for the role and an optional origin host for users to connect from.

  4. Define the permissions (ACLs) for the role. You can create ACLs for clusters, topics, consumer groups, transactional IDs, Schema Registry subjects, and Schema Registry operations.

    You can assign more than one user/principal to the role when creating it.

  5. Click Create.

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.

  • rpk

  • Redpanda Console

To delete a role, run:

rpk security role delete <role-name>

Example of deleting a role named red:

rpk security role delete red
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 (1)
==============
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"

To delete an existing role:

  1. From Security on the left navigation menu, select the Roles tab.

  2. Click the role you want to delete. This shows all currently assigned permissions (ACLs) and principals (users).

  3. Click Delete.

  4. Click Delete.

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.

  • rpk

  • Redpanda Console

To assign a role to a principal, run:

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

Example of assigning a role named red:

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

To assign a role to a principal, edit the role or edit the user.

Option 1: Edit the role

  1. From Security on the left navigation menu, select the Roles tab.

  2. Select the role you want to assign to one or more users/principals.

  3. Click Edit.

  4. Below the list of permissions, find the Principals section. You can add any number of users/principals to the role. After listing all new users/principals, click Update.

Option 2: Edit the user

  1. From Security on the left navigation menu, select the Users tab.

  2. Select the user you want to assign one or more roles to.

  3. In the Assign roles input field, select the roles you want to add to this user.

  4. After adding all roles, click Update.

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.

  • rpk

  • Redpanda Console

To remove a role assignment from a principal, run:

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

Example of unassigning a role named red:

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

There are two ways to remove a role from a principal:

Option 1: Edit the role

  1. From Security on the left navigation menu, select the Roles tab.

  2. Select the role you want to remove from one or more principals.

  3. Click Edit.

  4. Below the list of permissions, find the Principals section. Click x beside the name of any principals you want to remove from the role.

  5. After you have removed all needed principals, click Update.

Option 2: Edit the user

  1. From Security on the left navigation menu, select the Users tab.

  2. Select the user you want to remove from one or more roles.

  3. Click x beside the name of any roles you want to remove this user from.

  4. After you have removed the user from all roles, click Update.

Edit role permissions

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

  • rpk

  • Redpanda Console

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

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

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>

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>

See also:

To edit the ACLs for an existing role:

  1. From Security on the left navigation menu, select the Roles tab.

  2. Select the role you want to edit and click Edit.

  3. While editing the role, you can update the optional origin host for users to connect from.

  4. You can add or remove ACLs for the role. As when creating a new role, you can create or modify ACLs for topics, consumer groups, transactional IDs, Schema Registry subjects, and Schema Registry operations.

  5. After making all changes, click Update.

List all roles

Redpanda lets you view a list of all existing roles.

  • rpk

  • Redpanda Console

To view a list of all actives roles, run:

rpk security role list

Example of listing all roles:

rpk security role list
NAME
red

To view all existing roles:

  1. From Security on the left navigation menu, select the Roles tab.

    All roles are listed in a paginated view. You can also filter the view using the input field at the top of the list.

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.

  • rpk

  • Redpanda Console

To view the details of a given role, run:

rpk security role describe <role_name>

Example of describing a role named red:

rpk security role describe red
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 (1)
==============
NAME  TYPE
panda User

To view details of an existing role:

  1. From Security on the left navigation menu, select the Roles tab.

  2. Find the role you want to view and click the role name.

All roles are listed in a paginated view. You can also filter the view using the input field at the top of the list.

Suggested reading

Suggested labs

Search all labs