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

modules/ROOT/nav.adoc

@@ -137,6 +137,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/examples/kubernetes/group-crds.feature

@@ -0,0 +1,35 @@
+@cluster:sasl @variant:vectorized
+Feature: Group CRDs
+  Background: Cluster available
+    Given cluster "sasl" is available
+
+  @skip:gke @skip:aks @skip:eks
+  Scenario: Manage group ACLs
+    When I apply Kubernetes manifest:
+    """
+# tag::manage-group-acls[]
+    ---
+    apiVersion: cluster.redpanda.com/v1alpha2
+    kind: Group
+    metadata:
+      name: engineering
+    spec:
+      cluster:
+        clusterRef:
+          name: sasl
+      authorization:
+        acls:
+          - type: allow
+            resource:
+              type: topic
+              name: team-
+              patternType: prefixed
+            operations: [Read, Describe]
+          - type: allow
+            resource:
+              type: subject
+              name: team-
+              patternType: prefixed
+            operations: [Read, Describe]
+# end::manage-group-acls[]
+    """

modules/manage/examples/kubernetes/role-crds.feature

@@ -43,8 +43,6 @@ Feature: Role CRDs
     And I apply Kubernetes manifest:
     """
 # tag::manage-roles-with-authorization[]
-    # In this example manifest, a role called "read-only-role" is created in a cluster called "sasl".
-    # The role includes authorization rules that allow reading from topics with names starting with "public-".
     ---
     apiVersion: cluster.redpanda.com/v1alpha2
     kind: RedpandaRole
@@ -64,6 +62,12 @@ Feature: Role CRDs
               name: public-
               patternType: prefixed
             operations: [Read, Describe]
+          - type: allow
+            resource:
+              type: subject
+              name: public-
+              patternType: prefixed
+            operations: [Read, Describe]
 # end::manage-roles-with-authorization[]
     """
     And role "read-only-role" is successfully synced

modules/manage/examples/kubernetes/user-crds.feature

@@ -59,9 +59,6 @@ Feature: User CRDs
     When I apply Kubernetes manifest:
     """
 # tag::manage-authz-only-manifest[]
-    # In this example manifest, an ACL called "travis" is created in a cluster called "sasl".
-    # The ACL give an existing user called "travis" permissions to read from all topics whose names start with some-topic.
-    # This example assumes that you already have a user called "travis" in your cluster.
     ---
     apiVersion: cluster.redpanda.com/v1alpha2
     kind: User
@@ -86,8 +83,121 @@ Feature: User CRDs
             name: some-topic
             patternType: prefixed
           operations: [Read]
+        - type: allow
+          resource:
+            type: subject
+            name: some-topic
+            patternType: prefixed
+          operations: [Read]
 # end::manage-authz-only-manifest[]
     """
     And user "travis" is successfully synced
     And I delete the CRD user "travis"
     Then "travis" should be able to authenticate to the "sasl" cluster with password "password" and mechanism "SCRAM-SHA-256"
+
+  @skip:gke @skip:aks @skip:eks
+  Scenario: Grant a user read access to a subject
+    Given there is no user "consumer-app" in cluster "sasl"
+    When I apply Kubernetes manifest:
+    """
+# tag::grant-user-read-access[]
+    ---
+    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]
+# end::grant-user-read-access[]
+    """
+    And user "consumer-app" is successfully synced
+    And I delete the CRD user "consumer-app"
+
+  @skip:gke @skip:aks @skip:eks
+  Scenario: Grant a producer write access using prefix patterns
+    Given there is no user "producer-app" in cluster "sasl"
+    When I apply Kubernetes manifest:
+    """
+# tag::grant-producer-write-access[]
+    ---
+    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]
+# end::grant-producer-write-access[]
+    """
+    And user "producer-app" is successfully synced
+    And I delete the CRD user "producer-app"
+
+  @skip:gke @skip:aks @skip:eks
+  Scenario: Grant global Schema Registry access
+    Given there is no user "schema-admin" in cluster "sasl"
+    When I apply Kubernetes manifest:
+    """
+# tag::grant-global-sr-access[]
+    ---
+    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]
+# end::grant-global-sr-access[]
+    """
+    And user "schema-admin" is successfully synced
+    And I delete the CRD user "schema-admin"

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,133 @@
+= Manage Schema Registry ACLs with the Redpanda Operator
+:description: Manage Schema Registry ACLs declaratively in Kubernetes using User, RedpandaRole, and Group custom resources with the Redpanda Operator.
+:page-categories: Management, Security
+:page-topic-type: how-to
+:personas: platform_operator
+: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 perform specific operations within Schema Registry.
+
+For Schema Registry Authorization concepts and the available operations, see xref:manage:schema-reg/schema-reg-authorization.adoc[].
+
+== Prerequisites
+
+You must have the following:
+
+* *kubectl*: The https://kubernetes.io/docs/tasks/tools/#kubectl[kubectl^] command-line tool, installed and configured to communicate with your cluster.
+* *Redpanda Operator v25.3 or later*: See xref:deploy:deployment-option/self-hosted/kubernetes/k-production-deployment.adoc[].
+* *Redpanda cluster with SASL enabled*: See xref:manage:kubernetes/security/authentication/k-authentication.adoc#enable[Enable SASL authentication].
+* *Schema Registry Authorization enabled*: 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].
+
+== Define Schema Registry ACLs in a User resource
+
+The xref:manage:kubernetes/security/authentication/k-user-controller.adoc[User resource] supports Schema Registry ACLs alongside standard Kafka ACLs.
+
+.`user-with-sr-acls.yaml`
+[,yaml,indent=0]
+----
+include::manage:example$kubernetes/user-crds.feature[tags=manage-authz-only-manifest,indent=0]
+----
+
+In this example, the User resource creates ACLs for an existing user called `travis` in the cluster called `sasl`. The first ACL rule grants read access to all topics whose names start with `some-topic` using a `prefixed` pattern type. The second ACL rule grants read access to Schema Registry subjects matching the same prefix.
+
+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
+
+The xref:manage:kubernetes/security/authorization/k-role-controller.adoc[RedpandaRole resource] groups Schema Registry ACLs into reusable permission sets for multiple users.
+
+.`role-with-sr-acls.yaml`
+[,yaml,indent=0]
+----
+include::manage:example$kubernetes/role-crds.feature[tags=manage-roles-with-authorization,indent=0]
+----
+
+In this example, a RedpandaRole called `read-only-role` is created in the cluster called `sasl`. The user `charlie` is assigned as a principal. The authorization rules grant `Read` and `Describe` access to all topics with names starting with `public-` using a `prefixed` pattern type, and the same `Read` and `Describe` access to Schema Registry subjects matching the same prefix.
+
+== Define Schema Registry ACLs in a Group resource
+
+The Group resource supports Schema Registry ACLs for OIDC groups.
+
+.`group-with-sr-acls.yaml`
+[,yaml,indent=0]
+----
+include::manage:example$kubernetes/group-crds.feature[tags=manage-group-acls,indent=0]
+----
+
+In this example, ACLs are created for an OIDC group called `engineering` in the cluster called `sasl`. The authorization rules grant `Read` and `Describe` access to all topics with names starting with `team-` using a `prefixed` pattern type, and the same `Read` and `Describe` access to Schema Registry subjects matching the same prefix.
+
+== Common use cases
+
+The following examples show common patterns for configuring Schema Registry ACLs using the User resource.
+
+=== Grant a user read access to a subject
+
+This example gives a consumer application read access to the `orders` topic and its associated Schema Registry subject `orders-value`. Both ACLs use a `literal` pattern type to match exact resource names.
+
+.`consumer-app.yaml`
+[,yaml,indent=0]
+----
+include::manage:example$kubernetes/user-crds.feature[tags=grant-user-read-access,indent=0]
+----
+
+=== Grant a producer write access using prefix patterns
+
+This example creates a user called `producer-app` with both authentication credentials and authorization rules. The ACLs grant `Write` and `Describe` access to all topics and Schema Registry subjects whose names start with `events-` using a `prefixed` pattern type. This allows the producer to register new schema versions for any subject matching the prefix.
+
+.`producer-app.yaml`
+[,yaml,indent=0]
+----
+include::manage:example$kubernetes/user-crds.feature[tags=grant-producer-write-access,indent=0]
+----
+
+=== Grant global Schema Registry access
+
+This example gives a schema administrator full access to all Schema Registry operations. The first ACL rule uses the `registry` resource type, which applies to global operations such as getting or setting the global compatibility level. The `registry` resource type does not require a `name` field. The second ACL rule uses a `subject` resource type with an empty name and `prefixed` pattern type to match all subjects.
+
+.`schema-admin.yaml`
+[,yaml,indent=0]
+----
+include::manage:example$kubernetes/user-crds.feature[tags=grant-global-sr-access,indent=0]
+----
+
+== 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>
+----
+
+== Next steps
+
+* 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[]