docs (k8s): add Schema Registry ACLs for Redpanda Operator

modules/ROOT/nav.adoc

@@ -134,6 +134,7 @@
 ***** xref:manage:kubernetes/security/authentication/k-authentication.adoc[Enable Authentication]
 ***** xref:manage:kubernetes/security/authentication/k-user-controller.adoc[Manage Users and ACLs (Operator)]
 ***** xref:manage:kubernetes/security/authorization/k-role-controller.adoc[Manage Roles and ACLs (Operator)]
+***** xref:manage:kubernetes/security/authentication/k-schema-registry-acls.adoc[Manage Schema Registry ACLs (Operator)]
 **** xref:manage:kubernetes/security/k-audit-logging.adoc[Audit Logging]
 *** xref:manage:kubernetes/k-rack-awareness.adoc[Rack Awareness]
 *** xref:manage:kubernetes/k-remote-read-replicas.adoc[Remote Read Replicas]

modules/manage/pages/kubernetes/k-schema-controller.adoc

@@ -278,4 +278,6 @@ internal-rpk registry subject list
 For more details on using schemas in Redpanda, see:
 
 * xref:manage:schema-reg/index.adoc[]
+* xref:manage:kubernetes/security/authentication/k-schema-registry-acls.adoc[Manage Schema Registry ACLs (Operator)]
+* xref:manage:schema-reg/schema-reg-authorization.adoc[]
 

modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc

@@ -0,0 +1,207 @@
+= Manage Schema Registry ACLs with the Redpanda Operator
+:description: Use the User, RedpandaRole, and Group resources to declaratively manage Schema Registry ACLs as part of a Redpanda deployment in Kubernetes. Schema Registry ACLs provide fine-grained access control over schema subjects and global registry operations.
+:page-categories: Management, Security
+:env-kubernetes: true
+
+With the Redpanda Operator, you can declaratively manage Schema Registry ACLs alongside standard Kafka ACLs using the existing xref:reference:k-crd.adoc#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-user[User], xref:reference:k-crd.adoc#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-role[RedpandaRole], and Group custom resources. This allows you to control which users and roles can perform specific operations within the Redpanda Schema Registry.
+
+For details about Schema Registry Authorization concepts and the available operations, see xref:manage:schema-reg/schema-reg-authorization.adoc[].
+
+== Prerequisites
+
+You must have the following:
+
+* *Kubectl*: Ensure you have the https://kubernetes.io/docs/tasks/tools/#kubectl[kubectl^] command-line tool installed and configured to communicate with your cluster.
+* *Redpanda Operator*: Ensure you have at least version 25.3 of the xref:deploy:deployment-option/self-hosted/kubernetes/k-production-deployment.adoc[Redpanda Operator].
+* *Redpanda cluster with SASL enabled*: Ensure you have a Redpanda resource deployed with xref:manage:kubernetes/security/authentication/k-authentication.adoc#enable[SASL authentication enabled].
+* *Schema Registry Authorization enabled*: Schema Registry Authorization must be enabled on the Redpanda cluster. See xref:manage:schema-reg/schema-reg-authorization.adoc#_enable_schema_registry_authorization[Enable Schema Registry Authorization].
+
+== Schema Registry ACL resource types
+
+The Redpanda Operator supports two Schema Registry ACL resource types in addition to the standard Kafka ACL resource types (`topic`, `group`, `cluster`, `transactionalId`):
+
+* `subject`: Controls ACL access for specific Schema Registry subjects. Specify the subject name in `resource.name`. Supports both `literal` and `prefixed` pattern types.
+* `registry`: Controls access to global Schema Registry operations. The `registry` resource type does not require a `name` because it applies to all global registry operations.
+
+For a full list of supported operations by resource type, see xref:manage:schema-reg/schema-reg-authorization.adoc#_supported_operations[Supported operations].
+
+=== Supported operations
+
+You can use the following operations for `subject` and `registry` resource types:
+
+* `Read` - Read schemas and their content
+* `Write` - Register new schemas and schema versions
+* `Delete` - Delete schema versions and subjects
+* `Describe` - List and describe Schema Registry resources
+* `DescribeConfigs` - Read configuration settings
+* `AlterConfigs` - Modify configuration settings
+
+== Define Schema Registry ACLs in a User resource
+
+You can add Schema Registry ACLs to a xref:manage:kubernetes/security/authentication/k-user-controller.adoc[User resource] alongside standard Kafka ACLs.
+
+This example creates ACLs that grant the user `travis` read access to topics matching `some-topic` and read access to Schema Registry subjects matching `some-topic`:
+
+.`user-with-sr-acls.yaml`
+[,yaml,indent=0]
+----
+include::manage:example$kubernetes/user-crds.feature[tags=manage-authz-only-manifest,indent=0]
+----
+
+When both Kafka and Schema Registry ACLs are defined in the same User resource, the operator syncs them independently. Kafka ACLs are applied through the Kafka API and Schema Registry ACLs are applied through the Schema Registry API.
+
+== Define Schema Registry ACLs in a RedpandaRole resource
+
+You can add Schema Registry ACLs to a xref:manage:kubernetes/security/authorization/k-role-controller.adoc[RedpandaRole resource] to create reusable permission sets for multiple users.
+
+This example creates a read-only role that grants access to both topics and Schema Registry subjects matching `public-`:
+
+.`role-with-sr-acls.yaml`
+[,yaml,indent=0]
+----
+include::manage:example$kubernetes/role-crds.feature[tags=manage-roles-with-authorization,indent=0]
+----
+
+== Define Schema Registry ACLs in a Group resource
+
+You can add Schema Registry ACLs to a Group resource when using OIDC groups.
+
+This example creates ACLs for an OIDC group that grants read access to topics and Schema Registry subjects matching `team-`:
+
+.`group-with-sr-acls.yaml`
+[,yaml,indent=0]
+----
+include::manage:example$kubernetes/group-crds.feature[tags=manage-group-acls,indent=0]
+----
+
+== Common use cases
+
+=== Grant a user read access to a subject
+
+To give a consumer application read access to schemas for a specific topic:
+
+[source,yaml]
+----
+apiVersion: cluster.redpanda.com/v1alpha2
+kind: User
+metadata:
+  name: consumer-app
+spec:
+  cluster:
+    clusterRef:
+      name: redpanda
+  authorization:
+    acls:
+      - type: allow
+        resource:
+          type: topic
+          name: orders
+          patternType: literal
+        operations: [Read]
+      - type: allow
+        resource:
+          type: subject
+          name: orders-value
+          patternType: literal
+        operations: [Read]
+----
+
+=== Grant a producer write access using prefix patterns
+
+To give a producer application write access to all subjects matching a prefix:
+
+[source,yaml]
+----
+apiVersion: cluster.redpanda.com/v1alpha2
+kind: User
+metadata:
+  name: producer-app
+spec:
+  cluster:
+    clusterRef:
+      name: redpanda
+  authentication:
+    type: scram-sha-512
+    password:
+      valueFrom:
+        secretKeyRef:
+          name: producer-app-secret
+          key: password
+  authorization:
+    acls:
+      - type: allow
+        resource:
+          type: topic
+          name: events-
+          patternType: prefixed
+        operations: [Write, Describe]
+      - type: allow
+        resource:
+          type: subject
+          name: events-
+          patternType: prefixed
+        operations: [Write, Describe]
+----
+
+=== Grant global Schema Registry access
+
+To give a schema administrator full access to global registry operations:
+
+[source,yaml]
+----
+apiVersion: cluster.redpanda.com/v1alpha2
+kind: User
+metadata:
+  name: schema-admin
+spec:
+  cluster:
+    clusterRef:
+      name: redpanda
+  authorization:
+    acls:
+      - type: allow
+        resource:
+          type: registry
+        operations: [Read, Write, Delete, Describe, DescribeConfigs, AlterConfigs]
+      - type: allow
+        resource:
+          type: subject
+          name: ""
+          patternType: prefixed
+        operations: [Read, Write, Delete, Describe, DescribeConfigs, AlterConfigs]
+----
+
+The `registry` resource type does not require a `name` field because it applies to all global operations such as getting or setting the global compatibility level.
+
+== Partial sync behavior
+
+When a resource includes both Kafka and Schema Registry ACLs, the operator syncs them independently. If the Kafka ACLs sync successfully but the Schema Registry ACLs fail (for example, if Schema Registry Authorization is not enabled), the resource enters a `PartiallySynced` state. Check the resource status conditions for details:
+
+[,bash]
+----
+kubectl get user <user-name> -o jsonpath='{.status.conditions}' --namespace <namespace>
+----
+
+== Deploy and verify
+
+To deploy a resource with Schema Registry ACLs, apply the manifest to the same namespace as your Redpanda cluster:
+
+[,bash]
+----
+kubectl apply -f <manifest-filename>.yaml --namespace <namespace>
+----
+
+After deploying, verify that the Redpanda Operator reconciled the resource:
+
+[,bash]
+----
+kubectl logs -l app.kubernetes.io/name=operator -c manager --namespace <namespace>
+----
+
+== Suggested reading
+
+* xref:manage:schema-reg/schema-reg-authorization.adoc[]
+* xref:manage:kubernetes/security/authentication/k-user-controller.adoc[]
+* xref:manage:kubernetes/security/authorization/k-role-controller.adoc[]
+* xref:reference:k-crd.adoc#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-aclresourcespec[ACLResourceSpec]
+* xref:manage:security/authorization/acl.adoc[]