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

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

Schema Registry Authorization is now enabled fleet-wide on BYOC and
Dedicated clusters. The schema_registry_enable_authorization cluster
property is set automatically at provisioning, and the predefined Admin,
Writer, and Reader roles are seeded with Schema Registry permissions
(subject/* and registry resources). Account impersonation also now
supports Schema Registry as a separate subsystem from the Kafka API.

- Add SR permissions table to predefined-roles partial
- Update Account impersonation section to reflect per-subsystem toggles
  (Kafka API + Schema Registry) and the new default-role behavior
- Add May 2026 What's New entries for SR auth-by-default and SR
  impersonation

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* DOC-1936: Accurately scope Writer role permissions in impersonation warning

Writer lacks AlterConfigs and has no write ops at the registry resource level,
so "full access" only applies to Admin. Split the bullet to reflect this.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: micheleRP

modules/get-started/pages/whats-new-cloud.adoc

@@ -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].

modules/security/pages/cloud-authentication.adoc

@@ -115,27 +115,33 @@ 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 users* continue to have full Kafka and Schema Registry access through the predefined Admin role.
+* *Writer users* continue to have read and write permissions for Kafka topics and Schema Registry subjects 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.
 
 Plan to configure user permissions before or immediately after enabling this feature to avoid access disruption.
-==== 
+====
 
 == Service authentication
 

modules/security/partials/predefined-roles.adoc

@@ -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[].
+====