Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-10-16
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
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 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:37 admiyo I wanted the upstream repo URL to clone
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
22:29:05 sean-k-mooney[m] the diffent is scopes apply to the resouce not the token
22:29:27 sean-k-mooney[m] a port is owned by a project nto the system
22:29:44 sean-k-mooney[m] bindign a port to a host is a privaldaged action
22:29:46 JayF so if I take off my Ironic hat for a moment
22:29:55 JayF (since we have a history as admin-only I think we are exceptional a little)
22:29:58 sean-k-mooney[m] only servies shoudl be able to do that not humans
22:30:09 JayF essentially: a system-scoped admin shouldn't be able to do things to project-scoped items, generally
22:30:23 JayF only a service-scoped admin would, since service implies the ability to operate cross-project
22:30:23 sean-k-mooney[m] correct
22:30:32 JayF that makes so much sense why it doesn't make sense in Ironic then
22:30:44 JayF because we have to carry system-scope forward for everything due to $historical_baggage more or less
22:31:07 JayF at least until we're willing to require all new node creations to be scoped to a project, which will likely make a lot of our users unhappy
22:31:09 sean-k-mooney[m] another example form recent cves
22:31:13 admiyo JayF, that was my understanding, but the nova users seem to balk at that change. I am not certain it is alwyas wise tolisten to your users. I suspect in this case it will be good-enough.
22:31:26 sean-k-mooney[m] its safe for a normal user to detach a volume form a nova instance via the nova api
22:31:34 sean-k-mooney[m] its not safe to do that via cinders api
22:31:47 sean-k-mooney[m] so the cinder api requires the service role now
22:31:51 admiyo The problem is how role assignments are done in keystone. If you can do a role assignemnt, you can assign any role.
22:31:55 sean-k-mooney[m] but the nova detach volume api is member
22:31:59 admiyo So that needs to be fixed post haste
22:32:01 JayF oh no, this is venturing close to your favorite beef with the ironic model. Iceberg, dead ahead! Hard to port! LOL
22:32:37 admiyo I think that each API should actually have its own role, and then you use implied role assignments to link to the roles that users actually get
22:32:40 sean-k-mooney[m] well ironci is technically a service so it gets some leway because ye should be able to manage voluem in standalone mode
22:32:59 admiyo so ironic_volume could be a role, and admin implies ironic_volume
22:33:19 JayF that kills a big part of the operator value of the RBAC model
22:33:28 admiyo The issue is that Nova users are using project scoped tokens to do system wide operations.
22:33:35 sean-k-mooney[m] admiyo: it could btu we dont want to have service specific roles
22:33:41 sean-k-mooney[m] we want to have common personas
22:33:44 JayF I would never want, e.g., a reader role that didn't work for all services
22:33:50 admiyo personas are roles.
22:33:52 sean-k-mooney[m] that have a reasonable meeaning across all services
22:34:04 JayF sean-k-mooney[m]: ++ and that persona-based stuff is the value of the RBAC model to operators imho
22:34:05 sean-k-mooney[m] they are but personas are not service specific
22:34:15 sean-k-mooney[m] yep i agree
22:34:26 JayF the Ironic access granted to a nova user who just provisioned an instance is an A++ example of that tbh
22:34:27 admiyo i think in 3 levels
22:34:40 JayF a great example of how we carry the idea of that persona cross-project now in ways we didn't before
22:34:54 sean-k-mooney[m] the fact that you dont need ot give peopel createor on barbican and stack_operator? on heat and just use member was a big win
22:35:19 admiyo implied roles
22:35:38 admiyo reader implies nova_reader
22:35:46 admiyo or something ....
22:35:52 sean-k-mooney[m] we dont want role explsoiton or the imped roels to depend on which service are deployed
22:36:38 sean-k-mooney[m] having sepcific roels that are common across all clouds was part of the interop story
22:36:54 admiyo ah the old explosion argyument
22:37:07 sean-k-mooney[m] so instead of having nova_reader and ironic_reader we have jsut reader which works the same for each proejct
22:37:18 admiyo yeah, that is fine for somethings.
22:37:51 admiyo I think 3 levles: top level persona. bottom level resource. Middle level workflow
22:38:05 JayF Part of what I like about the policy model is that if you need more specific things than that, you can self-serve. It allows us flexibility without making our users get bombarded with a ton of information up front (e.g. the role explosion).
22:38:42 admiyo Execpt that the largest deployer, Red Hat, does not allow policy customization.
22:39:02 JayF I don't work there, I'm an OpenStack upstream contributor :)
22:39:11 JayF find someone with a red hat to complain to about red hat policies :)

Earlier   Later