DOC-2123: Update Console ACL UI references for new atomic-ACL design

modules/console/pages/index.adoc

@@ -34,7 +34,8 @@ image::topic.png[]
 
 Manage Redpanda users and control who has access to Redpanda Console:
 
-* *Visual ACL management*: Create, view, and manage ACLs, ensuring that your data is secure and access is properly controlled.
+* *Visual ACL management*: Create, view, and edit individual ACLs, with role-inherited permissions shown inline so you can see exactly what each principal is authorized to do.
+* *Role-based access control*: Group permissions into roles and assign roles to users or OIDC groups; manage role membership from a dedicated role page.
 * *Rotate credentials*: Update user and service account passwords to maintain security without downtime.
 * *Identity provider integration*: For enterprise users, Redpanda Console integrates with identity providers (IdPs) for single sign-on (SSO), making user management straightforward and secure.
 

modules/deploy/pages/kafka-connect/deploy-kafka-connect.adoc

@@ -292,7 +292,7 @@ curl localhost:8083/
 
 To connect to a Redpanda Cloud cluster with Docker Compose:
 
-. Use `rpk` or Redpanda Console (*Security* tab) to create a Redpanda user.
+. Use `rpk` or Redpanda Console (*Security* > *Users*) to create a Redpanda user.
 . Create ACLs for the user.
 . Set the username in the `CONNECT_SASL_USERNAME` property.
 . Create a file containing the user password (for example, in the path `passwords/redpanda-password/password`). Specify this path in the `CONNECT_SASL_PASSWORD_FILE` property.

modules/get-started/pages/quick-start.adoc

@@ -286,13 +286,19 @@ image::console:user.png[]
 
 Click *Done*, and you see a new user called Sasha. This user has no permissions yet. To set permissions on the `transactions` topic:
 
-. On the Access control page, open to the *Roles* tab.
-. Click *Create role*.
-. Enter "transaction-managers" as the role name.
-. In the topic selector dropdown, select *Literal* and enter "transactions" in the input field.
-. Under *Operations*, click the *All* dropdown and select *Allow*.
-. Scroll down to the bottom of the page and under *Principals* select *Sasha* from the dropdown.
-. Click *Create*.
+. From *Security* in the left navigation menu, go to *Roles*.
+. Click *Create role*, enter "transaction-managers" as the role name, and click *Create*. The role's detail page opens with empty *ACLs* and *Principals* sections.
+. Under *ACLs*, click *+ Add ACL* and define a rule:
++
+- *Resource Type*: Topic
+- *Pattern Type*: Literal
+- *Resource Name*: `transactions`
+- *Operation*: All
+- *Permission*: Allow
+- *Host*: `*`
++
+Then click *Add ACL*.
+. Under *Principals*, in the *Add a principal* search, select *Sasha*. The assignment takes effect immediately.
 
 Now Sasha has full access only to the topic called transactions.
 

modules/manage/pages/security/authorization/acl.adoc

@@ -32,11 +32,26 @@ ACLs control access by defining:
 
 ACLs work with SASL/SCRAM and mTLS authentication methods to provide comprehensive security.
 
+[[manage-acls]]
 == Manage ACLs
 
 You can create and manage ACLs in the following ways:
 
-* *{ui}*: Select *Security* from the left navigation menu, select the *ACLs* tab. After the ACL is created, you can add users or roles to it. 
+[[create-first-acl]]
+* *{ui}*: From *Security* in the left navigation menu, you can reach ACLs two ways:
++
+** *Permissions* tab: a unified, cluster-wide view of every principal that has at least one ACL, showing direct ACL counts and ACLs inherited from roles. A red badge marks any principal that has Deny rules. From this tab you can:
++
+*** Expand a principal's row to see every ACL applied to it: direct rules first, then groups labeled *VIA ROLE: <role-name>* listing the ACLs inherited from each role.
+*** Search across principals, resources, and roles to filter the list.
+*** Click *Create ACL* to add a rule from scratch.
+** *Users* or *Roles* tab: open the principal you want to manage, and use the *ACLs* section on its detail page.
++
+On a principal's detail page, the *ACLs* section shows one row per rule, with columns for type, resource, operation, permission, and host. It offers three actions:
++
+** Click *+ Add ACL* to define a single rule by specifying its resource type, pattern type, resource name, operation, permission, and host.
+** Click *Allow all operations* to grant full wildcard access across all resource types in a single step. Use this for testing only; it is too broad for production.
+** Select one or more rows with the checkboxes and click *Delete selected* to remove ACLs in bulk.
 * *Command Line*: Use the `rpk` command-line tool for programmatic management.
 +
 For example, suppose you want to create a user named `analytics-user` who can read from topics starting with `logs-` and write to a topic called `processed-data`:

modules/manage/partials/gbac-assign-group-role.adoc

@@ -2,22 +2,14 @@ To assign a group to a role in {ui}:
 
 . From *Security* on the left navigation menu, select the *Roles* tab.
 
-. Select the role you want to assign the group to.
+. Click the role you want to assign the group to.
 
-. Click *Edit*.
-
-. For *User/principal*, enter the group name using the `Group:<name>` format. For example, `Group:engineering`.
-
-. Click *Update*.
+. Under *Principals*, use the *Add a principal* search to add an entry in the `Group:<name>` format. For example, `Group:engineering`. The assignment takes effect immediately.
 
 To remove a group from a role:
 
 . From *Security* on the left navigation menu, select the *Roles* tab.
 
-. Select the role that has the group assignment you want to remove.
-
-. Click *Edit*.
-
-. For *User/principal*, remove the `Group:<name>` entry.
+. Click the role that has the group assignment you want to remove.
 
-. Click *Update*.
+. Under *Principals*, click the trash icon next to the `Group:<name>` entry. The removal takes effect immediately.

modules/manage/partials/gbac-create-group-acl.adoc

@@ -2,12 +2,10 @@ In {ui}, group-based ACLs are managed through roles. To create an ACL for an OID
 
 . From *Security* on the left navigation menu, select the *Roles* tab.
 
-. Click *Create role* to open the role creation form, or select an existing role and click *Edit*.
+. Either click *Create role* (provide a name, click *Create*) or click an existing role to open its detail page.
 
-. For *User/principal*, enter the group principal using the `Group:<name>` format. For example, `Group:engineering`.
+. Under *Principals*, use the *Add a principal* search to add the group principal in the `Group:<name>` format. For example, `Group:engineering`.
 
-. Define the permissions (ACLs) you want to grant to users in the group. You can configure ACLs for clusters, topics, consumer groups, transactional IDs, Schema Registry subjects, and Schema Registry operations.
-
-. Click *Create* (or *Update* if editing an existing role).
+. Under *ACLs*, click *+ Add ACL* to add each rule the group needs (resource type, pattern type, resource name, operation, permission, host), or click *Allow all operations* for full wildcard access.
 
 NOTE: {ui} assigns ACLs through roles. To grant permissions to a group, create a role for that group, add the group as a principal, and define the ACLs on the role. To create ACLs with a `Group:` principal directly (without creating a role), use `rpk`.

modules/manage/partials/rbac-assign-role.adoc

@@ -1,21 +1,17 @@
-To assign a role to a principal, edit the role or edit the user.
+You can assign a role from either side: open the role and add a principal, or open the user and assign the role.
 
-Option 1: Edit the role
+Option 1: From the role's detail page
 
 . From *Security* on the left navigation menu, select the *Roles* tab.
 
-. Select the role you want to assign to one or more users/principals.
+. Click the role you want to assign.
 
-. Click *Edit*.
+. Under *Principals*, use the *Add a principal* search to select one or more users (or `Group:<name>` entries for OIDC groups). Each selection takes effect immediately.
 
-. 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
+Option 2: From the user's detail page
 
 . From *Security* on the left navigation menu, select the *Users* tab.
 
-. Select the user you want to assign one or more roles to.
-
-. In the *Assign roles* input field, select the roles you want to add to this user.
+. Click the user you want to assign roles to.
 
-. After adding all roles, click *Update*.
+. Under *Roles*, use the *Assign a role* search to select one or more roles. Each selection takes effect immediately.

modules/manage/partials/rbac-create-role.adoc

@@ -2,13 +2,13 @@ To create a new role:
 
 . From *Security* on the left navigation menu, select the *Roles* tab.
 
-. Click *Create role*.
-
-. Provide a name for the role and an optional origin host for users to connect from.
-
-. 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.
+. Click *Create role*, provide a name for the role, and click *Create*.
++
+The role's detail page opens with empty *ACLs* and *Principals* sections.
 
+. Under *ACLs*, define the role's permissions:
 +
-TIP: You can assign more than one user/principal to the role when creating it.
+** Click *+ Add ACL* to define a single rule (resource type, pattern type, resource name, operation, permission, host). Repeat for each permission the role needs.
+** Click *Allow all operations* to grant the role full wildcard access across all resource types in a single step. Use this for testing only; it is too broad for production.
 
-. Click *Create*.
+. Under *Principals*, use the *Add a principal* search to assign one or more users (or `Group:<name>` entries for OIDC groups) to the role.

modules/manage/partials/rbac-delete-role.adoc

@@ -2,8 +2,8 @@ To delete an existing role:
 
 . From *Security* on the left navigation menu, select the *Roles* tab.
 
-. Click the role you want to delete. This shows all currently assigned permissions (ACLs) and principals (users).
+. Find the role you want to delete, then click the *...* (more options) menu at the end of its row.
 
 . Click *Delete*.
 
-. Click *Delete*.
+. In the confirmation dialog, type the role name to enable the *Delete* button, then click *Delete*.

modules/manage/partials/rbac-describe-role.adoc

@@ -4,4 +4,4 @@ To view details of an existing role:
 
 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.
+All roles are listed in a paginated view. The filter input at the top of the list accepts a regular expression, for example `^data-` matches every role name starting with `data-`.

modules/manage/partials/rbac-edit-role.adoc

@@ -2,10 +2,12 @@ To edit the ACLs for an existing role:
 
 . From *Security* on the left navigation menu, select the *Roles* tab.
 
-. Select the role you want to edit and click *Edit*.
+. Click the role you want to edit. The role's detail page opens with the role's ACLs and assigned principals.
 
-. While editing the role, you can update the optional origin host for users to connect from.
+. Under *ACLs*, you can:
++
+** Click *+ Add ACL* to add a new rule (resource type, pattern type, resource name, operation, permission, host).
+** Click *Allow all operations* to grant the role full wildcard access across all resource types.
+** Select one or more rows with the checkboxes and click *Delete selected* to remove ACLs in bulk.
 
-. 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.
-
-. After making all changes, click *Update*.
+Changes apply immediately. There is no separate save step.

modules/manage/partials/rbac-list-role.adoc

@@ -2,4 +2,4 @@ To view all existing roles:
 
 . 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.
+All roles are listed in a paginated view. The filter input at the top of the list accepts a regular expression, for example `^data-` matches every role name starting with `data-`.

modules/manage/partials/rbac-unassign-role.adoc

@@ -1,23 +1,17 @@
-There are two ways to remove a role from a principal:
+You can remove a role assignment from either side:
 
-Option 1: Edit the role
+Option 1: From the role's detail page
 
 . From *Security* on the left navigation menu, select the *Roles* tab.
 
-. Select the role you want to remove from one or more principals.
+. Click the role you want to modify.
 
-. Click *Edit*.
+. Under *Principals*, click the trash icon next to each principal you want to remove. Each removal takes effect immediately.
 
-. Below the list of permissions, find the Principals section. Click *x* beside the name of any principals you want to remove from the role.
-
-. After you have removed all needed principals, click *Update*.
-
-Option 2: Edit the user
+Option 2: From the user's detail page
 
 . From *Security* on the left navigation menu, select the *Users* tab.
 
-. Select the user you want to remove from one or more roles.
-
-. Click *x* beside the name of any roles you want to remove this user from.
+. Click the user you want to modify.
 
-. After you have removed the user from all roles, click *Update*.
+. Under *Roles*, click the trash icon next to each role you want to revoke. Each removal takes effect immediately.