Conversation
✅ Deploy Preview for redpanda-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
nguyen-andrew
left a comment
nguyen-andrew
left a comment
There was a problem hiding this comment.
Looks good so far! Just some minor comments and questions
modules/manage/partials/gbac-dp.adoc
Outdated
| @@ -0,0 +1,336 @@ | |||
| // tag::single-source[] | |||
|
|
|||
| Group-based access control (GBAC) builds on xref:manage:security/authorization/rbac.adoc[role-based access control (RBAC)] to simplify permission management at scale. Instead of assigning roles or ACLs to individual users, you assign them to OIDC groups managed by your identity provider (IdP). Users inherit permissions from all groups reported in their OIDC token claims, so onboarding and offboarding require no changes in Redpanda. | |||
There was a problem hiding this comment.
Group-based access control (GBAC) builds on xref:manage:security/authorization/rbac.adoc[role-based access control (RBAC)]
I think we should make a similar adjustment as this other convo.
modules/manage/partials/gbac-dp.adoc
Outdated
| @@ -0,0 +1,336 @@ | |||
| // tag::single-source[] | |||
|
|
|||
| Group-based access control (GBAC) builds on xref:manage:security/authorization/rbac.adoc[role-based access control (RBAC)] to simplify permission management at scale. Instead of assigning roles or ACLs to individual users, you assign them to OIDC groups managed by your identity provider (IdP). Users inherit permissions from all groups reported in their OIDC token claims, so onboarding and offboarding require no changes in Redpanda. | |||
There was a problem hiding this comment.
I wonder if we should mention OIDC earlier in the paragraph (like in the first sentence) so readers immediately understand that GBAC depends on OIDC being configured. I think the OIDC dependency could be easy to miss upfront until the reader reads further down (like the Prerequisites section).
|
|
||
| Group as an ACL principal:: Create an ACL with a `Group:<name>` principal. Users in that group receive that permission directly. | ||
|
|
||
| Both patterns can be used together. When a user belongs to multiple groups, they inherit the combined permissions of all groups. |
There was a problem hiding this comment.
I think the deny-first behavior could be worth mentioning in this section. The authorizer checks deny rules before allow rules across all groups, and if any group matches a deny ACL for a resource, the user is denied (even if another group would've granted allow).
There was a problem hiding this comment.
Oh I see it's mentioned in the Limitations section, but I still think it'd be helpful to mention here as well.
modules/manage/partials/gbac-dp.adoc
Outdated
| --resource-pattern-type prefixed | ||
| ---- | ||
|
|
||
| If your groups use path-style names (with `nested_group_behavior: none`), use the full path as the principal name: |
There was a problem hiding this comment.
Is there a way to add a link to the Customize token claim extraction#nested_group_behavior section below or the nested_group_behavior section in the cluster properties reference? I think that could be helpful.
|
|
||
| . 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` or the Admin API instead. |
There was a problem hiding this comment.
To create ACLs with a
Group:principal directly (without creating a role), userpkor the Admin API instead.
The Admin API cannot be used to create ACLs.
modules/manage/partials/gbac-dp.adoc
Outdated
| Users with more than 200 group memberships in Azure AD receive a URL reference in their token instead of a list of group names. Redpanda does not follow that URL and cannot resolve groups in this case. Mitigation: filter token claims to include only the groups relevant to Redpanda. | ||
|
|
||
| Nested groups:: | ||
| Redpanda does not recursively resolve nested group hierarchies. If group A contains group B, only the direct memberships reported in the token are used. Use `nested_group_behavior: suffix` to extract the last path segment from hierarchical group names when needed. |
There was a problem hiding this comment.
Adding a link to Customize token claim extraction#nested_group_behavior or the nested_group_behavior section in the cluster properties reference could be helpful here too, if possible.
|
|
||
| xref:reference:properties/cluster-properties.adoc#oidc_group_claim_path[`oidc_group_claim_path`]:: A https://goessner.net/articles/JsonPath/[JSON path^] expression that tells Redpanda where to find group information in the OIDC token. For example, Auth0 and Okta typically use a top-level `groups` claim (`$.groups`), while Keycloak nests roles inside `realm_access` (`$.realm_access.roles`). Default: `$.groups`. | ||
|
|
||
| xref:reference:properties/cluster-properties.adoc#nested_group_behavior[`nested_group_behavior`]:: Controls how Redpanda handles group names that use path-style notation (for example, `/departments/eng/platform`). Set to `none` to use the full path as-is, or `suffix` to extract only the last segment. Default: `none`. |
There was a problem hiding this comment.
I think we should warn that suffix can cause unintended collisions when groups share a leaf name (e.g. /departments/eng/groupA and /departments/sales/groupA both collapse to groupA). In that case, ACLs or role assignments for Group:groupA would apply to members of both groups. Maybe we should make a note so users are aware of this behavior when designing their group naming conventions and ACLs.
|
|
||
| == About GBAC | ||
|
|
||
| Group-based access control (GBAC) is an enterprise feature that extends OIDC authentication to support group-based permissions. Instead of assigning roles or ACLs to individual users, you assign them to OIDC groups. Users inherit permissions from all the groups they belong to, as reported by their identity provider (IdP) through OIDC token claims. |
There was a problem hiding this comment.
Instead of assigning roles or ACLs to individual users, you assign them to OIDC groups.
More of a nit, but I wonder if "Instead of" could be read as implying GBAC replaces per-user ACLs and roles, when in practice both can be used together. Maybe something like "In addition to assigning roles or ACLs to individual users, you can also assign them to OIDC groups" would make it clear that the two approaches are complementary rather than mutually exclusive.
| == Group-based access control (GBAC) | ||
|
|
||
| == Iceberg topics with GCP BigLake | ||
| 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. Instead of 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. |
There was a problem hiding this comment.
Instead of assigning roles or ACLs to individual users, you can assign them to OIDC groups.
Same question as the other comment
treevon
left a comment
treevon
left a comment
There was a problem hiding this comment.
This looks good. The token extraction section is really nice with clear examples
| == Prerequisites | ||
|
|
||
| * xref:manage:security/authentication.adoc#oidc[OIDC authentication] must be configured and enabled on your cluster. | ||
| * Superuser access to configure cluster properties and manage ACLs. |
There was a problem hiding this comment.
nit - this is a prerequisite to enable OIDC, so should appear first
| Redpanda evaluates all authorization sources (user ACLs, role ACLs, group ACLs, and group-to-role ACLs) in a single unified flow. Deny rules are checked first across all sources. If any source produces a deny, the request is rejected regardless of allows from other sources. If no deny is found, Redpanda checks for an allow across all sources. If no allow is found, the request is denied by default. | ||
|
|
||
| .Authorization evaluation flow | ||
| [mermaid] |
There was a problem hiding this comment.
nit - could we get this larger by default and aligned horizontally to take up more of the page space?
|
|
||
| == Assign groups to roles | ||
|
|
||
| Assigning a group to an RBAC role is the recommended pattern for managing permissions at scale. All users in the group inherit the role's ACLs automatically. |
There was a problem hiding this comment.
We should have a link to RBAC configuration here
| --resource-pattern-type prefixed | ||
| ---- | ||
|
|
||
| If your groups use path-style names (with xref:reference:properties/cluster-properties.adoc#nested_group_behavior[`nested_group_behavior`] set to `none`), use the full path as the principal name: |
There was a problem hiding this comment.
I think we should move this to the section on claim extraction
3 participants
Description
Resolves DOC-1789
Review deadline: March 3rd
Page previews
Main doc - GBAC
Cluster Properties:
Authorization index
What's new
Checks