Role permissions checks #170
Merged
Conversation
This file contains 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
Some functions, like currentSubject and checkAction, have logic that is either duplicated or could be reused elsewhere for things like checking access to actions in permissions-api itself. This commit moves some of that logic around so it is easier for other handlers (such as the handlers for roles) to use. Signed-off-by: John Schaeffer <[email protected]>
This commit adds permissions checks for role creation, as well as the action and bindings to the example policy. Signed-off-by: John Schaeffer <[email protected]>
This commit adds a command to create roles directly in SpiceDB, bypassing permissions checks. The intent of this command is to bootstrap a new permissions-api deployment with enough access to start provisioning roles using some subject. Signed-off-by: John Schaeffer <[email protected]>
This commit adds permissions checks for getting, listing, updating, and deleting roles. Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
mikemrm
previously approved these changes
Sep 6, 2023
|
One issue with this as written right now is that with the example policy, no relationships exist that convey that a role belongs to a resource. That actually seems necessary here, looking closer at the logic. |
One of the quirks of our current role model is that roles don't belong to a resource outright - instead, their binding to a resource is inferred by the actions that can be performed. This means that we can't use the role itself to make authorization decisions. This commit updates permissions checks for roles to use the role's resource rather than the role itself for checking permissions. Signed-off-by: John Schaeffer <[email protected]>
|
Updated with a change that doesn't break everything. |
fishnix
approved these changes
Sep 6, 2023
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.
This PR adds permissions checks for role management CRUD operations in the permissions-api API.
Because permissions checks are baked into the API (i.e., they cannot and should not be disabled), this PR also adds a command,
create-role, which can be used to bootstrap the creation of roles that can allow a subject to create other roles. The conditions for actions likerole_createare deliberately left out of permissions-api to allow operators to define their own policies.