| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 21:23:02 | sean-k-mooney[m] | well redhat also offcialy does not supprot custom policy | |
| 21:23:25 | admiyo | Well admiyo officially does not support Red Hat, and now you know why | |
| 21:23:35 | sean-k-mooney[m] | mainly because custoemr have litrally currpted nova’s db before by messing up neutrons policy file | |
| 21:23:40 | sean-k-mooney[m] | such that all instance lost all ports | |
| 21:23:56 | JayF | sean-k-mooney[m]: I'm waiting for the first bug report w/ironic enabling RBAC defaults, along those lines | |
| 21:24:09 | admiyo | Yeah, as I recall there were some interesting policy enforcement in Neutron.... | |
| 21:24:44 | sean-k-mooney[m] | it was actully a tirdparty vendor who i wont name who provide a core plugin with custom policy | |
| 21:25:35 | admiyo | So migrations should never be done by an end user....I think I get that. They don't know about physical hosts....but that does seem like a draconian setup. Seems like there could be cases where you want to let users trigger their own migrations. But I get it. | |
| 21:26:14 | sean-k-mooney[m] | we dont today because its a potinal ddos vector | |
| 21:26:27 | sean-k-mooney[m] | but in the future we do plan to allow that via the manager role | |
| 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 | |