GBAC

modules/ROOT/nav.adoc

@@ -173,6 +173,7 @@
 *** xref:manage:security/authentication.adoc[Authentication]
 *** xref:manage:security/authorization/index.adoc[Authorization]
 **** xref:manage:security/authorization/rbac.adoc[Role-Based Access Control (RBAC)]
+**** xref:manage:security/authorization/gbac.adoc[Group-Based Access Control (GBAC)]
 **** xref:manage:security/authorization/acl.adoc[Access Control Lists (ACLs)]
 *** xref:manage:security/fips-compliance.adoc[FIPS Compliance]
 *** xref:manage:security/encryption.adoc[]

modules/get-started/pages/release-notes/redpanda.adoc

@@ -7,6 +7,17 @@ This topic includes new content added in version {page-component-version}. For a
 * xref:redpanda-cloud:get-started:whats-new-cloud.adoc[]
 * xref:redpanda-cloud:get-started:cloud-overview.adoc#redpanda-cloud-vs-self-managed-feature-compatibility[Redpanda Cloud vs Self-Managed feature compatibility]
 
+== Group-based access control (GBAC)
+
+Redpanda {page-component-version} introduces xref:manage:security/authorization/gbac.adoc[group-based access control (GBAC)], which extends OIDC authentication to support group-based permissions. In addition to assigning roles or ACLs to individual users, you can assign them to OIDC groups. Users inherit permissions from all groups reported by their identity provider (IdP) in the OIDC token claims.
+
+GBAC supports two authorization patterns:
+
+* Assign a group as a member of an RBAC role so that all users in the group inherit the role's ACLs.
+* Create ACLs directly with a `Group:<name>` principal.
+
+Group membership is managed entirely by your IdP. Redpanda reads group information from the OIDC token at authentication time and works across the Kafka API, Schema Registry, and HTTP Proxy.
+
 == FIPS 140-3 validation and FIPS Docker image
 
 Redpanda's cryptographic module has been upgraded from FIPS 140-2 to https://csrc.nist.gov/pubs/fips/140-3/final[FIPS 140-3^] validation. Additionally, Redpanda now provides a FIPS-specific Docker image (`docker.redpanda.com/redpandadata/redpanda:<version>-fips`) for `amd64` and `arm64` architectures, with the required OpenSSL FIPS module pre-configured.
@@ -34,3 +45,10 @@ xref:develop:produce-data/leader-pinning.adoc[Leader Pinning] now supports the `
 Redpanda now supports throughput quotas based on authenticated user principals. Unlike client-based quotas (which rely on self-declared `client-id` values), user-based quotas enforce limits using verified identities from SASL, mTLS, or OIDC authentication.
 
 You can set quotas for individual users, default users, or fine-grained user/client combinations. See xref:manage:cluster-maintenance/about-throughput-quotas.adoc[] for conceptual details, and xref:manage:cluster-maintenance/manage-throughput.adoc#set-user-based-quotas[Set user-based quotas] to get started.
+
+== New configuration properties
+
+**Authentication:**
+
+* xref:reference:properties/cluster-properties.adoc#nested_group_behavior[`nested_group_behavior`]: Control how Redpanda handles nested groups extracted from authentication tokens
+* xref:reference:properties/cluster-properties.adoc#oidc_group_claim_path[`oidc_group_claim_path`]: JSON path to extract groups from the JWT payload

modules/manage/pages/audit-logging/audit-log-samples.adoc

@@ -3,6 +3,9 @@
 :page-categories: Management, Security
 // tag::single-source[]
 
+ifdef::env-cloud[:gbac-doc: security:authorization/gbac.adoc]
+ifndef::env-cloud[:gbac-doc: manage:security/authorization/gbac.adoc]
+
 ifndef::env-cloud[]
 [NOTE]
 ====
@@ -80,6 +83,59 @@ This scenario shows the message resulting from an admin using rpk with successfu
 ----
 ====
 
+.Authentication successful (OIDC with group claims)
+[%collapsible]
+====
+This scenario shows a successful OIDC authentication event that includes the user's IdP group memberships in the `user.groups` field. Group memberships are extracted from the OIDC token and included in all authentication events for OIDC users.
+[,json]
+----
+{
+  "category_uid": 3,
+  "class_uid": 3002,
+  "metadata": {
+    "product": {
+      "name": "Redpanda",
+      "uid": "0",
+      "vendor_name": "Redpanda Data, Inc.",
+      "version": "v26.1.1"
+    },
+    "version": "1.0.0"
+  },
+  "severity_id": 1,
+  "time": 1700533469078,
+  "type_uid": 300201,
+  "activity_id": 1,
+  "auth_protocol": "SASL-OAUTHBEARER",
+  "auth_protocol_id": 99,
+  "dst_endpoint": {
+    "ip": "127.0.0.1",
+    "port": 9092,
+    "svc_name": "kafka rpc protocol"
+  },
+  "is_cleartext": false,
+  "is_mfa": false,
+  "service": {
+    "name": "kafka rpc protocol"
+  },
+  "src_endpoint": {
+    "ip": "10.0.1.50",
+    "name": "kafka-client",
+    "port": 48210
+  },
+  "status_id": 1,
+  // IdP group memberships extracted from the OIDC token
+  "user": {
+    "name": "alice@example.com",
+    "type_id": 1,
+    "groups": [
+      {"type": "idp_group", "name": "engineering"},
+      {"type": "idp_group", "name": "analytics"}
+    ]
+  }
+}
+----
+====
+
 .Authentication failed
 [%collapsible]
 ====
@@ -237,6 +293,93 @@ This example illustrates an ACL update that also requires a superuser authentica
 ----
 ====
 
+.Authorization matched on a group ACL
+[%collapsible]
+====
+This example shows an API Activity (6003) where the authorization decision matched an ALLOW ACL on a `Group:` principal. The `actor.user.groups` field includes the matched group with type `idp_group`, and the `authorization_metadata` shows the group ACL that granted access. See xref:{gbac-doc}[Group-Based Access Control].
+
+[,json]
+----
+{
+  "category_uid": 6,
+  "class_uid": 6003,
+  "metadata": {
+    "product": {
+      "name": "Redpanda",
+      "uid": "0",
+      "vendor_name": "Redpanda Data, Inc.",
+      "version": "v26.1.0"
+    },
+    "version": "1.0.0"
+  },
+  "severity_id": 1,
+  "time": 1774544504327,
+  "type_uid": 600303,
+  "activity_id": 3,
+  "actor": {
+    "authorizations": [
+      {
+        "decision": "authorized",
+        "policy": {
+          "desc": "acl: {principal type {group} name {/sales} host {{any_host}} op all perm allow}, resource: type {topic} name {sales-topic} pattern {literal}",
+          "name": "aclAuthorization"
+        }
+      }
+    ],
+    // The matched group appears in the user's groups field
+    "user": {
+      "name": "alice",
+      "type_id": 1,
+      "groups": [
+        {
+          "type": "idp_group",
+          "name": "/sales"
+        }
+      ]
+    }
+  },
+  "api": {
+    "operation": "produce",
+    "service": {
+      "name": "kafka rpc protocol"
+    }
+  },
+  "dst_endpoint": {
+    "ip": "127.0.1.1",
+    "port": 9092,
+    "svc_name": "kafka rpc protocol"
+  },
+  "resources": [
+    {
+      "name": "sales-topic",
+      "type": "topic"
+    }
+  ],
+  "src_endpoint": {
+    "ip": "127.0.0.1",
+    "name": "rdkafka",
+    "port": 42728
+  },
+  "status_id": 1,
+  "unmapped": {
+    "authorization_metadata": {
+      "acl_authorization": {
+        "host": "{{any_host}}",
+        "op": "all",
+        "permission_type": "allow",
+        "principal": "type {group} name {/sales}"
+      },
+      "resource": {
+        "name": "sales-topic",
+        "pattern": "literal",
+        "type": "topic"
+      }
+    }
+  }
+}
+----
+====
+
 .Metadata request (with counts)
 [%collapsible]
 ====

modules/manage/pages/security/authorization/acl.adoc

@@ -62,8 +62,8 @@ Understanding these terms helps you configure least-privilege access.
 | Term | Definition | Example
 
 | Principal
-| The entity (user or role) requesting access
-| `User:analytics-user`, `RedpandaRole:data-engineers`
+| The entity (user, role, or group) requesting access
+| `User:analytics-user`, `RedpandaRole:data-engineers`, `Group:engineering`
 
 | Resource
 | The Redpanda component being accessed (cluster, topic, consumer group, transactional ID, Schema Registry glossterm:subject[], and Schema Registry operation)
@@ -91,7 +91,13 @@ ACL commands work on a multiplicative basis. If you specify two principals and t
 [[principals]]
 === Principals
 
-All ACLs require a principal. A principal is composed of two parts: the type, and the name. Redpanda supports the types "User" and "RedpandaRole". When you create user "bar", Redpanda expects you to add ACLs for "User:bar".
+All ACLs require a principal. A principal is composed of two parts: the type, and the name. Redpanda supports the types "User", "RedpandaRole", and "Group". When you create user "bar", Redpanda expects you to add ACLs for "User:bar". To grant permissions to an OIDC group, use the `Group:` prefix (for example, `Group:engineering`).
+ifndef::env-cloud[]
+See xref:manage:security/authorization/gbac.adoc[].
+endif::[]
+ifdef::env-cloud[]
+See xref:security:authorization/gbac.adoc[].
+endif::[]
 
 The `--allow-principal` and `--deny-principal` flags add this prefix for you, if necessary.
 

modules/manage/pages/security/authorization/gbac.adoc

@@ -0,0 +1,17 @@
+= Configure Group-Based Access Control
+:description: Manage Redpanda permissions at scale using your identity provider's groups. Define access once per group and let your IdP control membership, with no per-user configuration in Redpanda.
+:page-topic-type: how-to
+:page-categories: Management, Security
+:personas: security_engineer, platform_engineer
+: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
+
+ifndef::env-cloud[]
+[NOTE]
+====
+include::shared:partial$enterprise-license.adoc[]
+====
+endif::[]
+
+include::manage:partial$gbac-dp.adoc[]

modules/manage/pages/security/authorization/index.adoc

@@ -1,8 +1,8 @@
 = Configure Authorization
-:description: Redpanda provides two mechanisms for controlling user permissions.
+:description: Redpanda provides mechanisms for controlling user permissions, including ACLs, role-based access control, and group-based access control.
 :page-aliases: security:authorization/index.adoc, manage:security/authorization.adoc
 :page-categories: Management, Security
 :page-layout: index
 
 
-Authorization works in tandem with xref:security/authentication.adoc[authentication]. Authentication grants permission to interact with Redpanda resources while authorization controls what a principal is permitted to do once authenticated.
+Authorization works in tandem with xref:security/authentication.adoc[authentication]. Authentication verifies who a principal is. Authorization controls what that principal can do once authenticated.

modules/manage/partials/audit-logging.adoc

@@ -159,10 +159,11 @@ NOTE: The Included column captures whether the event itself is included (for exa
 |===
 |Data Logging Level |Audit Event |Included? |Details
 
-.11+|System Level
+.12+|System Level
 |Date and time stamp for each entry |Yes |`time` field on each event
 |Successful and failed access attempts |Yes |The `status_id` field shows success/failure for all access attempts for which auditing is enabled
 |User ID |Yes |`user.name`
+|User group memberships |Yes |`user.groups` field with type `idp_group`. Included in authentication events for OIDC users and in authorization events when a group ACL matches. See xref:manage:security/authorization/gbac.adoc[].
 |User connect and disconnect time |No |Connect and disconnect time may be inferred from the presence or absence of activity.
 |Password change |Yes |For SCRAM users managed through Redpanda core, the Admin API call associated with the password change is logged. Note that this does not cover users synced from external IdPs, such as through OIDC.
 |Changes of security settings |Yes |For example, ACL creation is logged (kafka `create_acls`), and cluster configuration changes are logged (Admin API events)

modules/manage/partials/authentication.adoc

@@ -867,6 +867,8 @@ but can instead rely on the trusted authentication capabilities of established I
 Redpanda's implementation of OIDC provides SASL/OAUTHBEARER support for the Kafka API, and supports
 standard OIDC authentication across all other HTTP APIs, including Schema Registry, HTTP Proxy, and the Admin API.
 
+TIP: With OIDC enabled, you can also use xref:manage:security/authorization/gbac.adoc[group-based access control (GBAC)] to assign Redpanda permissions to OIDC groups instead of individual users. To use GBAC, configure your IdP to include group claims in the access token (for example, a `groups` claim). See your IdP's documentation for how to add group claims to tokens.
+
 include::manage:partial$security/oidc/limitations.adoc[leveloffset=+3]
 
 ===== OIDC credentials flow and access token validation

modules/manage/partials/gbac-assign-group-role.adoc

@@ -0,0 +1,23 @@
+To assign a group to a role in {ui}:
+
+. From *Security* on the left navigation menu, select the *Roles* tab.
+
+. Select the role you want to assign the group to.
+
+. Click *Edit*.
+
+. In the *Principals* section, enter the group name using the `Group:<name>` format. For example, `Group:engineering`.
+
+. Click *Update*.
+
+To remove a group from a role:
+
+. From *Security* on the left navigation menu, select the *Roles* tab.
+
+. Select the role that has the group assignment you want to remove.
+
+. Click *Edit*.
+
+. In the *Principals* section, remove the `Group:<name>` entry.
+
+. Click *Update*.

modules/manage/partials/gbac-create-group-acl.adoc

@@ -0,0 +1,13 @@
+In {ui}, group-based ACLs are managed through roles. To create an ACL for an OIDC group:
+
+. From *Security* on the left navigation menu, select the *Roles* tab.
+
+. Click *Create role* to open the role creation form, or select an existing role and click *Edit*.
+
+. In the *Principals* field, enter the group principal using the `Group:<name>` format. For example, `Group:engineering`.
+
+. Define the permissions (ACLs) you want to grant to users in the group. You can configure ACLs for clusters, topics, consumer groups, transactional IDs, Schema Registry subjects, and Schema Registry operations.
+
+. Click *Create* (or *Update* if editing an existing role).
+
+NOTE: {ui} assigns ACLs through roles. To grant permissions to a group, create a role for that group, add the group as a principal, and define the ACLs on the role. To create ACLs with a `Group:` principal directly (without creating a role), use `rpk`.