RFD 0229b: Scopes - Machine & Workload Identity#63437
RFD 0229b: Scopes - Machine & Workload Identity#63437strideynet wants to merge 56 commits intomasterfrom
Conversation
rfd/0229b-mwi-scopes.md
Outdated
| Assignments or via Scoped Access Lists. They cannot assign unscoped Roles to the | ||
| Scoped Bot. | ||
|
|
||
| TODO: Do the Scoped Roles assigned to the Scoped Bot need to be within the same |
There was a problem hiding this comment.
@fspmarshall I think this is my first "philosophical" question. I'm leaning towards permitting a Bot within scope /foo to be granted privileges in scope /bar by an admin of scope /bar but very curious on your thoughts and whether there's a solution that fits better with the philosophy of Scoped RBAC here.
There was a problem hiding this comment.
Discussion in slack (summarised):
- Yes: this is a tricky problem we need to think on longer.
- We may want to make this possible (there seems to be good use-cases), but, we need to protect against Bot privileges changing without the consent of the scope admin.
- This may require pinning the role assignment to the Bot Name and Scope OR introducing namespacing for ScopedBot resources.
We will meditate on this further.
| a descendent scope. | ||
| - RFD229-2: A Scoped Role Assignment's scope of effect must be the same or a | ||
| descendent of its scope of origin. | ||
| - RFD229B-1: The scope of origin and scope of effect of a Scoped Role Assignment |
There was a problem hiding this comment.
Is it strictly necessary to prevent the Scope of Origin being above the Bot Scope?
For example:
- Bot:
/foo/bar - SR:
/foo - SRA Origin:
/foo - SRA Effect:
/foo/bar
|
|
||
| When joining with a scoped token, the following new validation will be enforced: | ||
|
|
||
| - The Bot must have a scope set, and this scope must match the |
There was a problem hiding this comment.
This check may be overly strict.
Today, for a scoped token, the assigned_scope must be the same or descendent to scope. This means we could instead only validate that assigned_scope is equal to the scope of the Bot. This would permit an admin in a parent scope to create a join token for a bot in a descendent scope - which does not break any of the rules of Scoped RBAC.
I don't think there's a strong use-case for this - so it doesn't matter too much which way we go here. I'm tempted to start with the "stricter" check since it would be not-breaking to make this more relaxed in future - whereas vice versa would be a breaking change.
Curious on thoughts.
| scope of origin or a descendent scope. | ||
| - The pinning of the Bot's credentials to its scope of origin. | ||
|
|
||
| We propose that to relax these controls, the following new controls would likely |
There was a problem hiding this comment.
@fspmarshall - do any other controls come to mind for the cross-scope privilege ?
1 participant
Related to #63195