| Luzi | Hey could someone take a look at https://review.opendev.org/c/openstack/keystone/+/900028 ? | 07:48 |
|---|---|---|
| Luzi | dmendiza[m], are you around? | 12:46 |
| dmendiza[m] | Luzi: 👋 | 14:12 |
| Luzi | hi | 14:12 |
| Luzi | i am currently trying to understand the impact of the scopes and the current state of the RBAC implementation | 14:13 |
| dmendiza[m] | Yeah, it's somewhat confusing, but I can try to help. 😅 | 14:14 |
| Luzi | i am thinking about the restrictions a domain-manager (role or persona) should have and how this can be achieved | 14:15 |
| Luzi | so far i did understand, that system scope is postponed or even not up for enforcing at all, due to the problems with breaking workflows: | 14:16 |
| Luzi | admins managing user resources in cases of operational need (e.g. evacuating a compute host) | 14:16 |
| dmendiza[m] | Right, so, per the latest Secure RBAC spec https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html we sort-of backpedaled on system-admin, not necessarily system scope | 14:17 |
| Luzi | so for example a domain manager should be able to list only his domain, a admin schould be able to list all domains and a user from a project? | 14:18 |
| Luzi | because in that policy the project scope is added | 14:18 |
| Luzi | https://github.com/openstack/keystone/blob/master/keystone/common/policies/domain.py#L74 | 14:18 |
| dmendiza[m] | Right, so, for that specific rule (identity:list_domains) the allowed personas would be: Any admin regardless of scope (system-admin, domain-admin, project-admin) as well as any system-scoped persona (system-admin, system-manager, system-member, system-reader). | 14:21 |
| dmendiza[m] | actually, no sorry, that's wrong | 14:21 |
| dmendiza[m] | scratch that | 14:22 |
| dmendiza[m] | so it would be any admin in the allowed scope types | 14:22 |
| dmendiza[m] | so, system-admin and project-admin are allowed, but no domain-admin | 14:22 |
| dmendiza[m] | because scope_types does not allow domain-scoped tokens | 14:22 |
| dmendiza[m] | all system personas are allowed though | 14:23 |
| dmendiza[m] | because of implied roles. | 14:23 |
| Luzi | okay? but a domain manager persona would in that case need a domain scope, right? | 14:23 |
| dmendiza[m] | right, so all we need to do for that policy would be to add `scope_types=['system', 'domain', 'project'] | 14:23 |
| dmendiza[m] | that would allow domain-admin | 14:24 |
| dmendiza[m] | say we wanted to extend that to domain-manager | 14:24 |
| dmendiza[m] | then the policy would have to change to: | 14:24 |
| dmendiza[m] | base.RULE_ADMIN_REQUIRED + ' or (role:reader and system_scope:all) or (role:manager and domain_id:%(target.domain_id)s)' | 14:26 |
| dmendiza[m] | And we'd need to make sure the target object has the domain_id property assigned for that API | 14:26 |
| dmendiza[m] | which I've realized in the last couple of weeks is kind of a mess | 14:26 |
| dmendiza[m] | because we are very inconsistent in how domain scope is checked | 14:27 |
| dmendiza[m] | but I have a few ideas on how to fix it | 14:27 |
| Luzi | okay, so before a possible domain manager role can be applied, the domain scope has to be thoroughly defined | 14:27 |
| Luzi | or persona | 14:28 |
| Luzi | i still miss the part of where is the scope given? so right now what would an admins request look like, for creating a project in constrast to migrating ressources for users of said project. Do those scopes differ somewhere? | 14:29 |
| dmendiza[m] | Yeah, so, we can technically already make domain-managers with the existing default roles. We just have to assign "manager" to a user on a specific domain. The only part missing is adding the scope_type=[ ... , "domain" , ... ] to the relevant policy definitions and (role:manager and domain_id:%(target.domain_id)s) to the actual policy. | 14:30 |
| Luzi | oh okay | 14:31 |
| dmendiza[m] | the scope comes into play in two parts of the workflow | 14:31 |
| Luzi | and being in that scope would prevent the domain manager from managing ressources in the projects of the domain, because those are project-scoped, right? | 14:32 |
| dmendiza[m] | It depends on the policy for the individual APIs | 14:32 |
| Luzi | okay, so this is very individual... | 14:32 |
| Luzi | thank you dmendiza[m] | 14:33 |
| dmendiza[m] | but, in general, I think most projects are only accepting project-scoped tokens | 14:33 |
| Luzi | I will think about this and maybe update the spec in keystone :) | 14:33 |
| dmendiza[m] | so, yeah, to be clear, the scope is defined at role-assignment | 14:33 |
| dmendiza[m] | so to make a domain-manager you'd send a request to: | 14:33 |
| dmendiza[m] | PUT /v3/domains/$SPECIFIC_DOMAIN_ID/users/$USER_ID/roles/$MANAGER_ROLE_ID | 14:34 |
| dmendiza[m] | after that, the user is allowed to request tokens with domain scope that will have the manager role | 14:34 |
| dmendiza[m] | the user has to say they want a domain-scoped token when they submit their credentials | 14:35 |
| dmendiza[m] | and that token is not allowed by policies that only have system_scope=['project'] in their definition | 14:35 |
| Luzi | yeah, okay i have to think about all of this, thank you dmendiza[m] | 14:39 |
| opendevreview | Douglas Mendizábal proposed openstack/keystone master: Normalize policy checks for domain-scoped tokens https://review.opendev.org/c/openstack/keystone/+/908524 | 17:34 |
| opendevreview | Douglas Mendizábal proposed openstack/keystone-tempest-plugin master: Consistent and Secure RBAC (Phase 1) https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/903713 | 20:38 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!