| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 21:27:03 | sean-k-mooney[m] | so member would not be able to but if you cant some one manager in a project they would be able to trigger a live migation | |
| 21:27:37 | sean-k-mooney[m] | we are also considring if we could allow them to select a host but thats tbd | |
| 21:28:08 | sean-k-mooney[m] | admiyo: ond of our custoemer does nto allow normal admins to live migrate by the way. they have a super admin role for that | |
| 21:28:39 | admiyo | OK. Remember, you also have implied roles, so admin can imply a lower level role and that gives them the ability to move forward. | |
| 21:28:45 | admiyo | so superadmin implies admin | |
| 21:28:49 | sean-k-mooney[m] | basically they had one team that did all the openstack admin and another team that did all the hardware/software mantahcne and patching | |
| 21:29:38 | sean-k-mooney[m] | they actully impmented it by making live migration require a dedicatd live_migration role and used a custom policy overried just for that | |
| 21:30:09 | admiyo | And by the way, according to Keystone, projects can still be nested, so if you assign an inheritable role on a parent or domain, you get it for the full hierarchy, but that means that administrators need to get a token specifically scoped to the project they want to affect | |
| 21:30:20 | admiyo | and I can see how that would be annoying in Horizon.... | |
| 21:31:27 | sean-k-mooney[m] | so i dont remember the details but with unifed limists there have been other changes to how nesting works | |
| 21:32:09 | admiyo | heh...yeah. Another lost battle. | |
| 21:32:25 | admiyo | Did you end up going with the two level approach? | |
| 21:32:38 | sean-k-mooney[m] | yes | |
| 21:32:44 | sean-k-mooney[m] | although its not on by default yet | |
| 21:32:49 | sean-k-mooney[m] | but we have supprot innova | |
| 21:33:00 | sean-k-mooney[m] | glance now only uses unifed limits | |
| 21:33:00 | admiyo | even if a quota is subdivided, you still need to check the overall quota of the project and all the parent projects. | |
| 21:33:15 | sean-k-mooney[m] | we are trying to swap to it by defaut in the next release or two | |
| 21:33:29 | admiyo | there is no real benefit or reason to limit it to two levels. | |
| 21:33:47 | sean-k-mooney[m] | so i dont think any of the service really supprot nested projects | |
| 21:34:30 | sean-k-mooney[m] | at least we dont have special logic to walk the tree | |
| 21:34:55 | admiyo | But for access control, especially admin functionality, you can make use of it. Remember, a domain IS a project. And even domain have a root, the defult project, so you can make roles that roll-on-down-the-hill\ | |
| 21:35:07 | sean-k-mooney[m] | so depending on how much of that is common in the keyston auth middleware ectra your milage will vary | |
| 21:35:51 | sean-k-mooney[m] | you can but you need to use a project scoped token becaue nova does not know about domains | |
| 21:36:02 | sean-k-mooney[m] | nor does neutron or glance ectra | |
| 21:36:16 | sean-k-mooney[m] | heat might | |
| 21:38:53 | admiyo | yeah, you can use a project sccoped token | |
| 21:39:03 | admiyo | but they don't know about nesting | |
| 21:39:10 | admiyo | so you need a token scoped to the project | |
| 21:39:28 | sean-k-mooney[m] | yep | |
| 21:39:38 | admiyo | but you automatically have access to that if you have the role assignment on the domain-as-aproject | |
| 21:39:43 | admiyo | and yes, domains were a mistake | |
| 21:40:10 | admiyo | OK, let me look at the keystone role assignemnt api. that is the real question | |
| 21:40:10 | sean-k-mooney[m] | well domains are kind for for the VPC/reseller usecse | |
| 21:40:23 | sean-k-mooney[m] | but that is not very common | |
| 21:40:51 | admiyo | NO, domains should have just been nested proejcts (tennants) on the proejct side, and IdPs on the user side | |
| 21:41:08 | admiyo | domains as groupings of projects was a mistake | |
| 21:41:22 | sean-k-mooney[m] | probably | |
| 21:41:40 | admiyo | but they predated Federated Identity. But IdP is the logical grouping for users, not domains | |
| 21:41:41 | sean-k-mooney[m] | im not really aware of domains being used by any of our custoemrs | |
| 21:41:55 | sean-k-mooney[m] | it would be a good question for the openstack user survay | |
| 21:41:56 | admiyo | this is all 20.20 hindsight | |
| 21:42:42 | admiyo | Although I do remember rendering insufficient resistenace to domains, thinking they should be projects. And I do rmeember being to person reminding people they were projects, not tennants. So I am very much to blame | |
| 21:44:12 | sean-k-mooney[m] | there is one feature that i have always wanted in keystone since your here. i wish there was a way to get a token form an sshkey like i want to just use the openstack client but assocating a public key with my user and using my private key to sign in | |
| 21:44:48 | sean-k-mooney[m] | the other feature is more a nova one but people have asked use to provide a token to vms liek k8s does | |
| 21:45:34 | sean-k-mooney[m] | i.e have a way via the metadata api to provide a project scoped token or proably applciation credital to the vm | |
| 21:45:57 | admiyo | And I think I just spotted how things are broken. I am working backwards here. But there is no specific check in the keystone role assignment API that does anything like say "you can only assign a role that you yourself have" which was one of the reasons for implied roles. And to do a role assignment for a project I need the role": | |
| 21:46:00 | admiyo | "identity:create_grant": "(rule:admin_required) or ((role:admin and domain_id:%(target.user.domain_id)s and domain_id:%(target.project.domain_id)s) or (role:admin and domain_id:%(target.user.domain_id)s and domain_id:%(target.domain.id)s) or (role:admin and domain_id:%(target.group.domain_id)s and domain_id:%(target.project.domain_id)s) or (role:admin and domain_id:%(target.group.domain_id)s and domain_id:%(target.domain.id) | |
| 21:46:00 | admiyo | s)) and (domain_id:%(target.role.domain_id)s or None:%(target.role.domain_id)s)" | |
| 21:46:05 | sean-k-mooney[m] | usually people ask for that in JWT format | |
| 21:46:05 | admiyo | Ugh...really. | |
| 21:46:27 | admiyo | OK, I think I see what they are doing there. | |
| 21:46:43 | admiyo | And I think it is broken by that first or | |
| 21:46:58 | sean-k-mooney[m] | there is some form of delegation check for applciation credentials | |
| 21:47:15 | admiyo | yeah, but it is skipped | |
| 21:47:49 | sean-k-mooney[m] | it might be enforced outside the policy layer | |
| 21:47:53 | admiyo | (rule:admin_required) means that anyone with an admin role can execute that policy | |
| 21:47:59 | admiyo | none of the others will be checked | |
| 21:48:06 | sean-k-mooney[m] | right | |
| 21:48:11 | admiyo | #"admin_required": "role:admin or is_admin:1 | |
| 21:48:22 | sean-k-mooney[m] | but thats in line with how admin works in all other proejcts | |
| 21:48:37 | sean-k-mooney[m] | * all other openstack services | |
| 21:49:00 | sean-k-mooney[m] | admiyo: i will note that keystones docs still document what you want | |
| 21:49:11 | sean-k-mooney[m] | but i dont think that has been true for a very very long time | |
| 21:49:32 | sean-k-mooney[m] | admiyo: https://docs.openstack.org/keystone/latest/admin/service-api-protection.html#admin | |
| 21:49:37 | admiyo | I just generated the policy file from the code | |
| 21:50:10 | sean-k-mooney[m] | that is not consistent with the standard definition of admin | |
| 21:50:22 | sean-k-mooney[m] | per the SRBAC comunity goal | |
| 21:50:56 | sean-k-mooney[m] | the keystone doc imples it is scoped but that has never been the case as far as i was aware | |
| 21:51:13 | sean-k-mooney[m] | so i think it documented the intent you had in 2015 | |
| 21:51:23 | admiyo | We are going to have to break the operators one way or another to fix this | |
| 21:51:26 | sean-k-mooney[m] | but not what was implemnted | |
| 21:51:34 | admiyo | EIther in their keystone workflows or in their Nova | |
| 21:52:04 | sean-k-mooney[m] | perhaps but i dont think any deployemnt cna be using the workflow you are descibing | |
| 21:52:06 | admiyo | I think it might be less painful to do it in Keystone, and it will at a minimum make those policy rules simpler | |
| 21:53:23 | admiyo | OK let me talk it through with the Keystone folks. I think I can see a way forward. Bascially, if the policy enforcement for Keystone uses a role other than admin for performing the operation when you want it limited to a project, everything else will be ok | |
| 21:53:24 | sean-k-mooney[m] | ya so it looks like the keytone doc was never updated after yoga | |
| 21:54:24 | sean-k-mooney[m] | admiyo: jsut remember the defintion of the personas and role means were effectivly moved out of keystone with the goverance resolution | |
| 21:56:01 | admiyo | Yeah, but they are effectively implemented there, which means if Keystone is wrong, everyone suffers | |
| 21:56:13 | admiyo | and I think that is what I am seeing. At least according to the policy generate | |
| 21:56:17 | admiyo | d on my system | |
| 21:57:35 | admiyo | ADMIN_OR_DOMAIN_ADMIN = ( | |
| 21:57:35 | admiyo | '(' + base.RULE_ADMIN_REQUIRED + ') or ' | |
| 21:57:35 | admiyo | '(' + GRANTS_DOMAIN_ADMIN + ') and ' | |
| 21:57:36 | admiyo | '(' + DOMAIN_MATCHES_ROLE + ')' | |
| 21:57:36 | admiyo | ) | |
| 21:57:51 | admiyo | yeah it is right there in the code. OK. | |
| 22:00:14 | sean-k-mooney[m] | admiyo: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#legacy-admin-continues-to-work-as-it-is is why i marked the bug as wont fix by the way | |
| 22:01:19 | sean-k-mooney[m] | we collectivly commited to not change admin going forward and instead add manager for more scoped privaldged access | |
| 22:01:47 | sean-k-mooney[m] | which is pahse 3 which is where we are now | |
| 22:02:19 | sean-k-mooney[m] | phase 2 and 3 are basiclaly happening in parallel | |
| 22:03:18 | sean-k-mooney[m] | we already use the servie role in some cases but have not removed admin so they were admin_required and not they are admin_or_serivce for upgrade reasons | |
| 22:04:38 | admiyo | sean-k-mooney[m], ok, so the only point you and I now disagree on is the status of the bug. You should make it "in progress" and not "wish list" because you have made changes to fix it. And if you do that, and fix it, I will grant a copy of the t shirt I had made up to both you and to whomever did the lionshare of the work for fixing it. | |
| 22:06:40 | sean-k-mooney[m] | so the reason i set it as wont fix is we wont ever limit the scope of admin to a project or domain | |
| 22:07:00 | sean-k-mooney[m] | so we wont fix the bug in the way it was stated in the deciption | |
| 22:07:37 | sean-k-mooney[m] | we are fixing it by intoducing a new role for “scoped” admin | |
| 22:10:25 | admiyo | OK. No T-shirt for you. But I can see your argument. | |
| 22:11:03 | JayF | admiyo: you'd be surprised at the number of people who read the title/first lines of an issue, see "fix released" and assumed they got exactly what they wanted rather than whatever compromise item got fixed instead :) | |
| 22:11:17 | admiyo | I suspect, however, that things are broken in other services. Admin needs to go away everywhere, and have special enforcement in Keystone | |
| 22:11:56 | JayF | admiyo: are you an ironic user? Would be interested to see what you think about how we took on rbac | |