Skip to content

Commit a93a39a

Browse files
JakeSCahillmicheleRPclaudekbatuigas
authored
DOC-1809 Document Cloud Feature Group-based Access Control via OIDC (#542)
* DOC-1809 Document Cloud Feature Group-based Access Control via OIDC (#536) * DOC-1809 Document Cloud Feature Group-based Access Control via OIDC * note GBAC not supported in Serverless * trigger Netlify rebuild * Apply suggestion from @JakeSCahill --------- Co-authored-by: Jake Cahill <45230295+JakeSCahill@users.noreply.github.com> * docs: Set up GBAC folder structure mirroring RBAC with CP/DP pages Restructure GBAC documentation to mirror the RBAC pattern with separate control plane and data plane pages. Create shared predefined-roles partial, add custom roles documentation, and update cross-references across the repo. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * add docs metadata * point playbook to docs PR * edits * minor edit * update predefined roles + style/consistency edits * update SSO for GBAC * add links to SSO * Use group claim extraction partial * minor edits * review fixes: revert playbook, headings, trailing newlines, index intro Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Michele Cyran <michele@redpanda.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-authored-by: Kat Batuigas <kbatuigas@gmail.com>
1 parent 8c22b23 commit a93a39a

File tree

15 files changed

+214
-47
lines changed

15 files changed

+214
-47
lines changed

modules/ROOT/nav.adoc

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -533,6 +533,9 @@
533533
*** xref:security:authorization/rbac/index.adoc[Role-Based Access Control (RBAC)]
534534
**** xref:security:authorization/rbac/rbac.adoc[]
535535
**** xref:security:authorization/rbac/rbac_dp.adoc[]
536+
*** xref:security:authorization/gbac/index.adoc[Group-Based Access Control (GBAC)]
537+
**** xref:security:authorization/gbac/gbac.adoc[]
538+
**** xref:security:authorization/gbac/gbac_dp.adoc[]
536539
*** xref:security:authorization/rbac/acl.adoc[Access Control Lists (ACLs)]
537540
*** xref:security:authorization/cloud-iam-policies.adoc[]
538541
*** xref:security:authorization/cloud-iam-policies-gcp.adoc[]

modules/ai-agents/partials/service-account-authorization.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -53,4 +53,4 @@ The default Writer role provides broad access suitable for most use cases. If yo
5353
. Find the service account for your resource.
5454
. Edit the role bindings to use a more restrictive role or scope.
5555

56-
For more information about roles and permissions, see xref:security:authorization/rbac/rbac.adoc[Role-based access control].
56+
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].

modules/billing/pages/billing-notifications.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -37,7 +37,7 @@ Notifications are sent to email only. The subject line follows this format:
3737

3838
== Who receives notifications
3939

40-
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].
40+
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].
4141

4242
== Opt out of notifications
4343

modules/get-started/pages/byoc-arch.adoc

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -9,9 +9,9 @@ For high availability, Redpanda Cloud uses the following control plane - data pl
99

1010
image::shared:control_d_plane.png[Control plane and data plane]
1111

12-
* *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.
12+
* *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.
1313

14-
* *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.
14+
* *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.
1515

1616
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.
1717

modules/get-started/pages/cloud-overview.adoc

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -91,7 +91,12 @@ Redpanda Cloud applications are supported by three fully-managed deployment opti
9191
| ✓
9292
| ✓
9393

94-
| *RBAC & audit logs*
94+
| *Role-based access control (RBAC) & audit logs*
95+
| ✗
96+
| ✓
97+
| ✓
98+
99+
| *Group-based access control (GBAC)*
95100
| ✗
96101
| ✓
97102
| ✓
@@ -200,6 +205,7 @@ Consider BYOC or Dedicated if you need more control over the deployment or if yo
200205
* Redpanda Agentic Data Plane (ADP): BYOC only
201206
* Multiple availability zones (AZs). A multi-AZ cluster provides higher resiliency in the event of a failure in one of the zones.
202207
* Role-based access control (RBAC) in the data plane
208+
* Group-based access control (GBAC)
203209
* Kafka Connect
204210
* 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].
205211

modules/get-started/pages/cluster-types/serverless.adoc

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -100,7 +100,8 @@ Not all features included in BYOC clusters are available in Serverless. For exam
100100

101101
* HTTP Proxy API
102102
* Multiple availability zones (AZs)
103-
* RBAC in the data plane and mTLS authentication for Kafka API clients
103+
* Role-based access control (RBAC) in the data plane and mTLS authentication for Kafka API clients
104+
* Group-based access control (GBAC)
104105
* Kafka Connect
105106

106107
== Next steps

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

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,13 @@ This page lists new features added to Redpanda Cloud.
88

99
== April 2026
1010

11+
=== Group-based access control (GBAC)
12+
13+
GBAC is available for BYOC and Dedicated clusters. In addition to the predefined roles (including Reader, Writer, and Admin) that you cannot modify or delete, you can also create custom roles.
14+
15+
* 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.
16+
* 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.
17+
1118
=== Increased Serverless limits for Redpanda Connect pipelines and MCP servers
1219

1320
Serverless clusters now support up to 100 Redpanda Connect pipelines and 100 MCP servers. See xref:get-started:cluster-types/serverless.adoc#_serverless_usage_limits[Serverless usage limits].

modules/security/pages/authorization/cloud-authorization.adoc

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -7,6 +7,7 @@ There are two types of authorization in Redpanda Cloud:
77
* User authorization
88
+
99
** 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.
10+
** 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.
1011
** 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.
1112
1213
* BYOC agent authorization
Lines changed: 102 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,102 @@
1+
= Configure GBAC in the Control Plane
2+
:description: Configure GBAC to manage access to organization-level resources, like clusters, resource groups, and networks, using OIDC groups from your identity provider.
3+
:page-topic-type: how-to
4+
:learning-objective-1: Register an OIDC group in Redpanda Cloud
5+
:learning-objective-2: Assign a predefined or custom role to a group
6+
:learning-objective-3: Manage group-based access at the organization level
7+
8+
NOTE: This feature is available for BYOC and Dedicated clusters.
9+
10+
Use Redpanda Cloud group-based access control (GBAC) in the glossterm:control plane[] to manage access to organization resources based on OIDC groups from your identity provider (IdP). For example, you can grant one group access to development clusters while restricting production access to another group. You can also restrict access to geographically dispersed clusters to support data residency requirements. When a user's group membership changes in the IdP, their Redpanda access updates automatically.
11+
12+
After reading this page, you will be able to:
13+
14+
* [ ] {learning-objective-1}
15+
* [ ] {learning-objective-2}
16+
* [ ] {learning-objective-3}
17+
18+
== GBAC terminology
19+
20+
**Group**: A group is a collection of users defined in your IdP. 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 IdP.
21+
22+
**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 several predefined roles that you cannot modify or delete, including Reader, Writer, and Admin. You can also create custom roles.
23+
24+
**Role binding**: Role binding assigns a role to an account. Administrators can add, edit, or remove role bindings for a user. When you change the permissions for a given role, all users and service accounts with that role automatically get the modified permissions.
25+
26+
== Manage organization access
27+
28+
In the Redpanda Cloud Console, the *Organization IAM* page lets you create groups. When you create a group, you define its permissions with role binding. When you edit a group, you can change its role bindings to update the group's permissions. When you change the permissions for a given role, all groups with that role automatically get the modified permissions.
29+
30+
Various resources can be assigned as the scope of a role, including the following:
31+
32+
- Organization
33+
- Resource group
34+
- Network
35+
- Network peering
36+
- Cluster (Serverless clusters have a different set of permissions from BYOC and Dedicated clusters.)
37+
- MCP server
38+
39+
You can manage GBAC configurations with the https://cloud.redpanda.com[Redpanda Cloud Console^] or with the link:/api/doc/cloud-controlplane/[Control Plane API].
40+
41+
== Configure group claim extraction
42+
43+
Different identity providers structure group information differently in their OIDC tokens. Before you register groups, configure your SSO connection to tell Redpanda Cloud where to find group claims in the token.
44+
45+
include::ROOT:manage:partial$gbac-token-claim-extraction.adoc[]
46+
47+
== Register groups
48+
49+
To assign an IdP group to a role or ACL, you must first register the group in Redpanda Cloud:
50+
51+
[tabs]
52+
====
53+
Cloud UI::
54+
+
55+
--
56+
. Navigate to *Organization IAM > Groups*.
57+
. Click *Create group*.
58+
. Enter a *Name* that matches the group in your IdP exactly (for example, `engineering`).
59+
. Optionally, enter a *Description*, and configure a *Role binding* to assign the group to a role with a specific scope and resource.
60+
. Click *Create*.
61+
--
62+
63+
Control Plane API::
64+
+
65+
--
66+
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]:
67+
68+
[,bash]
69+
----
70+
curl -X POST 'https://api.redpanda.com/v1/groups' \
71+
-H 'Content-Type: application/json' \
72+
-H 'Authorization: Bearer <token>' \
73+
-d '{
74+
"group": {
75+
"name": "<group-name>",
76+
"description": "<group-description>"
77+
}
78+
}'
79+
----
80+
81+
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.
82+
--
83+
====
84+
85+
== Predefined roles
86+
87+
include::security:partial$predefined-roles.adoc[]
88+
89+
== Custom roles
90+
91+
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 predefined roles.
92+
93+
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].
94+
95+
When you register a group or edit a group's role binding, you can assign any predefined or custom role to the group.
96+
97+
== Suggested reading
98+
99+
* xref:security:authorization/gbac/gbac_dp.adoc[]
100+
* xref:security:authorization/rbac/rbac.adoc[]
101+
* xref:security:authorization/rbac/rbac_dp.adoc[]
102+
* xref:security:cloud-authentication.adoc#single-sign-on[Single sign-on]
Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
= Configure GBAC in the Data Plane
2+
: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.
3+
:page-topic-type: how-to
4+
:learning-objective-1: Configure the cluster properties that enable GBAC
5+
:learning-objective-2: Assign an OIDC group to an RBAC role
6+
:learning-objective-3: Create a group-based ACL using the Group: principal prefix
7+
8+
NOTE: This feature is available for BYOC and Dedicated clusters.
9+
10+
include::ROOT:manage:partial$gbac-dp.adoc[tag=single-source]
11+
12+
== Suggested reading
13+
14+
* xref:security:authorization/gbac/gbac.adoc[]
15+
* xref:security:authorization/rbac/rbac.adoc[]
16+
* xref:security:authorization/rbac/rbac_dp.adoc[]
17+
* xref:security:cloud-authentication.adoc#single-sign-on[Single sign-on]

0 commit comments

Comments
 (0)