docs (k8s): add Schema Registry ACLs for Redpanda Operator#1619
docs (k8s): add Schema Registry ACLs for Redpanda Operator#1619david-yu wants to merge 9 commits intoredpanda-data:mainfrom
Conversation
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) <noreply@anthropic.com>
📝 WalkthroughWalkthroughThis pull request adds documentation for managing Schema Registry ACLs with the Redpanda Operator in Kubernetes. The changes include a new navigation entry pointing to a comprehensive documentation file that describes how to define and manage Schema Registry ACLs across User, RedpandaRole, and Group resources. The documentation covers supported operations, prerequisites, manifest examples, common use cases, and verification steps. Additionally, cross-reference links are added to an existing schema controller documentation file. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
✅ Deploy Preview for redpanda-docs-preview ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc (1)
6-6: Prefer auto-title xrefs where possible.Several xrefs hard-code link text; repository convention prefers
xref:...[]so titles are pulled from targets automatically.Based on learnings: "AsciiDoc linking: prefer using xref links with empty brackets (e.g., xref:section/target.adoc[]) because the title is pulled from the referenced document automatically."
Also applies to: 41-42, 55-56
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc` at line 6, The xref links in k-schema-registry-acls.adoc currently include hard-coded link text (e.g., xref:reference:k-crd.adoc#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-user[User] and xref:reference:k-crd.adoc#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-role[RedpandaRole]); replace those explicit labels with auto-title xrefs by removing the bracket text so they become xref:reference:k-crd.adoc#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-user[] and xref:reference:k-crd.adoc#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-role[], and apply the same change to the other occurrences noted around lines 41-42 and 55-56 so the link titles are pulled automatically from the target documents.modules/manage/pages/kubernetes/k-schema-controller.adoc (1)
281-281: Use empty-bracket xref for consistency with docs linking style.This link can rely on target page title instead of hard-coded text.
Suggested diff
-* xref:manage:kubernetes/security/authentication/k-schema-registry-acls.adoc[Manage Schema Registry ACLs (Operator)] +* xref:manage:kubernetes/security/authentication/k-schema-registry-acls.adoc[]Based on learnings: "AsciiDoc linking: prefer using xref links with empty brackets (e.g., xref:section/target.adoc[]) because the title is pulled from the referenced document automatically."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@modules/manage/pages/kubernetes/k-schema-controller.adoc` at line 281, Replace the explicit link text xref:manage:kubernetes/security/authentication/k-schema-registry-acls.adoc[Manage Schema Registry ACLs (Operator)] with an empty-bracket xref so the target title is pulled automatically, e.g. xref:manage:kubernetes/security/authentication/k-schema-registry-acls.adoc[]; update the occurrence in k-schema-controller.adoc where that xref appears.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@modules/manage/pages/kubernetes/k-schema-controller.adoc`:
- Line 281: Replace the explicit link text
xref:manage:kubernetes/security/authentication/k-schema-registry-acls.adoc[Manage
Schema Registry ACLs (Operator)] with an empty-bracket xref so the target title
is pulled automatically, e.g.
xref:manage:kubernetes/security/authentication/k-schema-registry-acls.adoc[];
update the occurrence in k-schema-controller.adoc where that xref appears.
In
`@modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc`:
- Line 6: The xref links in k-schema-registry-acls.adoc currently include
hard-coded link text (e.g.,
xref:reference:k-crd.adoc#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-user[User]
and
xref:reference:k-crd.adoc#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-role[RedpandaRole]);
replace those explicit labels with auto-title xrefs by removing the bracket text
so they become
xref:reference:k-crd.adoc#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-user[]
and
xref:reference:k-crd.adoc#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-role[],
and apply the same change to the other occurrences noted around lines 41-42 and
55-56 so the link titles are pulled automatically from the target documents.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 85b3a6ad-76ca-41ed-af12-72b7c75648f6
📒 Files selected for processing (3)
modules/ROOT/nav.adocmodules/manage/pages/kubernetes/k-schema-controller.adocmodules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
| .`group-with-sr-acls.yaml` | ||
| [,yaml,indent=0] | ||
| ---- | ||
| include::manage:example$kubernetes/group-crds.feature[tags=manage-group-acls,indent=0] |
There was a problem hiding this comment.
This causes a build error and the code block does not render correctly: https://deploy-preview-1619--redpanda-docs-preview.netlify.app/current/manage/kubernetes/security/authentication/k-schema-registry-acls/#define-schema-registry-acls-in-a-group-resource To fix, this requires adding a group-crds.feature in modules/manage/examples/kubernetes
| 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. |
There was a problem hiding this comment.
This implies that the block enclosed by tag::manage-authz-only-manifest[] and end::manage-authz-only-manifest contain an ACL where the resource type is subject, but that doesn't seem to be the case: https://github.com/redpanda-data/docs/pull/1619/changes#diff-dccea8dda19b7046e776a78bcb2a687a4034b8a3243aa8b7cee2a4f6b90f38f1L85 (preview) Could you double check that user-crds.feature needs to be updated, or let me know if I'm not looking in the right place?
modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc
Outdated
Show resolved
Hide resolved
modules/manage/pages/kubernetes/security/authentication/k-schema-registry-acls.adoc
Outdated
Show resolved
Hide resolved
|
|
||
| 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 |
There was a problem hiding this comment.
We could probably do without this whole subsection, since we already link to Supported operations immediately above it
There was a problem hiding this comment.
Removed the Supported operations subsection since we already link to it above.
| .`role-with-sr-acls.yaml` | ||
| [,yaml,indent=0] | ||
| ---- | ||
| include::manage:example$kubernetes/role-crds.feature[tags=manage-roles-with-authorization,indent=0] |
There was a problem hiding this comment.
Please also double check if the example needs updating within the defined tags
| 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. |
There was a problem hiding this comment.
Could we move this above the code block, after the subheading, so that it becomes intro text for this subsection?
| 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. |
| 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. |
| 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 | ||
|
|
There was a problem hiding this comment.
Could we add a short intro here? For example "The following examples show common patterns for configuring Schema Registry ACLs using the User resource." or something along these lines
…ma-registry-acls.adoc Co-authored-by: Kat Batuigas <36839689+kbatuigas@users.noreply.github.com>
…ma-registry-acls.adoc Co-authored-by: Kat Batuigas <36839689+kbatuigas@users.noreply.github.com>
|
Thanks @kbatuigas I will incorporate your feedback. |
david-yu
changed the title
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) <noreply@anthropic.com>
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) <noreply@anthropic.com>
2 participants
Summary
subjectandregistryACL resource types for User, RedpandaRole, and Group CRDs introduced in Add Schema Registry ACLs redpanda-operator#1306Test plan
🤖 Generated with Claude Code