DOC-1732: Document managing Schema Registry ACLs in Console

modules/manage/pages/schema-reg/schema-reg-authorization.adoc

@@ -37,10 +37,10 @@ You can manage Schema Registry Authorization in the following ways:
 - **rpk**: Use the xref:reference:rpk/rpk-security/rpk-security-acl-create.adoc[`rpk security acl create`] command, just like you would for other Kafka ACLs.
 - **Schema Registry API**: Use the link:/api/doc/schema-registry/operation/operation-get_security_acls[Redpanda Schema Registry API] endpoints.
 ifndef::env-cloud[]
-- **{ui}**: After enabling Schema Registry Authorization for your cluster, you can use {ui} to manage Schema Registry ACLs. See xref:manage:security/authorization/acl.adoc[].
+- **{ui}**: After enabling Schema Registry Authorization for your cluster, you can use {ui} to manage Schema Registry ACLs. See xref:#manage-sr-acls-console[].
 endif::[]
 ifdef::env-cloud[]
-- **{ui}**: Use {ui} to manage Schema Registry ACLs. See xref:security:authorization/acl.adoc[].
+- **{ui}**: Use {ui} to manage Schema Registry ACLs. See xref:#manage-sr-acls-console[].
 endif::[]
 
 === Schema Registry ACL resource types
@@ -50,6 +50,19 @@ Schema Registry Authorization introduces two new ACL resource types in addition
 * `registry`: Controls whether or not to grant ACL access to global, or top-level Schema Registry operations. Specify using the flag `registry-global`.
 * `subject`: Controls ACL access for specific Schema Registry subjects. Specify using the flag `registry-subject`.
 
+[#manage-sr-acls-console]
+=== Manage Schema Registry ACLs in {ui}
+
+You can create and manage Schema Registry ACLs from the *Security* page in {ui}, the same way you manage Kafka ACLs. Open a user under *Users* (or a role under *Roles*), then use the *ACLs* section on its detail page.
+
+To add a Schema Registry ACL, click *+ Add ACL* and set *Resource Type* to one of the Schema Registry resource types:
+
+* *Subject*: Restricts access to specific subjects (the `subject` resource type). Set *Resource Name* to the subject name (for example, `sensor-data-value`), and set *Pattern Type* to `Literal` to match a single subject or `Prefixed` to match all subjects that share a prefix.
+* *Schema Registry*: Restricts global, top-level Schema Registry operations (the `registry` resource type). This resource applies cluster-wide, so you do not set a resource name.
+
+For example, to let a principal read schemas under the `sensor-data-value` subject, add an ACL with *Resource Type* `Subject`, *Pattern Type* `Literal`, *Resource Name* `sensor-data-value`, *Operation* `Read`, and *Permission* `Allow`.
+
+[#supported-operations]
 == Supported operations
 
 Redpanda Schema Registry ACLs support the following specific subset of Schema Registry endpoints and operations:

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

@@ -49,7 +49,7 @@ You can create and manage ACLs in the following ways:
 +
 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 *+ Add ACL* to define a single rule by specifying its resource type, pattern type, resource name, operation, permission, and host. The *Resource Type* list includes *Subject* and *Schema Registry* for Schema Registry ACLs, in addition to the Kafka resource types. See xref:manage:schema-reg/schema-reg-authorization.adoc[] for the Schema Registry operations they support.
 ** 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.