Permission level degradation proposal #66
Conversation
kubermatic-bot
added
release-note-none
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: thetechnick The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
kubermatic-bot
added
approved
| - my-corp.com | ||
| resources: | ||
| - mycoolapps | ||
| verbs: # limited verbs, due to a max permission issue |
There was a problem hiding this comment.
This means, if user tries to create ProjectRole which escalates the user's permission or max permission, we will still let the ProjectRole be created but with limited permissions? Why don't we forbidden to create this ProjectRole?
There was a problem hiding this comment.
I should probably point this out more prominently in the design document:
OrganizationRolesare validated on creation and update to enforce the same prerequisites as Kubernetes:
https://kubernetes.io/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update
Same for ProjectRoles. *RoleBindings are also validated the similar, but the link points to the *Binding specific validation rules.
Those checks include escalation checks, just follow the link.
There was a problem hiding this comment.
I am sorry that I still don't get it :)
For example, if User only has permission to do X but not Y, and User creates a Role with X and Y, Kubernetes API server will reject the API call with a forbidden error.
In our case, if User create a ProjectRole with X and Y, we will let it be created, but we only give people permission X (In the status, only X will be granted).
My question was why don't we also reject the call with a forbidden error when user creates ProjectRole? Why we let it be created instead?
Thanks!
There was a problem hiding this comment.
Oh, now I see it. In your example, it is the case that the max permission is limited after the ProjectRole is created, in this case, we have the acceptedRules in the status to show User, that your permission is also limited.
| @@ -0,0 +1,188 @@ | |||
| # Bulward Permission Level Degradation | |||
|
|
|||
| This document extends on the initial Bulward concept to enable degradation of user defined roles. | |||
There was a problem hiding this comment.
| This document extends on the initial Bulward concept to enable degradation of user defined roles. | |
| This document extends on the initial Bulward concept to enable user defined roles scope reduction. |
not sure if the degradation is the right word in this context.
|
|
||
| ## Background | ||
|
|
||
| After installing bulward organization owners will have very limited permissions. Essentially they will only be allowed to interact with the Bulward API -> e.g. creating new Projects, organize users and create sub-roles. |
There was a problem hiding this comment.
| After installing bulward organization owners will have very limited permissions. Essentially they will only be allowed to interact with the Bulward API -> e.g. creating new Projects, organize users and create sub-roles. | |
| After installing bulward organization owners have limited permissions. Essentially they are allowed to interact with the Bulward API -> e.g. creating new Projects, organize users, and create sub-roles. |
| conditions: [] | ||
| ``` | ||
|
|
||
| ## Changes from initial concept |
There was a problem hiding this comment.
update the concept in the PR as well, to have it up to date.
|
|
||
| ### Max Permission Level (Organization/Project) | ||
|
|
||
| Organizations and Projects have both a maximum permission level that cannot be exceeded within. |
There was a problem hiding this comment.
How is this maximum permission configured? In the Organization / Project resource or?
| ### Max Permission Level (Organization/Project) | ||
|
|
||
| Organizations and Projects have both a maximum permission level that cannot be exceeded within. | ||
| This maximum permission level results from all roles that are assigned to the organization unit and thus to the Organization/Project Owner. |
There was a problem hiding this comment.
This is tad underspecified. All roles --> do we mean OrganizationRoleTemplate roles or?
|
|
||
| Organization/Project Owners may create sub-roles that don't exceed this maximum permission level. | ||
|
|
||
| If roles are removed from the organization the maximum permission level drops and sub-roles need to be limited in order not to exceed this permission level. |
There was a problem hiding this comment.
Same, roles is referring to which resource exactly?
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #
Special notes for your reviewer:
Documentation:
Does this PR introduce a user-facing change?: