| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 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 | '(' + GRANTS_DOMAIN_ADMIN + ') and ' | |
| 21:57:35 | admiyo | '(' + base.RULE_ADMIN_REQUIRED + ') or ' | |
| 21:57:35 | admiyo | ADMIN_OR_DOMAIN_ADMIN = ( | |
| 21:57:36 | admiyo | ) | |
| 21:57:36 | admiyo | '(' + DOMAIN_MATCHES_ROLE + ')' | |
| 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 | JayF | admiyo: authenticating ironic, which has a component called ipa, using freeipa, is just devious :D | |
| 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:14:10 | admiyo | We had the name first | |
| 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:14 | admiyo | and I worked on both | |
| 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 | |
| 22:18:51 | admiyo | "dear google, I want the actual git repo, not github, for openstack. Please at least return that in the second or third search result." | |
| 22:18:55 | JayF | admiyo: combine that with our new runbooks feature to basically encapsulate sets of steps to perform maintenance + our service feature (basically perform manual cleaning on an active node) == fully self-serve, curated maintenance by the project that runs the node | |
| 22:19:39 | JayF | (this is my downstreams' story: now they can perform firmware updates by providing a runbook to their downstream teams, and those teams can call Ironic API directly to run those runbooks so they can coordinate their own maintenance without ever having to talk to another human) | |
| 22:19:59 | sean-k-mooney[m] | admiyo: they are all ato opendev.org/openstack/whatever but untile we mvoed to gitea away for git web i always wanted the github result | |
| 22:20:20 | admiyo | I know. ..and I am just in grumpy old man mode | |
| 22:20:36 | sean-k-mooney[m] | now that we actully have a nice web ui im fine with either to be honest | |
| 22:20:37 | admiyo | I wanted the upstream repo URL to clone | |
| 22:20:37 | JayF | sean-k-mooney[m]: admamcarthur7 (someone who works at GR-OSS part time on Ironic) actually said they /prefer/ the gitea opendev.org instance over github | |
| 22:20:40 | JayF | sean-k-mooney[m]: I was shocked | |
| 22:20:53 | JayF | s/gitea/whatever_the_hell_that_web_ui_is/ | |
| 22:20:55 | JayF | lol | |
| 22:21:17 | sean-k-mooney[m] | JayF: the search was worse on gitea btu github has been getting worse at that lately | |
| 22:21:35 | JayF | since discovering ripgrep, I almost never search using anything but get a local clone -> rg string | |
| 22:22:11 | sean-k-mooney[m] | rg is fast so is ag the_silver_searcher | |
| 22:22:35 | admiyo | "is_admin": "rule:admin_api or (rule:is_member and role:baremetal_admin)" | |
| 22:23:14 | JayF | sean-k-mooney[m]: https://github.com/ggreer/the_silver_searcher last commit 4 years ago; ripgrep is still maintained | |
| 22:23:19 | admiyo | JayF, so that looks sane. It avoids the problem that I saw on the keystone one. It looks like the onus is on Keystone. And I think the tirck there is to allow a user to only assign roles that they themselves already have, to include implied roles | |
| 22:23:33 | JayF | sean-k-mooney[m]: although knowing ggreer it's probably just that it doesn't need any more code written lol | |
| 22:23:59 | sean-k-mooney[m] | ya it kind of does what it needs too i still use vainall grep | |
| 22:24:03 | admiyo | so id admin implies member, someone with the admin role can assign member. But if I want to make a project manager, they should not (CANNOT!) be allowed to assign admin to anyone in their project | |
| 22:24:04 | sean-k-mooney[m] | but i should swap | |
| 22:24:44 | sean-k-mooney[m] | admiyo: manager would imply member and member would imply reader | |
| 22:24:53 | admiyo | Exactly. | |
| 22:24:54 | sean-k-mooney[m] | you will only be able to delgate roles you have | |
| 22:24:58 | sean-k-mooney[m] | so not admin | |
| 22:25:03 | admiyo | ++ | |
| 22:25:11 | admiyo | That was one of the reasons I wrote that feature... | |
| 22:26:55 | sean-k-mooney[m] | we dont plan to remove admin by the way but we do plan to reduce what its used for as much as possibel by making it doable via manager or service depending on if a human should do it | |
| 22:27:16 | sean-k-mooney[m] | nova’s external evnets api should be service only | |
| 22:27:50 | sean-k-mooney[m] | because humans even the global adim should not send an event impersonating a openstack service | |
| 22:28:32 | JayF | honestly service scope is still the one thing that doesn't make a lot of sense to me | |
| 22:28:39 | JayF | how it's different than system scope in any context except keystone | |