From 85a8e113d95b446b6c544b1b45a47f443a635835 Mon Sep 17 00:00:00 2001 From: david-yu Date: Wed, 18 Mar 2026 12:21:49 -0700 Subject: [PATCH 01/15] docs: add Schema Registry ACLs page for Redpanda Operator Add documentation for managing Schema Registry ACLs using the Redpanda Operator's User, RedpandaRole, and Group custom resources. This covers the new `subject` and `registry` ACL resource types added in operator PR redpanda-data/redpanda-operator#1306. Co-Authored-By: Claude Opus 4.6 (1M context) --- modules/ROOT/nav.adoc | 1 + .../pages/kubernetes/k-schema-controller.adoc | 2 + .../k-schema-registry-acls.adoc | 207 ++++++++++++++++++ 3 files changed, 210 insertions(+) create mode 100644 modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 3c8abcbce6..fedfe0bf3b 100644 --- a/modules/ROOT/nav.adoc +++ b/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] diff --git a/modules/manage/pages/kubernetes/k-schema-controller.adoc b/modules/manage/pages/kubernetes/k-schema-controller.adoc index e2e5772aba..4062cd33dd 100644 --- a/modules/manage/pages/kubernetes/k-schema-controller.adoc +++ b/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[] diff --git a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc new file mode 100644 index 0000000000..4f4164e69f --- /dev/null +++ b/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 -o jsonpath='{.status.conditions}' --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 .yaml --namespace +---- + +After deploying, verify that the Redpanda Operator reconciled the resource: + +[,bash] +---- +kubectl logs -l app.kubernetes.io/name=operator -c manager --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[] From 568e561bd0022e1a49ec6a4fe92b9f32573c2440 Mon Sep 17 00:00:00 2001 From: david-yu Date: Wed, 18 Mar 2026 12:58:06 -0700 Subject: [PATCH 02/15] fix: lowercase kubectl in prerequisites Co-Authored-By: Claude Opus 4.6 (1M context) --- .../security/authentication/k-schema-registry-acls.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc index 4f4164e69f..49c706eb6f 100644 --- a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc +++ b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc @@ -11,7 +11,7 @@ For details about Schema Registry Authorization concepts and the available opera 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. +* *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]. From 88999f68f2a3c6a898d091418b5556fbe0844569 Mon Sep 17 00:00:00 2001 From: david-yu Date: Wed, 18 Mar 2026 13:00:07 -0700 Subject: [PATCH 03/15] fix: move example descriptions to paragraphs after YAML blocks Co-Authored-By: Claude Opus 4.6 (1M context) --- .../k-schema-registry-acls.adoc | 24 +++++++++---------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc index 49c706eb6f..2b536ccb81 100644 --- a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc +++ b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc @@ -40,46 +40,44 @@ You can use the following operations for `subject` and `registry` resource types 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] ---- +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 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] ---- +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 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] ---- +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 === 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 @@ -106,9 +104,9 @@ spec: operations: [Read] ---- -=== Grant a producer write access using prefix patterns +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. -To give a producer application write access to all subjects matching a prefix: +=== Grant a producer write access using prefix patterns [source,yaml] ---- @@ -143,9 +141,9 @@ spec: operations: [Write, Describe] ---- -=== Grant global Schema Registry access +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. -To give a schema administrator full access to global registry operations: +=== Grant global Schema Registry access [source,yaml] ---- @@ -171,7 +169,7 @@ spec: 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. +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. == Partial sync behavior From 363bffe98f05564addfed156317da94c65bfee1f Mon Sep 17 00:00:00 2001 From: david-yu Date: Wed, 18 Mar 2026 15:56:50 -0700 Subject: [PATCH 04/15] fix: remove comments from user-crds authz-only example Co-Authored-By: Claude Opus 4.6 (1M context) --- modules/manage/examples/kubernetes/user-crds.feature | 3 --- 1 file changed, 3 deletions(-) diff --git a/modules/manage/examples/kubernetes/user-crds.feature b/modules/manage/examples/kubernetes/user-crds.feature index ada3478265..fb09edb8b5 100644 --- a/modules/manage/examples/kubernetes/user-crds.feature +++ b/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 From 37b6e75a645e416b42a27c68a16a9ad46ac6cc41 Mon Sep 17 00:00:00 2001 From: david-yu Date: Wed, 18 Mar 2026 15:57:22 -0700 Subject: [PATCH 05/15] fix: remove comments from role-crds authorization example Co-Authored-By: Claude Opus 4.6 (1M context) --- modules/manage/examples/kubernetes/role-crds.feature | 2 -- 1 file changed, 2 deletions(-) diff --git a/modules/manage/examples/kubernetes/role-crds.feature b/modules/manage/examples/kubernetes/role-crds.feature index 0f9dfc9ccf..351ce75e99 100644 --- a/modules/manage/examples/kubernetes/role-crds.feature +++ b/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 From 03a06fe21b5f061a859afe8f224180f975cdc7d8 Mon Sep 17 00:00:00 2001 From: David Yu Date: Fri, 20 Mar 2026 09:11:47 -0700 Subject: [PATCH 06/15] Update modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc Co-authored-by: Kat Batuigas <36839689+kbatuigas@users.noreply.github.com> --- .../security/authentication/k-schema-registry-acls.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc index 2b536ccb81..23146bb868 100644 --- a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc +++ b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc @@ -23,7 +23,7 @@ The Redpanda Operator supports two Schema Registry ACL resource types in additio * `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]. +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 From 7d1130d73ddaccfdfeeae8a01d7087e5675b8484 Mon Sep 17 00:00:00 2001 From: David Yu Date: Fri, 20 Mar 2026 09:12:15 -0700 Subject: [PATCH 07/15] Update modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc Co-authored-by: Kat Batuigas <36839689+kbatuigas@users.noreply.github.com> --- .../security/authentication/k-schema-registry-acls.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc index 23146bb868..cc55e2d898 100644 --- a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc +++ b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc @@ -14,7 +14,7 @@ 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 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 From 59e4e525f7448980ee4d83b4a26d746d8eb094d4 Mon Sep 17 00:00:00 2001 From: david-yu Date: Fri, 20 Mar 2026 09:52:17 -0700 Subject: [PATCH 08/15] Remove redundant Supported operations subsection The operations list is already linked from the line above, so the subsection was duplicating content from the Schema Registry Authorization page. Co-Authored-By: Claude Opus 4.6 (1M context) --- .../authentication/k-schema-registry-acls.adoc | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc index cc55e2d898..0704c3a4b0 100644 --- a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc +++ b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc @@ -25,17 +25,6 @@ The Redpanda Operator supports two Schema Registry ACL resource types in additio 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. From bc20f332f2e9314a434464a7fb23b1edf98a0acf Mon Sep 17 00:00:00 2001 From: david-yu Date: Fri, 20 Mar 2026 16:25:49 -0700 Subject: [PATCH 09/15] Add Prometheus ServiceMonitor docs for Console on Kubernetes Document the new monitoring.enabled, monitoring.scrapeInterval, and monitoring.labels Helm values that deploy a ServiceMonitor resource alongside Console for automatic Prometheus discovery. Relates to redpanda-data/redpanda-operator#1056 Co-Authored-By: Claude Opus 4.6 (1M context) --- .../pages/console/kubernetes/deploy.adoc | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/modules/deploy/pages/console/kubernetes/deploy.adoc b/modules/deploy/pages/console/kubernetes/deploy.adoc index 091359c4ff..bd7830a9c7 100644 --- a/modules/deploy/pages/console/kubernetes/deploy.adoc +++ b/modules/deploy/pages/console/kubernetes/deploy.adoc @@ -401,6 +401,43 @@ config: port: 9090 ---- +=== Prometheus ServiceMonitor + +If you use the https://github.com/prometheus-operator/prometheus-operator[Prometheus Operator^], you can deploy a `ServiceMonitor` resource alongside Redpanda Console so that Prometheus automatically discovers and scrapes Console metrics from the `/admin/metrics` endpoint. + +To enable the ServiceMonitor in the Console Helm chart, add the following to your `console-values.yaml`: + +[,yaml] +---- +monitoring: + enabled: true <1> + scrapeInterval: "30s" <2> + labels: {} <3> +---- + +<1> Set to `true` to create a `ServiceMonitor` resource. Default: `false`. +<2> How often Prometheus scrapes the metrics endpoint. Default: `1m`. +<3> Additional labels to apply to the `ServiceMonitor`. Use this to match your Prometheus Operator's `serviceMonitorSelector`. For example: ++ +[,yaml] +---- +monitoring: + enabled: true + labels: + release: kube-prometheus-stack +---- + +If you deploy Redpanda Console as a subchart of the Redpanda Helm chart, configure monitoring under the `console` key: + +[,yaml] +---- +console: + monitoring: + enabled: true +---- + +When the Console server is configured with TLS (`config.server.tls.enabled: true`), the ServiceMonitor automatically uses HTTPS and includes the TLS certificate and key file paths for scraping. + == Troubleshooting * **Connection refused**: Verify Redpanda broker addresses and network policies From 655184127908d51050b5058390b3e7bf5a3e9b0c Mon Sep 17 00:00:00 2001 From: micheleRP Date: Mon, 23 Mar 2026 20:07:02 -0600 Subject: [PATCH 10/15] Style edits for Schema Registry ACLs page - Add page-topic-type and personas metadata - Trim description to under 155 chars - Replace repeated "Ensure" in prerequisites with noun-led format - Replace "You can add" openers with direct statements - Fix "the Redpanda Schema Registry" -> "Schema Registry" - Trim "For details about" verbose opener - Rename "Suggested reading" to "Next steps" Co-Authored-By: Claude Opus 4.6 (1M context) --- .../k-schema-registry-acls.adoc | 24 ++++++++++--------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc index 0704c3a4b0..8851e0898e 100644 --- a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc +++ b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc @@ -1,20 +1,22 @@ = 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. +: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 can perform specific operations within the Redpanda Schema Registry. +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 details about Schema Registry Authorization concepts and the available operations, see xref:manage:schema-reg/schema-reg-authorization.adoc[]. +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*: 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]. +* *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 @@ -27,7 +29,7 @@ For a full list of supported operations by resource type, see xref:manage:schema == 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. +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] @@ -41,7 +43,7 @@ When both Kafka and Schema Registry ACLs are defined in the same User resource, == 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. +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] @@ -53,7 +55,7 @@ In this example, a RedpandaRole called `read-only-role` is created in the cluste == Define Schema Registry ACLs in a Group resource -You can add Schema Registry ACLs to a Group resource when using OIDC groups. +The Group resource supports Schema Registry ACLs for OIDC groups. .`group-with-sr-acls.yaml` [,yaml,indent=0] @@ -185,7 +187,7 @@ After deploying, verify that the Redpanda Operator reconciled the resource: kubectl logs -l app.kubernetes.io/name=operator -c manager --namespace ---- -== Suggested reading +== Next steps * xref:manage:schema-reg/schema-reg-authorization.adoc[] * xref:manage:kubernetes/security/authentication/k-user-controller.adoc[] From 1b17f544478f75ffce1f8da10333428addfe0f5e Mon Sep 17 00:00:00 2001 From: david-yu Date: Fri, 27 Mar 2026 13:48:57 -0700 Subject: [PATCH 11/15] Add group-crds.feature to fix build error in Schema Registry ACLs page The include directive for group-crds.feature was missing, causing the code block not to render on the deploy preview. Co-Authored-By: Claude Opus 4.6 (1M context) --- .../examples/kubernetes/group-crds.feature | 35 +++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 modules/manage/examples/kubernetes/group-crds.feature diff --git a/modules/manage/examples/kubernetes/group-crds.feature b/modules/manage/examples/kubernetes/group-crds.feature new file mode 100644 index 0000000000..f5527eb90e --- /dev/null +++ b/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[] + """ From ac05be1e2db97305bee8f8f799b6c81ba3f60148 Mon Sep 17 00:00:00 2001 From: david-yu Date: Fri, 27 Mar 2026 13:51:48 -0700 Subject: [PATCH 12/15] Add subject ACLs to user and role feature file examples The doc page describes both topic and subject ACLs in the examples, but the feature files only had topic ACLs. Add the missing subject ACL entries to match the documentation. Co-Authored-By: Claude Opus 4.6 (1M context) --- modules/manage/examples/kubernetes/role-crds.feature | 6 ++++++ modules/manage/examples/kubernetes/user-crds.feature | 6 ++++++ 2 files changed, 12 insertions(+) diff --git a/modules/manage/examples/kubernetes/role-crds.feature b/modules/manage/examples/kubernetes/role-crds.feature index 351ce75e99..2707bf84ff 100644 --- a/modules/manage/examples/kubernetes/role-crds.feature +++ b/modules/manage/examples/kubernetes/role-crds.feature @@ -62,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 diff --git a/modules/manage/examples/kubernetes/user-crds.feature b/modules/manage/examples/kubernetes/user-crds.feature index fb09edb8b5..ba82ec3fbd 100644 --- a/modules/manage/examples/kubernetes/user-crds.feature +++ b/modules/manage/examples/kubernetes/user-crds.feature @@ -83,6 +83,12 @@ 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 From 0f490ad3db06b0b50be9e89487fee672cfb0c803 Mon Sep 17 00:00:00 2001 From: david-yu Date: Fri, 27 Mar 2026 13:53:20 -0700 Subject: [PATCH 13/15] Add intro sentence to Common use cases section Co-Authored-By: Claude Opus 4.6 (1M context) --- .../security/authentication/k-schema-registry-acls.adoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc index 8851e0898e..3c7222600a 100644 --- a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc +++ b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc @@ -67,6 +67,8 @@ In this example, ACLs are created for an OIDC group called `engineering` in the == 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 [source,yaml] From 3d254188abfe001ffd02496afb2dd103c5a86bfb Mon Sep 17 00:00:00 2001 From: david-yu Date: Fri, 27 Mar 2026 13:56:31 -0700 Subject: [PATCH 14/15] Move description text above code blocks in common use cases Move the explanatory text from after the code blocks to before them so it serves as intro text for each subsection. Co-Authored-By: Claude Opus 4.6 (1M context) --- .../authentication/k-schema-registry-acls.adoc | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc index 3c7222600a..1061052fce 100644 --- a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc +++ b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc @@ -71,6 +71,8 @@ The following examples show common patterns for configuring Schema Registry ACLs === 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. + [source,yaml] ---- apiVersion: cluster.redpanda.com/v1alpha2 @@ -97,10 +99,10 @@ spec: operations: [Read] ---- -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. - === 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. + [source,yaml] ---- apiVersion: cluster.redpanda.com/v1alpha2 @@ -134,10 +136,10 @@ spec: operations: [Write, Describe] ---- -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. - === 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. + [source,yaml] ---- apiVersion: cluster.redpanda.com/v1alpha2 @@ -162,8 +164,6 @@ spec: operations: [Read, Write, Delete, Describe, DescribeConfigs, AlterConfigs] ---- -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. - == 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: From d5079040bdc8744d85f75a0ed97b5a6c901050cf Mon Sep 17 00:00:00 2001 From: david-yu Date: Fri, 27 Mar 2026 14:28:27 -0700 Subject: [PATCH 15/15] Move Common use cases examples to feature file and revert deploy.adoc Extract the three inline YAML examples from the Common use cases section into tagged scenarios in user-crds.feature so they are testable. Revert unrelated changes to the Console deploy page. Co-Authored-By: Claude Opus 4.6 (1M context) --- .../pages/console/kubernetes/deploy.adoc | 37 ------ .../examples/kubernetes/user-crds.feature | 107 ++++++++++++++++++ .../k-schema-registry-acls.adoc | 89 ++------------- 3 files changed, 119 insertions(+), 114 deletions(-) diff --git a/modules/deploy/pages/console/kubernetes/deploy.adoc b/modules/deploy/pages/console/kubernetes/deploy.adoc index f4fc17b313..c63e6337c5 100644 --- a/modules/deploy/pages/console/kubernetes/deploy.adoc +++ b/modules/deploy/pages/console/kubernetes/deploy.adoc @@ -678,43 +678,6 @@ config: port: 9090 ---- -=== Prometheus ServiceMonitor - -If you use the https://github.com/prometheus-operator/prometheus-operator[Prometheus Operator^], you can deploy a `ServiceMonitor` resource alongside Redpanda Console so that Prometheus automatically discovers and scrapes Console metrics from the `/admin/metrics` endpoint. - -To enable the ServiceMonitor in the Console Helm chart, add the following to your `console-values.yaml`: - -[,yaml] ----- -monitoring: - enabled: true <1> - scrapeInterval: "30s" <2> - labels: {} <3> ----- - -<1> Set to `true` to create a `ServiceMonitor` resource. Default: `false`. -<2> How often Prometheus scrapes the metrics endpoint. Default: `1m`. -<3> Additional labels to apply to the `ServiceMonitor`. Use this to match your Prometheus Operator's `serviceMonitorSelector`. For example: -+ -[,yaml] ----- -monitoring: - enabled: true - labels: - release: kube-prometheus-stack ----- - -If you deploy Redpanda Console as a subchart of the Redpanda Helm chart, configure monitoring under the `console` key: - -[,yaml] ----- -console: - monitoring: - enabled: true ----- - -When the Console server is configured with TLS (`config.server.tls.enabled: true`), the ServiceMonitor automatically uses HTTPS and includes the TLS certificate and key file paths for scraping. - == Troubleshooting * **Connection refused**: Verify Redpanda broker addresses and network policies diff --git a/modules/manage/examples/kubernetes/user-crds.feature b/modules/manage/examples/kubernetes/user-crds.feature index ba82ec3fbd..b49ae0db83 100644 --- a/modules/manage/examples/kubernetes/user-crds.feature +++ b/modules/manage/examples/kubernetes/user-crds.feature @@ -94,3 +94,110 @@ Feature: User CRDs 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" diff --git a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc index 1061052fce..89d23a8b85 100644 --- a/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc +++ b/modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc @@ -73,95 +73,30 @@ The following examples show common patterns for configuring Schema Registry ACLs 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. -[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] +.`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. -[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] +.`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. -[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] +.`schema-admin.yaml` +[,yaml,indent=0] +---- +include::manage:example$kubernetes/user-crds.feature[tags=grant-global-sr-access,indent=0] ---- == Partial sync behavior