| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 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 | |
| 22:12:02 | admiyo | JayF, I think you misspelled Jaded | |
| 22:12:17 | admiyo | JayF, I have been an Ironic user in the past. I will take a look | |
| 22:12:42 | JayF | I don't think we'd likely change anything, but I'm curious how it comes across to someone who has old openstack experience back when Ironic was an admin-only api | |
| 22:12:45 | admiyo | But the short of it is that Ironic is almost all admin functions as defined by Nova. Which may or may not be how you view the world | |
| 22:12:51 | JayF | not anymore :) | |
| 22:13:00 | admiyo | Yeah, I am a big Bifrost fan | |
| 22:13:17 | JayF | You can 100% use a project manager as your nova service user today, as long as the nodes being managed are node.owner=that_project | |
| 22:13:18 | admiyo | https://adam.younglogic.com/2022/05/keystone-ldap-with-bifrost/ | |
| 22:13:55 | sean-k-mooney[m] | well not exactly its perfectly reasonable for ironic to be accessed with member or reader if a node has been assigned to a user/project | |
| 22:13:55 | JayF | admiyo: authenticating ironic, which has a component called ipa, using freeipa, is just devious :D | |
| 22:14:10 | admiyo | We had the name first | |
| 22:14:14 | admiyo | and I worked on both | |
| 22:14:14 | JayF | sean-k-mooney[m]: yeah, I think he's commenting on the old ironic world before we had a concept of non-admin | |
| 22:14:18 | JayF | admiyo: beer had the name first | |
| 22:14:37 | JayF | admiyo: Did I know you as another nickname? Or is my old man brain just being forgetful | |
| 22:14:42 | admiyo | https://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ | |
| 22:14:46 | admiyo | ayoung | |
| 22:14:52 | JayF | aha | |
| 22:15:41 | sean-k-mooney[m] | admiyo: for what its worth you have also been able to use ironci via nova with just member for a decade or more | |
| 22:16:31 | JayF | sean-k-mooney[m]: not a project-scoped member, but yes :) | |
| 22:16:58 | admiyo | sean-k-mooney[m], the problem was (and I suspect still is) that other projects are using admin the same way that keystone was. | |
| 22:17:10 | sean-k-mooney[m] | the real delta now is ironic nativly supprot assinging host to project/user adn partitioning the privlsaged info(ipmi creds) form the ablity to do things like power on/off a system | |
| 22:17:16 | JayF | sean-k-mooney[m]: I <3 that our model allows a central ironic to have multiple novas talking to it that all are just isolated by rbac project. How many people use this arch? Hell if I know. But it's a green flag that it's possible :D | |
| 22:17:21 | admiyo | i.e. you as the local admin, not a global one | |
| 22:17:39 | admiyo | JayF, that was something I dreamt of in the past | |
| 22:17:41 | JayF | sean-k-mooney[m]: yeah, that's default in devstack now too, it's really really nice to see all the redacted stuff :D | |
| 22:17:46 | admiyo | very cool. and how it should be | |
| 22:18:14 | JayF | admiyo: we basically support now, at provision time, we will assign the project that owns the instance on the node to "node.lessee", allowing that project minimal access (mainly reader) to that node | |