redpanda-data · JakeSCahill · Mar 31, 2026 · Apr 1, 2026 · Apr 1, 2026 · Apr 1, 2026
@@ -15,7 +15,7 @@ content:
   - url: .
     branches: HEAD
   - url: https://github.com/redpanda-data/documentation
-    branches: [main, v/*, shared, site-search]
+    branches: [DOC-1809-remove-register-groups-from-gbac-dp, v/*, shared, site-search]
   - url: https://github.com/redpanda-data/docs-site
     branches: [main]
     start_paths: [home]

@@ -533,6 +533,9 @@
 *** xref:security:authorization/rbac/index.adoc[Role-Based Access Control (RBAC)]
 **** xref:security:authorization/rbac/rbac.adoc[]
 **** xref:security:authorization/rbac/rbac_dp.adoc[]
+*** xref:security:authorization/gbac/index.adoc[Group-Based Access Control (GBAC)]
+**** xref:security:authorization/gbac/gbac.adoc[]
+**** xref:security:authorization/gbac/gbac_dp.adoc[]
 *** xref:security:authorization/rbac/acl.adoc[Access Control Lists (ACLs)]
 *** xref:security:authorization/cloud-iam-policies.adoc[]
 *** xref:security:authorization/cloud-iam-policies-gcp.adoc[]

@@ -53,4 +53,4 @@ The default Writer role provides broad access suitable for most use cases. If yo
 . Find the service account for your resource.
 . Edit the role bindings to use a more restrictive role or scope.
 
-For more information about roles and permissions, see xref:security:authorization/rbac/rbac.adoc[Role-based access control].
+For more information about roles and permissions, see xref:security:authorization/rbac/rbac.adoc[Role-based access control] or xref:security:authorization/gbac/gbac.adoc[Group-based access control].
@@ -37,7 +37,7 @@ Notifications are sent to email only. The subject line follows this format:
 
 == Who receives notifications
 
-All users with the *Admin* role in your organization receive billing notifications by default. To change who receives notifications, update role assignments on the *Organization IAM* page. See xref:security:authorization/rbac/rbac.adoc[Role-Based Access Control].
+All users with the *Admin* role in your organization receive billing notifications by default. To change who receives notifications, update role assignments on the *Organization IAM* page. See xref:security:authorization/rbac/rbac.adoc[Role-Based Access Control] or xref:security:authorization/gbac/gbac.adoc[Group-Based Access Control].
 
 == Opt out of notifications
 

@@ -9,9 +9,9 @@ For high availability, Redpanda Cloud uses the following control plane - data pl
 
 image::shared:control_d_plane.png[Control plane and data plane]
 
-* *Control plane*: This is a Redpanda Cloud managed service that manages provisioning, operations, and maintenance of clusters with Kubernetes under the hood, including Kubernetes version upgrades and infrastructure maintenance. The control plane enforces rules in the data plane. You can use role-based access control xref:security:authorization/rbac/rbac.adoc[(RBAC) in the control plane] to manage access to organization-level resources like clusters, resource groups, and networks.
+* *Control plane*: This is a Redpanda Cloud managed service that manages provisioning, operations, and maintenance of clusters with Kubernetes under the hood, including Kubernetes version upgrades and infrastructure maintenance. The control plane enforces rules in the data plane. You can use xref:security:authorization/rbac/rbac.adoc[RBAC] or xref:security:authorization/gbac/gbac.adoc[GBAC] in the control plane to manage access to organization-level resources like clusters, resource groups, and networks.
 
-* *Data plane*: This is where your cluster lives. The term _data plane_ is sometimes used interchangeably with _cluster_. The data plane is where you manage topics, consumer groups, connectors, and schemas. You can use xref:security:authorization/rbac/rbac_dp.adoc[RBAC in the data plane] to configure cluster-level permissions for provisioned users at scale. 
+* *Data plane*: This is where your cluster lives. The term _data plane_ is sometimes used interchangeably with _cluster_. The data plane is where you manage topics, consumer groups, connectors, and schemas. You can use xref:security:authorization/rbac/rbac_dp.adoc[RBAC] or xref:security:authorization/gbac/gbac_dp.adoc[GBAC] in the data plane to configure cluster-level permissions for provisioned users at scale. 
 
 IAM permissions allow the Redpanda Cloud agent to access the cloud provider API to create and manage cluster resources. The permissions follow the principle of least privilege, limiting access to only what is necessary.
 

@@ -91,7 +91,12 @@ Redpanda Cloud applications are supported by three fully-managed deployment opti
 | ✓
 | ✓
 
-| *RBAC & audit logs*
+| *Role-based access control (RBAC) & audit logs*
+| ✗
+| ✓
+| ✓
+
+| *Group-based access control (GBAC)*
 | ✗
 | ✓
 | ✓
@@ -200,6 +205,7 @@ Consider BYOC or Dedicated if you need more control over the deployment or if yo
 * Redpanda Agentic Data Plane (ADP): BYOC only
 * Multiple availability zones (AZs). A multi-AZ cluster provides higher resiliency in the event of a failure in one of the zones. 
 * Role-based access control (RBAC) in the data plane
+* Group-based access control (GBAC)
 * Kafka Connect
 * Higher limits and quotas. See xref:reference:tiers/byoc-tiers.adoc[BYOC usage tiers] and xref:reference:tiers/dedicated-tiers.adoc[Dedicated usage tiers] compared to xref:get-started:cluster-types/serverless.adoc#serverless-usage-limits[Serverless limits].
 

@@ -100,7 +100,8 @@ Not all features included in BYOC clusters are available in Serverless. For exam
 
 * HTTP Proxy API
 * Multiple availability zones (AZs)
-* RBAC in the data plane and mTLS authentication for Kafka API clients
+* Role-based access control (RBAC) in the data plane and mTLS authentication for Kafka API clients
+* Group-based access control (GBAC)
 * Kafka Connect 
 
 == Next steps

@@ -6,6 +6,14 @@
 
 This page lists new features added to Redpanda Cloud.
 
+== April 2026
+
+=== Group-based access control (GBAC)
+
+With xref:security:authorization/gbac/gbac.adoc[GBAC in the control plane], you can manage access to organization-level resources using OIDC groups from your identity provider. Assign OIDC groups to roles so that users inherit access based on their group membership. 
+
+With xref:security:authorization/gbac/gbac_dp.adoc[GBAC in the data plane], you can configure cluster-level permissions for provisioned users at scale using OIDC groups. Because group membership is managed by your identity provider, onboarding and offboarding require no changes in Redpanda. GBAC is available for BYOC and Dedicated clusters.
+
 == March 2026
 
 === Redpanda Connect updates

@@ -7,6 +7,7 @@ There are two types of authorization in Redpanda Cloud:
 * User authorization
 +
 ** Use xref:security:authorization/rbac/index.adoc[role-based access control (RBAC)] in the glossterm:control plane[] and in the glossterm:data plane[] to assign users access to specific resources. For example, you could grant everyone access to clusters in a development resource group while limiting access to clusters in a production resource group. Or, you could limit access to geographically-dispersed clusters in accordance with data residency laws. This alleviates the process of manually maintaining and verifying a set of ACLs for a user base that may contain thousands of users.
+** Use xref:security:authorization/gbac/index.adoc[group-based access control (GBAC)] in the glossterm:control plane[] and in the glossterm:data plane[] to manage permissions at the group level using OIDC. Assign OIDC groups to roles or create ACLs with `Group:<name>` principals, so that users inherit access based on their group membership in your identity provider. Because group membership is managed by your identity provider, onboarding and offboarding require no changes in Redpanda.
 ** Use Kafka glossterm:ACL[,access control lists (ACLs)] to grant users permission to perform specific types of operations on specific resources (such as topics, groups, clusters, or transactional IDs). ACLs provide a way to configure fine-grained access to provisioned users. ACLs work with SASL/SCRAM and with mTLS with principal mapping for authentication.
 
 * BYOC agent authorization

@@ -0,0 +1,101 @@
+= Configure GBAC in the Control Plane
+:description: Configure GBAC to manage access to organization-level resources, like clusters, resource groups, and networks, using OIDC groups from your identity provider.
+:page-topic-type: how-to
+:learning-objective-1: Register an OIDC group in Redpanda Cloud
+:learning-objective-2: Assign a predefined or custom role to a group
+:learning-objective-3: Manage group-based access at the organization level
+
+NOTE: This feature is available for BYOC and Dedicated clusters.
+
+Use Redpanda Cloud group-based access control (GBAC) in the glossterm:control plane[] to manage and restrict access to resources in your organization using OIDC groups from your identity provider. For example, you could grant everyone in a group access to clusters in a development resource group while limiting access to clusters in a production resource group. Or, you could limit access to geographically-dispersed clusters in accordance with data residency laws.
+
+After reading this page, you will be able to:
+
+* [ ] {learning-objective-1}
+* [ ] {learning-objective-2}
+* [ ] {learning-objective-3}
+
+The following resources can be assigned as the scope of a role: 
+
+- Organization 	
+- Resource groups
+- Networks
+- Network peerings
+- Clusters (Serverless clusters have a different set of permissions from BYOC and Dedicated clusters.) 
+- Topics
+- MCP servers
+- AI agents
+- AI gateway
+- AI Gateway models
+- AI Gateway model providers
+- AI Gateway config
+
+You can manage these GBAC configurations with the https://cloud.redpanda.com[Redpanda Cloud Console^] or with the link:/api/doc/cloud-controlplane/[Control Plane API].
+
+== GBAC terminology
+
+**Group**: A group is a collection of users defined in your identity provider. With GBAC, you can assign groups to roles or ACLs in Redpanda Cloud, so that users inherit permissions based on their group membership in your identity provider.
+
+**Role**: A role is a list of permissions. Permissions are attached to roles. Users assigned multiple roles receive the union of all permissions defined in those roles. Redpanda Cloud has three predefined roles: Reader, Writer, and Admin, but you can also create custom roles.
+
+**Role binding**: Role binding assigns a role to an account. 
+
+== Manage access for organization
+
+In the Redpanda Cloud Console, the *Organization IAM* page lets you create groups, edit a user's access, invite new users, and create service accounts. 
+
+== Register groups in Redpanda Cloud
+
+To assign an IdP group to a role or ACL, you must first register the group:
+
+[tabs]
+====
+Cloud UI::
++
+--
+. In the left navigation menu, select *Organization IAM*, then select the *Groups* tab.
+. Click *Create group*.
+. Enter a *Name* that matches the group in your IdP exactly (for example, `engineering`).
+. Optionally, enter a *Description*, and configure a *Role binding* to assign the group to a role with a specific scope and resource.
+. Click *Create*.
+--
+
+Control Plane API::
++
+--
+Make a link:/api/doc/cloud-controlplane/operation/operation-groupservice_creategroup[`POST /v1/groups`] request to the xref:redpanda-cloud:manage:api/cloud-byoc-controlplane-api.adoc[Control Plane API]:
+
+[,bash]
+----
+curl -X POST 'https://api.redpanda.com/v1/groups' \
+  -H 'Content-Type: application/json' \
+  -H 'Authorization: Bearer <token>' \
+  -d '{
+    "group": {
+      "name": "<group-name>",
+      "description": "<group-description>"
+    }
+  }'
+----
+
+Replace `<group-name>` with the name that matches the group in your IdP (for example, `engineering`). The name must match exactly for GBAC to map the group correctly.
+--
+====
+
+== Predefined roles
+
+include::security:partial$predefined-roles.adoc[]
+
+== Custom roles
+
+In addition to the predefined roles, administrators can create custom roles to mix and match permissions for specific use cases. Custom roles let you grant only the permissions a group needs, without the broad access of the predefined Reader, Writer, or Admin roles.
+
+Custom roles are created on the *Roles* tab in *Organization IAM*. For steps to create a custom role, see xref:security:authorization/rbac/rbac.adoc#custom-roles[Custom roles in RBAC].
+
+When you register a group or edit a group's role binding, you can assign any predefined or custom role to the group.
+
+== Suggested reading
+
+* xref:security:authorization/gbac/gbac_dp.adoc[]
+* xref:security:authorization/rbac/rbac.adoc[]
+* xref:security:authorization/rbac/rbac_dp.adoc[]
@@ -0,0 +1,17 @@
+= Configure GBAC in the Data Plane
+:description: Configure GBAC to manage access for provisioned users to cluster-level resources, like topics and consumer groups, using OIDC groups from your identity provider.
+:learning-objective-1: Configure the cluster properties that enable GBAC
+:learning-objective-2: Assign an OIDC group to an RBAC role
+:learning-objective-3: Create a group-based ACL using the Group: principal prefix
+
+NOTE: This feature is available for BYOC and Dedicated clusters.
+
+Use group-based access control (GBAC) in the glossterm:data plane[] to configure cluster-level permissions for provisioned users at scale. GBAC works in conjunction with all supported authentication methods.
+
+include::ROOT:manage:partial$gbac-dp.adoc[tag=single-source]
+
+== Suggested reading
+
+* xref:security:authorization/gbac/gbac.adoc[]
+* xref:security:authorization/rbac/rbac.adoc[]
+* xref:security:authorization/rbac/rbac_dp.adoc[]
@@ -0,0 +1,3 @@
+= Group-Based Access Control (GBAC)
+:description: Learn about configuring group-based access control (GBAC) in the control plane and in the data plane.
+:page-layout: index