OSAC-953: Update AuthConfig to use organization groups#666
Conversation
|
@CrystalChun: This pull request references OSAC-953 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the sub-task to target the "5.0.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThis PR updates OPA authorization policy to derive tenant identity exclusively from JWT ChangesgRPC Authorization Policy: Organization-Based Tenant & Project Rules
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Caution Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional.
❌ Failed checks (1 error)
✅ Passed checks (10 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@charts/service/templates/grpc-server/authconfig.yaml`:
- Around line 282-295: The current authorization rule inside the allow if block
applies the same group check to Get/Update/Delete and therefore denies read-only
viewers; modify the policy by splitting the rule into two checks: one allow
branch that permits grpc_method == "/osac.public.v1.Projects/Get" when
input.auth.identity.authnMethod == "jwt" and some group in
subject_org_groups[tenant].groups where group == sprintf("/%s/viewers", [name])
or group == sprintf("/%s/managers", [name]); and a second allow branch that
permits grpc_method in
{"/osac.public.v1.Projects/Update","/osac.public.v1.Projects/Delete"} only when
the same jwt check and some group in subject_org_groups[tenant].groups where
group == sprintf("/%s/managers", [name]); retain use of tenant :=
input.context.context_extensions.tenant and name :=
input.context.context_extensions.name in both branches.
- Around line 104-108: The current rule assigns subject_tenants = subject_groups
when input.auth.identity.authnMethod == "jwt" and organization is missing, which
incorrectly treats project group paths as tenants; update the logic so that when
authnMethod is "jwt" and input.auth.identity.organization is absent,
subject_tenants remains empty (do not assign subject_groups). Concretely, remove
or guard the branch that sets subject_tenants from subject_groups for JWTs
without organization, relying solely on input.auth.identity.organization as the
authoritative tenant source and leaving subject_tenants unset in that case.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 99d70ea3-613b-4bd1-95d3-1a70fbb81c66
📒 Files selected for processing (1)
charts/service/templates/grpc-server/authconfig.yaml
CrystalChun
force-pushed
the
groups-authz
branch
2 times, most recently
from
5b0c673 to
41f59c9
Compare
jhernand
left a comment
jhernand
left a comment
There was a problem hiding this comment.
You need to update the authconfig.yaml file in the manifests directory as well.
CrystalChun
force-pushed
the
groups-authz
branch
from
41f59c9 to
61f8677
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: CrystalChun The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
CrystalChun
force-pushed
the
groups-authz
branch
from
61f8677 to
0b765cb
Compare
Thank you! Updated that one as well |
CrystalChun
force-pushed
the
groups-authz
branch
2 times, most recently
from
3b6cd8b to
930964d
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@charts/service/templates/grpc-server/authconfig.yaml`:
- Around line 271-301: Add an allow rule for the Projects/List gRPC method:
create a new allow-if block checking grpc_method ==
"/osac.public.v1.Projects/List", extract tenant :=
input.context.context_extensions.tenant, require input.auth.identity.authnMethod
== "jwt", and verify some group in subject_org_groups[tenant].groups (or narrow
to viewers/managers if you prefer filtering at the app layer); this mirrors the
Get/Update rules and ensures JWT-authenticated tenant members can call
Projects/List while the server can perform any result-level filtering.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 3f312678-7c68-4944-b608-71f503969b9d
📒 Files selected for processing (2)
charts/service/templates/grpc-server/authconfig.yamlmanifests/base/grpc-server/authconfig.yaml
CrystalChun
force-pushed
the
groups-authz
branch
5 times, most recently
from
ad5b834 to
14bff45
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@it/charts/keycloak/files/realm.json`:
- Around line 836-846: The realm config sets protocolMapper
"oidc-organization-group-membership-mapper" (id "org-group-membership-001") but
the chart defaults images.keycloak to 26.3 and realm.json declares
keycloakVersion 26.3.5, which is <26.6.0 where that mapper is guaranteed; update
the deployment to a compatible Keycloak version (bump values.images.keycloak
default and chart/appVersion to >=26.6.0 and align realm.json keycloakVersion)
or alternatively gate/remove the protocolMapper
"oidc-organization-group-membership-mapper" (org-group-membership-001) for older
versions and provide a fallback mapper implementation so org-scoped JWT
membership continues to be emitted.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 3a58f4ce-ff1b-4fd9-a490-e39d1ef78a29
📒 Files selected for processing (3)
charts/service/templates/grpc-server/authconfig.yamlit/charts/keycloak/files/realm.jsonmanifests/base/grpc-server/authconfig.yaml
CrystalChun
force-pushed
the
groups-authz
branch
8 times, most recently
from
d747d86 to
bd603a9
Compare
CrystalChun
force-pushed
the
groups-authz
branch
8 times, most recently
from
4db781b to
a8791a2
Compare
There was a problem hiding this comment.
♻️ Duplicate comments (1)
charts/service/templates/grpc-server/authconfig.yaml (1)
94-95:⚠️ Potential issue | 🟠 Major | ⚡ Quick winMajor authorization risk: JWT fallback still classifies raw groups as tenants.
Line 94 says JWT callers without
organizationshould have an empty tenant list, but Line 111 overrides that by assigningsubject_tenants = subject_groups. Impact: project ACL-style groups (for example/<project>/managers) can be propagated as tenant identifiers (including inx-subject.tenants), weakening tenant-boundary guarantees in downstream authorization/filtering.🔧 Suggested fix
- # Fallback to groups for JWT users without organization claim (backwards compatibility) - subject_tenants = subject_groups if { - input.auth.identity.authnMethod == "jwt" - not input.auth.identity.organization - }Based on learnings: in this repo’s grpc-server Helm auth config, JWT tenant resolution should use the singular
auth.identity.organizationclaim as authoritative and must not fall back to JWTgroups.Also applies to: 110-114
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/service/templates/grpc-server/authconfig.yaml` around lines 94 - 95, The template currently falls back to using JWT groups as tenants (assigning subject_tenants = subject_groups), which allows project ACL groups to be treated as tenant identifiers; change the tenant-resolution logic so subject_tenants is populated only from the singular claim auth.identity.organization (e.g. set subject_tenants to that claim when present, otherwise to an empty list) and remove the unconditional fallback to subject_groups; if service accounts must use groups as tenants, make that conditional (only set subject_tenants = subject_groups when a service-account claim like auth.identity.type == "service_account" or a dedicated service_account boolean is present), and ensure x-subject.tenants is emitted only from subject_tenants.Source: Learnings
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In `@charts/service/templates/grpc-server/authconfig.yaml`:
- Around line 94-95: The template currently falls back to using JWT groups as
tenants (assigning subject_tenants = subject_groups), which allows project ACL
groups to be treated as tenant identifiers; change the tenant-resolution logic
so subject_tenants is populated only from the singular claim
auth.identity.organization (e.g. set subject_tenants to that claim when present,
otherwise to an empty list) and remove the unconditional fallback to
subject_groups; if service accounts must use groups as tenants, make that
conditional (only set subject_tenants = subject_groups when a service-account
claim like auth.identity.type == "service_account" or a dedicated
service_account boolean is present), and ensure x-subject.tenants is emitted
only from subject_tenants.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: cc871161-2ed4-457c-bf2e-2ac474efcd55
📒 Files selected for processing (4)
charts/service/templates/grpc-server/authconfig.yamlit/charts/keycloak/files/realm.jsonit/it_organization_lifecycle_test.gomanifests/base/grpc-server/authconfig.yaml
💤 Files with no reviewable changes (3)
- it/it_organization_lifecycle_test.go
- manifests/base/grpc-server/authconfig.yaml
- it/charts/keycloak/files/realm.json
Determine if a user can get/update/delete a project based on the organization group they're part of. Assisted-by: Claude Code <noreply@anthropic.com>
CrystalChun
force-pushed
the
groups-authz
branch
from
a8791a2 to
7dd0887
Compare
|
@CrystalChun: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
3 participants
Description
Determine if a user can get/update/delete a project based on the organization group they're part of.
Testing
Assisted-by: Claude Code noreply@anthropic.com
/cc @jhernand
Summary by CodeRabbit
Release Notes
New Features
Improvements