- Notifications
You must be signed in to change notification settings - Fork1.1k
refactor: clean up policy.rego#20366
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
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Emyrk left a comment
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.
👍
| - 1 to allow | ||
| If a level abstains, then the decision gets deferred to the next level. When | ||
| there is no "next" level to defer to it is equivalent to being denied. |
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.
| there is no "next" level to defer to it is equivalent to being denied. | |
| there is no "next" level to defer to, it is equivalent to being denied. |
| there is no "next" level to defer to it is equivalent to being denied. | ||
| ###Scope | ||
| Additionally, each input has a "scope" that can be thought of as a second set of permissions, where each permission belongs to one of the four levels–exactly the same as role permissions. An action is only allowed if it is allowed by both the subject's permissions_and_ their current scope. This is to allow issuing tokens for a subject that have a subset of the full subjects permissions. |
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.
Should this be a comma?
| Additionally, each input has a "scope" that can be thought of as a second set of permissions, where each permission belongs to one of the four levels–exactly the same as role permissions. An action is only allowed if it is allowed by both the subject's permissions_and_ their current scope. This is to allow issuing tokens for a subject that have a subset of the full subjects permissions. | |
| Additionally, each input has a "scope" that can be thought of as a second set of permissions, where each permission belongs to one of the four levels,exactly the same as role permissions. An action is only allowed if it is allowed by both the subject's permissions_and_ their current scope. This is to allow issuing tokens for a subject that have a subset of the full subjects permissions. |
d9c40d6 intomainUh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
I found some of the naming and organization of this file to be really confusing/overwhelming at first. I'm hoping that by rearranging a couple of things, renaming some variables, and rewriting some comments that I can make it less intimidating for the next person who needs to dive in to this policy. 😄
This is all a bunch of stuff I wanted to do while adding the org member level, but I felt like it cluttered the diff too much, making it unclear what was just being shuffled around vs what was actually meaningfully changing. Once this is merged, the org member code should slot in very nicely, with a much smaller diff.
This whole PR should essentially be a no-op! Anything that looks like it's changing behavior is unintentional. This change is meant to be purely for the benefit of future readers.