# Configure RBAC in the Data Plane > For the complete documentation index, see [llms.txt](https://docs.redpanda.com/llms.txt). Component-specific: [cloud-data-platform-full.txt](https://docs.redpanda.com/cloud-data-platform-full.txt) --- title: Configure RBAC in the Data Plane latest-operator-version: v26.1.4 latest-console-tag: v3.7.3 latest-connect-version: 4.93.0 latest-redpanda-tag: v26.1.9 docname: authorization/rbac/rbac_dp page-component-name: cloud-data-platform page-version: master page-component-version: master page-component-title: Cloud page-relative-src-path: authorization/rbac/rbac_dp.adoc page-edit-url: https://github.com/redpanda-data/cloud-docs/edit/main/modules/security/pages/authorization/rbac/rbac_dp.adoc description: Configure RBAC to manage access for provisioned users to cluster-level resources, like topics and consumer groups. page-topic-type: how-to learning-objective-1: Configure cluster-level permissions for provisioned users learning-objective-2: Assign roles to users in the data plane learning-objective-3: Use RBAC with supported authentication methods page-git-created-date: "2025-02-26" page-git-modified-date: "2026-05-26" --- > 📝 **NOTE** > > This feature is available for BYOC and Dedicated clusters. Use role-based access control (RBAC) in the [data plane](https://docs.redpanda.com/cloud-data-platform/reference/glossary/#data-plane) to configure cluster-level permissions for provisioned users at scale. After reading this page, you will be able to: - Configure cluster-level permissions for provisioned users - Assign roles to users in the data plane - Use RBAC with supported authentication methods ## [](#rbac-overview)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)Manage roles Administrators can manage RBAC configurations with `rpk` or Redpanda Cloud. In Redpanda Cloud, 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`](https://docs.redpanda.com/cloud-data-platform/reference/rpk/rpk-security/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: ```bash # 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)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](https://docs.redpanda.com/cloud-data-platform/security/authorization/acl/) for more information on defining ACLs and working with principals. ### [](#roles)Roles You can assign any number of roles to a given user. When installing a new Redpanda cluster, no roles are provisioned by default. 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)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-best-practices)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)Manage users and roles Administrators can manage RBAC configurations with `rpk` or Redpanda Cloud. 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)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 To create a new role, run: ```bash rpk security role create ``` After the role is created, administrators create new ACLs and assign this role either allow or deny permissions. For example: ```bash rpk security acl create ... --allow-role ``` Example of creating a new role named `red`: ```bash rpk security role create red ``` ```bash Successfully created role "red" ``` #### Redpanda Cloud 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. > 💡 **TIP** > > You can assign more than one user/principal to the role when creating it. 5. Click **Create**. ### [](#delete-a-role)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 To delete a role, run: ```bash rpk security role delete ``` Example of deleting a role named `red`: ```bash 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 (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" ``` #### Redpanda Cloud 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)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 To assign a role to a principal, run: ```bash rpk security role assign --principal ``` Example of assigning a role named `red`: ```bash rpk security role assign red --principal bear,panda ``` ```bash Successfully assigned role "red" to NAME PRINCIPAL-TYPE bear User panda User ``` #### Redpanda Cloud 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)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 To remove a role assignment from a principal, run: ```bash rpk security role unassign --principal ``` Example of unassigning a role named `red`: ```bash rpk security role unassign red --principal panda ``` ```bash Successfully unassigned role "red" from NAME PRINCIPAL-TYPE panda User ``` #### Redpanda Cloud 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)Edit role permissions You can add or remove ACLs from any of the roles you have previously created. #### rpk To modify an existing role by adding additional ACLs to it, run: ```bash rpk security acl create ... --allow-role ``` ```bash rpk security acl create ... --deny-role ``` To use `rpk` to remove ACLs from a role, run: ```bash rpk security acl delete ... --allow-role rpk security acl delete ... --deny-role ``` 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: ```bash rpk security acl list --allow-role --deny-role ``` See also: - [rpk security acl create](https://docs.redpanda.com/cloud-data-platform/reference/rpk/rpk-security/rpk-security-acl-create/) - [rpk security acl delete](https://docs.redpanda.com/cloud-data-platform/reference/rpk/rpk-security/rpk-security-acl-delete/) - [rpk security acl list](https://docs.redpanda.com/cloud-data-platform/reference/rpk/rpk-security/rpk-security-acl-list/) #### Redpanda Cloud 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)List all roles Redpanda lets you view a list of all existing roles. #### rpk To view a list of all actives roles, run: ```bash rpk security role list ``` Example of listing all roles: ```bash rpk security role list ``` ```bash NAME red ``` #### Redpanda Cloud 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)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 To view the details of a given role, run: ```bash rpk security role describe ``` Example of describing a role named `red`: ```bash 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 (1) ============== NAME TYPE panda User ``` #### Redpanda Cloud 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 reading - [`rpk security`](https://docs.redpanda.com/cloud-data-platform/reference/rpk/rpk-security/rpk-security/) - Complete security command reference - [`rpk security acl`](https://docs.redpanda.com/cloud-data-platform/reference/rpk/rpk-security/rpk-security-acl/) - ACL management commands - [Access Control Lists](https://docs.redpanda.com/cloud-data-platform/security/authorization/acl/) - Understanding the underlying ACL system ## [](#suggested-reading-2)Suggested reading - [Configure RBAC in the Control Plane](https://docs.redpanda.com/cloud-data-platform/security/authorization/rbac/rbac/) - [Configure GBAC in the Control Plane](https://docs.redpanda.com/cloud-data-platform/security/authorization/gbac/gbac/) - [Configure GBAC in the Data Plane](https://docs.redpanda.com/cloud-data-platform/security/authorization/gbac/gbac_dp/)