-
Notifications
You must be signed in to change notification settings - Fork 156
enhancement: Role policies parent roles field #2349
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 our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Sambigeara
merged 11 commits into
cerbos:main
from
Sambigeara:enhancement/role-policy-parent-roles
Oct 30, 2024
Merged
enhancement: Role policies parent roles field #2349
Sambigeara
merged 11 commits into
cerbos:main
from
Sambigeara:enhancement/role-policy-parent-roles
Oct 30, 2024
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
7939d2f
to
bf39df9
Compare
Introduce a discrete set of parent roles which a role policy: * implicitly assumes * narrows the permissions of If a principal has a custom role, and the role policy definition for that role has one or more parent roles, the principal implicitly assumes those custom roles. It also allows role policies to narrow the permissions of more than one IdP role (rather than just the named role, as was previously the case). Signed-off-by: Sam Lock <sam@swlock.co.uk>
…n time Signed-off-by: Sam Lock <sam@swlock.co.uk>
Signed-off-by: Sam Lock <sam@swlock.co.uk>
Signed-off-by: Sam Lock <sam@swlock.co.uk>
bf39df9
to
6184237
Compare
Signed-off-by: Sam Lock <sam@swlock.co.uk>
Signed-off-by: Sam Lock <sam@swlock.co.uk>
…source policies. more test cases Signed-off-by: Sam Lock <sam@swlock.co.uk>
…olicy evaluation (fixes flaky tests) Signed-off-by: Sam Lock <sam@swlock.co.uk>
charithe
reviewed
Oct 30, 2024
Signed-off-by: Sam Lock <sam@swlock.co.uk>
Signed-off-by: Sam Lock <sam@swlock.co.uk>
charithe
approved these changes
Oct 30, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduce a set of parent roles which a role policy assumes.
scopePermissions
settings are honoured. "Override parent" inherits the permissions of parent roles and has the authority to returnALLOW
early if aresource:action
pair exists in any of the policies. "Required parental consent for allows" narrows the scope for the full set of (recursive) parent roles.NO_MATCH
(rather thanDENY
) forresource:action
pairs that don't exist. This covers the case where we need to inherit a base (non role policy) role, and evaluate it in the resource policies in the case where aresource:action
pair isn't defined in the role policy. It also brings the behaviour in line with resource policy types.There is scope for some caching improvements to the recursive lookup, but I don't think this is super straight forward as cache invalidation requires context from a separate area of concern within the PDP (we'd need to be aware of index updates from within the engine). This is doable, but we don't know if it's necessary yet, and we're going to revamp the index at some point anyway so that might come first.