Skip to content

DOC-1936: Document SR authorization enabled by default for Cloud #581

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
micheleRP wants to merge 1 commit into
base: main
Choose a base branch
from
Open

DOC-1936: Document SR authorization enabled by default for Cloud #581

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions modules/get-started/pages/whats-new-cloud.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,14 @@ This page lists new features added to Redpanda Cloud.

== May 2026

=== Schema Registry Authorization enabled by default

Schema Registry Authorization is now enabled automatically on all new BYOC and Dedicated clusters. The xref:reference:properties/cluster-properties.adoc#schema_registry_enable_authorization[`schema_registry_enable_authorization`] cluster property is set to `true` at provisioning, and the predefined Admin, Writer, and Reader roles include Schema Registry permissions for the `subject` and `registry` ACL resource types. You can use ACLs and RBAC roles to grant fine-grained access to schemas and subjects without any additional setup. See xref:manage:schema-reg/schema-reg-authorization.adoc[Schema Registry Authorization] and xref:security:authorization/rbac/rbac.adoc#predefined-roles[Predefined roles].

=== Account impersonation: Schema Registry support

xref:security:cloud-authentication.adoc#account-impersonation[Account impersonation] now supports Schema Registry in addition to the Kafka API. With Schema Registry impersonation enabled, the schemas and subjects users see in the Redpanda Cloud UI match exactly what they can access with the Cloud API or `rpk`. You can enable impersonation independently for each subsystem from the *Dataplane settings* page.

=== Extended Serverless free trial

The free trial for Redpanda Serverless now lasts 30 days, up from 14 days. The $100 (USD) credit allowance and 7-day grace period are unchanged. Sign up at https://www.redpanda.com/try-data-streaming[redpanda.com^]. See xref:get-started:cluster-types/serverless.adoc[Serverless clusters].
Expand Down
21 changes: 13 additions & 8 deletions modules/security/pages/cloud-authentication.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -115,27 +115,32 @@ Administrators can require MFA for all users in an organization.

=== Account impersonation

include::shared:partial$feature-flag.adoc[]

BYOC and Dedicated clusters support unified authentication and authorization between the Redpanda Cloud UI and Redpanda with account impersonation. With account impersonation enabled, the topics and resources users see in the UI match exactly what they can access with the Cloud API or `rpk`. You can use the same credentials to authenticate to both Redpanda Cloud and the underlying Redpanda cluster, with consistent permissions across all interfaces. This ensures accurate audit logs and unified identity enforcement across all client applications, including the Cloud UI.
BYOC and Dedicated clusters support unified authentication and authorization between the Redpanda Cloud UI and Redpanda with account impersonation. With account impersonation enabled, the topics, schemas, and other resources users see in the UI match exactly what they can access with the Cloud API or `rpk`. You can use the same credentials to authenticate to both Redpanda Cloud and the underlying Redpanda cluster, with consistent permissions across all interfaces. This ensures accurate audit logs and unified identity enforcement across all client applications, including the Cloud UI.

* *Without account impersonation*: Redpanda Cloud uses a static service account to access your cluster. All UI requests appear to come from this generic admin user.
* *With account impersonation*: Redpanda Cloud uses your individual user credentials and evaluates permissions using glossterm:ACL[,access control lists (ACLs)] and glossterm:RBAC[,role-based access control (RBAC)] in the data plane. Each user sees only the resources they have permission to access.
* *With account impersonation*: Redpanda Cloud uses your individual user credentials and evaluates permissions using glossterm:ACL[,access control lists (ACLs)] and glossterm:RBAC[,role-based access control (RBAC)] in the data plane. Each user sees only the resources they have permission to access.

You can enable account impersonation independently for each subsystem:

* *Kafka API*: Impersonate users for topic, consumer group, and transaction operations.
* *Schema Registry*: Impersonate users for schema and subject operations. Enabling Schema Registry impersonation also enables xref:manage:schema-reg/schema-reg-authorization.adoc[Schema Registry Authorization] on the cluster, and seeds Schema Registry permissions into the predefined Admin, Writer, and Reader roles. See xref:security:authorization/rbac/rbac.adoc#predefined-roles[Predefined roles].

To enable account impersonation:

. Go to the *Dataplane settings* page and select the option to enable account impersonation.
. Go to the *Dataplane settings* page.
. Enable impersonation for *Kafka API*, *Schema Registry*, or both.
. Configure permissions for your users on the cluster *Security* page using ACLs or RBAC roles.

[IMPORTANT]
====
After enabling account impersonation:

* *Admin users* continue to have full access as before
* *Reader and Writer users* will lose access to the cluster until you explicitly grant them permissions through ACLs or RBAC roles on the *Security* page
* *Admin and Writer users* continue to have full Kafka and Schema Registry access through the predefined roles.
* *Reader users* keep read access to topics, consumer groups, and Schema Registry subjects through the predefined Reader role.
* *Custom roles or users without role bindings* will lose access until you explicitly grant them permissions through ACLs or RBAC roles on the *Security* page.
Comment on lines +138 to +140
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot May 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Writer role access is overstated as “full” and can mislead authorization expectations.

Line 138 should not describe Writer as having full Kafka and Schema Registry access. Writer permissions are predefined but not admin-equivalent, so this wording is materially inaccurate.

✏️ Proposed wording fix 
-* *Admin and Writer users* continue to have full Kafka and Schema Registry access through the predefined roles.
+* *Admin users* continue to have full Kafka and Schema Registry access through the predefined Admin role.
+* *Writer users* continue to have Writer-level Kafka and Schema Registry permissions through the predefined Writer role.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
* *Admin and Writer users* continue to have full Kafka and Schema Registry access through the predefined roles.
* *Reader users* keep read access to topics, consumer groups, and Schema Registry subjects through the predefined Reader role.
* *Custom roles or users without role bindings* will lose access until you explicitly grant them permissions through ACLs or RBAC roles on the *Security* page.
* *Admin users* continue to have full Kafka and Schema Registry access through the predefined Admin role.
* *Writer users* continue to have Writer-level Kafka and Schema Registry permissions through the predefined Writer role.
* *Reader users* keep read access to topics, consumer groups, and Schema Registry subjects through the predefined Reader role.
* *Custom roles or users without role bindings* will lose access until you explicitly grant them permissions through ACLs or RBAC roles on the *Security* page.
🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@modules/security/pages/cloud-authentication.adoc` around lines 138 - 140, The
phrase "Admin and Writer users continue to have full Kafka and Schema Registry
access through the predefined roles" overstates Writer permissions; update the
copy so Admin is described as having full/admin access while Writer is described
as having predefined write permissions (e.g., topic produce/write and subject
write) but not full admin-equivalent rights. Locate the sentence that begins
"Admin and Writer users" and replace "full Kafka and Schema Registry access" for
Writer with wording like "predefined write permissions for Kafka topics and
appropriate Schema Registry subjects (not full admin privileges)" and leave
Admin described as having full access; ensure subsequent lines referencing
"Writer role" or "Reader users" remain consistent.


Plan to configure user permissions before or immediately after enabling this feature to avoid access disruption.
====
====

== Service authentication

Expand Down
26 changes: 25 additions & 1 deletion modules/security/partials/predefined-roles.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,27 @@
Redpanda Cloud provides several predefined roles that you cannot modify or delete, including Reader, Writer, and Admin.
Redpanda Cloud provides several predefined roles that you cannot modify or delete, including Reader, Writer, and Admin.

Before assigning a role to a user or service account, review the *Organization IAM* - *Roles* tab to compare the full list of predefined roles and their permissions.

[NOTE]
====
On BYOC and Dedicated clusters, the Reader, Writer, and Admin roles include data plane permissions for the Schema Registry in addition to Kafka resources (topics, consumer groups, transactional IDs, and cluster operations). Permissions are scoped to the `subject` and `registry` ACL resource types.

[cols="1,3,2"]
|===
| Role | `subject` operations (resource name `*`) | `registry` operations (global)

| Reader
| Read, Describe
| Describe, DescribeConfigs

| Writer
| Read, Write, Delete, Describe, DescribeConfigs
| Describe, DescribeConfigs

| Admin
| Read, Write, Delete, Describe, DescribeConfigs, AlterConfigs
| Describe, DescribeConfigs, AlterConfigs
|===

For more information on Schema Registry ACLs, including resource types and supported operations, see xref:manage:schema-reg/schema-reg-authorization.adoc[].
====