Skip to content

CONCEPT Cited by 1 source

Group-based access control (GBAC)

Definition

Group-Based Access Control (GBAC) is an authorization model where permissions are granted to groups (not individual users) and group membership is provided by a centralized Identity Provider (IdP) rather than managed per-system. When the IdP changes group membership (e.g. a user joins / leaves a team via Okta, Azure AD, or Google Workspace), the change automatically propagates to every downstream system that consumes IdP group claims — without any per-system ACL edits.

GBAC is the natural evolution of RBAC (Role-Based Access Control) for organisations that already run a corporate IdP: instead of each system maintaining its own user → role mapping, the IdP becomes the single source of truth for group membership, and each system maps groups → permissions.

Canonical Redpanda framing

From the sources/2026-03-31-redpanda-261-delivers-the-industrys-first-adaptable-streaming-engine|26.1 launch post:

"With 26.1, we're introducing Group-Based Access Control (GBAC). Instead of micromanaging permissions for every single 'Bob' and 'Alice' in your organization in each cluster, you can now map roles or permissions to groups provided centrally by an Identity Provider (IdP). Access control that automatically absorbs your organization's changes delivers a 'set it and forget it' model for authorization that finally brings sanity to enterprise-scale streaming security."

Motivating problem

Kafka / Redpanda ACLs are expressed per-principal:

ALLOW User:alice → READ Topic:orders
ALLOW User:bob   → WRITE Topic:shipments
...

For N users × M topics × K clusters, the ACL count grows multiplicatively. When Alice changes teams, an operator must walk every cluster and edit her per-principal ACLs. The post frames this as "managing individual ACLs for more than a dozen different users across multiple clusters... doesn't scale, it's error-prone, and it's a security nightmare."

GBAC structural shape

┌──────────────┐                  ┌──────────────┐
│ Identity     │ group claims in  │ Streaming    │
│ Provider     │───── token ─────▶│ cluster      │
│ (Okta / AzureAD)                │              │
└──────────────┘                  │  group →     │
                                  │  permission  │
                                  │  mapping     │
                                  └──────────────┘

Operator edits:

  • On the IdP: "Alice is now in the payments-team group."
  • On the streaming cluster: ALLOW Group:payments-team → READ Topic:orders (one-time).

When Alice leaves payments-team, the IdP claim changes on her next token refresh; her access evaporates without touching cluster ACLs.

Distinguishing from RBAC

Axis RBAC GBAC
Membership source Per-system user-to-role tables External IdP group claims
Propagation latency Manual edit per system Next token refresh
Scaling with user count O(users × systems) edits O(groups × systems) — users join/leave on IdP alone
Audit surface N system-local audit logs IdP as single audit source
Offboarding posture Walk every system Revoke IdP group membership once

GBAC is a specialisation of RBAC: "role" is replaced by "group claim in IdP-issued token." The mechanism is otherwise the same.

Why IdP integration matters at enterprise scale

Enterprise IT already runs an IdP as the authentication hub for SSO, passkey / FIDO2, and phishing-resistant MFA. Every system that re-implements user management creates:

  • A second identity store that drifts from the IdP (terminated employees retain access if IT forgets to sweep).
  • A second audit log that doesn't correlate with the IdP's access log.
  • A per-system offboarding step that scales with system count.

GBAC collapses this by making the cluster a consumer of the IdP's group claims rather than a parallel identity store. "Access control that automatically absorbs your organization's changes" is the canonical framing.

Status (Redpanda 26.1)

First-class authorization model in Redpanda 26.1, documented at docs.redpanda.com/current/manage/security/authorization/gbac/. IdP protocol details (SAML? OIDC? SCIM?), token format, group- claim mapping conventions, and policy evaluation engine mechanics are not disclosed in the launch post — the wiki coverage is limited to the user-facing model.

Mechanism gaps (from the source)

The 26.1 launch post is high-altitude PR framing rather than a spec. Undisclosed:

  • Protocol — OIDC ID tokens? SAML assertions? SCIM sync?
  • Group-claim shape — flat list of strings? Hierarchical paths? Custom claim key?
  • Cluster-side policy store — is group → permission mapping stored in the controller Raft log? In a separate IdP config file? How is it reconciled on cluster restart?
  • Nested group support — does engineering → payments-team transitively grant engineering permissions?
  • Fallback for IdP outages — does group → permission mapping have a cached snapshot? Fail-open / fail-closed?

Seen in

Source

Last updated · 550 distilled / 1,221 read