- Notifications
You must be signed in to change notification settings - Fork1k
fix: improve RBAC scope allow list handling for create actions#20008
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:thomask33/09-28-add_api_key_audit_metadata
Are you sure you want to change the base?
Conversation
ThomasK33 commentedSep 29, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stackon Graphite.
This stack of pull requests is managed byGraphite. Learn more aboutstacking. |
5ac8d9c tobd1ff54Comparef53f9aa to7a79289Compare7a79289 tof38d137Comparebd1ff54 toeedeed8Compare8390b78 tocb4f67cCompareb3d04ca toafb4b9dComparecb4f67c tobc0acfcCompareafb4b9d to1060d38Comparec410a2c to696cc1dCompare1060d38 to403b866Compare
How is this inconsistent with how other permissions work? The permission to create a workspace is This change allows an object with no uuid to always pass the allow list, but that is not correct imo. That would mean if you grant I don't think we should special case the action |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Just preventing an accidental merge
403b866 to5e40a34Compare09d60e6 to4bb9040Compare4280771 to384a406Comparecc44d1c to4c9762eCompare154d4a1 tocafac8dComparec9ad043 to610e5e7Comparecafac8d to393492aCompare610e5e7 to14537dbCompare393492a to2c9a4c1Compare14537db tofd7df7cCompare2c9a4c1 to7915a16CompareThe allow_list for RBAC scopes has been updated to use typed elementsof the form `{type: string, id: string}` instead of raw string IDs.This change enables more granular authorization policies. Specifically, itmodifies the behavior for "create" actions. A create operation is nowpermitted if the scope's allow_list contains an entry matching theresource type, even without a specific ID. This is useful for scenarioslike workspace agent tokens which need to create resources but cannotknow the ID ahead of time.For all other actions (e.g., read, update, delete), the allow_listmust still contain an entry that matches both the type and the specificID of the resource.The Rego policy, relevant Go code, and tests have been updated toimplement and verify this new typed allow_list behavior.7915a16 toe153689Comparefd7df7c to80f543aCompare
Fix API key scope authorization for workspace creation
This PR fixes an issue with API key scopes and workspace creation. Previously, the RBAC policy allowed creation of resources with an empty ID in the allow list, but this approach was inconsistent with how other permissions work.
The changes:
These changes ensure that API key scopes are properly enforced for creation operations while maintaining backward compatibility.