| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 20:54:36 | admiyo | And they implemented system scopes based on operator feedback. | |
| 20:54:46 | gmann | this cycle, I am going to make more progress on remaining projects and manager role in core services | |
| 20:56:08 | admiyo | It used to be possible to generate the default policy file from the code. I am assuming that is still the case, and that I need a proper tox set up to do so. As I recall, that was tox genpolicy? | |
| 20:56:11 | sean-k-mooney[m] | i belive nova,neutron,placement, ironic and maybe glance and cidner + obviously keystoen had system scope | |
| 20:56:24 | sean-k-mooney[m] | now it has been removed form all but keystone and ironic i think | |
| 20:56:50 | gmann | yes, genpolicy tox env | |
| 20:56:55 | sean-k-mooney[m] | that is still possible yes althoguh you dont need a policy file anymore | |
| 20:57:07 | sean-k-mooney[m] | you only need it if you want to change it | |
| 20:57:11 | admiyo | It just allows me to see what the actual policy enforcement is, though | |
| 20:57:20 | sean-k-mooney[m] | we now also use yaml instead of json for reasons | |
| 20:57:20 | admiyo | as opposed to crawling through all the apis. | |
| 20:57:34 | admiyo | I think comments were the primary driver | |
| 20:57:37 | gmann | yeah | |
| 20:58:35 | sean-k-mooney[m] | if you do want to look at the code its all in https://github.com/openstack/nova/tree/master/nova/policies | |
| 21:00:37 | sean-k-mooney[m] | and this is our doc on this topic https://docs.openstack.org/nova/latest/configuration/policy-concepts.html | |
| 21:01:32 | sean-k-mooney[m] | i think we had a rednered policy file soemwhere in the docs but you can also gernerated it locally | |
| 21:01:37 | admiyo | I was, but the logic aaaround deprecations and such made it hard for me to determine exactly what was meant by ADMIN. So I figure that the policy generator is going to evaluate it down to how it is actuall implemented. | |
| 21:01:37 | sean-k-mooney[m] | ah its here https://docs.openstack.org/nova/latest/configuration/policy-concepts.html | |
| 21:02:32 | sean-k-mooney[m] | admin is now just does the token have the admin role | |
| 21:02:47 | admiyo | yeah, I think it is still broken. Hold on. | |
| 21:03:04 | sean-k-mooney[m] | https://github.com/openstack/nova/blob/ed2bf3699ddc360fb646b895560fa9dbcfd6beba/nova/policies/base.py#L40 | |
| 21:03:44 | sean-k-mooney[m] | the rule is defiend here https://github.com/openstack/nova/blob/ed2bf3699ddc360fb646b895560fa9dbcfd6beba/nova/policies/base.py#L40 | |
| 21:05:16 | admiyo | you can't have it both ways. either ADMIN is scoped to the project, or it is global. If there are cases where it needs to be scoped to a project, you can never assign that role to anything other than a system power user, and thus you have an un-delegatable operation. | |
| 21:05:51 | sean-k-mooney[m] | admin is global the resouces in the api are porject scoped | |
| 21:06:02 | sean-k-mooney[m] | yep | |
| 21:06:18 | sean-k-mooney[m] | it can only be asgined to the sytem power user i.e. the root of openstack | |
| 21:06:27 | sean-k-mooney[m] | that is however that role is defiend now | |
| 21:07:59 | admiyo | And that is OK, so long as you don't also need the other. So anything which is rule:context_is_admin" is essentially something reserved for system administators | |
| 21:08:28 | admiyo | for example (first one I saw) #"os_compute_api:os-admin-actions:reset_state": "rule:context_is_admin" | |
| 21:08:53 | admiyo | so the only people that can perform a reset_state operation on a server is a system administrator, right? | |
| 21:09:41 | admiyo | #"os_compute_api:os-aggregates:set_metadata": "rule:context_is_admin" | |
| 21:09:43 | admiyo | and so on? | |
| 21:10:07 | sean-k-mooney[m] | yes reset state is very dangourse | |
| 21:10:09 | admiyo | #"os_compute_api:os-assisted-volume-snapshots:delete": "rule:context_is_admin" | |
| 21:10:28 | sean-k-mooney[m] | it basically bypassing all oru saftey checks and has a high probability of requireing db surgery | |
| 21:10:42 | sean-k-mooney[m] | so reset state is not someing that and end user should every be able to do | |
| 21:11:09 | sean-k-mooney[m] | the assisted volume snapshot api | |
| 21:11:18 | sean-k-mooney[m] | is not ment to be used for humans | |
| 21:11:25 | sean-k-mooney[m] | its reseved exclustivly for cinder | |
| 21:11:52 | sean-k-mooney[m] | in the future admin will not be able to call it and it will require the service role instead | |
| 21:12:10 | sean-k-mooney[m] | aggerate metadata is also systems scoped | |
| 21:12:29 | sean-k-mooney[m] | so all of the above are examples of things only global admisn should be able to do | |
| 21:12:56 | sean-k-mooney[m] | aggreate metadata is basically to allow openstack admins to map capablity to speicifc hosts | |
| 21:13:04 | sean-k-mooney[m] | i.e. to reserve hyperviors for specific tenants | |
| 21:13:19 | admiyo | OK I think I see how things are going. | |
| 21:13:21 | sean-k-mooney[m] | or partions kvm hosts for hyperv ectra | |
| 21:14:47 | sean-k-mooney[m] | service can escualte on behalf of users in some cases where appriate. i.e. if you do a cinder snapshot of a volume as a normal user cinder willl call novas assisted snapshot api as an admin if and only if the volume is attached to a nova instace | |
| 21:14:58 | admiyo | sean-k-mooney[m], understand that in order to implement this, Keystone had to break its users. | |
| 21:15:06 | sean-k-mooney[m] | where that is required we are trying to move those endpoint to the service role | |
| 21:15:29 | admiyo | I still think this is fragile, but I can see where it is sufficient | |
| 21:15:53 | sean-k-mooney[m] | as far as i am ware the usage of admin i am descibeing has been there since 2013 | |
| 21:16:26 | sean-k-mooney[m] | i think longer but i started working on quantom in 2013 at the end of havana | |
| 21:16:46 | admiyo | Yes, it predated essex. It was designed broken | |
| 21:17:20 | sean-k-mooney[m] | so we now have 12 years of oeprators expecting this global admin behvior | |
| 21:17:44 | admiyo | Yep. But it also had serious side effects | |
| 21:18:02 | sean-k-mooney[m] | yep both good and bad | |
| 21:18:06 | admiyo | don't think of the people that use the system. Think of the people that decided not to because they could not expose their APIs to their end users | |
| 21:18:16 | admiyo | I think it seriously affected adoption. | |
| 21:18:40 | sean-k-mooney[m] | what i dont get is you could alwasy use custom policy | |
| 21:18:45 | admiyo | It is the same problem as having to do everything as root in a linux system. Fine if you are the only one using it.... | |
| 21:19:03 | admiyo | And I did serious education on using custom policy at the time. | |
| 21:19:19 | sean-k-mooney[m] | so downstream we impemented the reader roled using custom policy in wallaby | |
| 21:19:30 | admiyo | But it was hard to make custom policy that worked across a whole deployment consistently | |
| 21:19:46 | admiyo | The defaults varied from project to project | |
| 21:20:12 | sean-k-mooney[m] | right so since the reader role was not aviable in wallaby in every proejct we litally wrote custome policy for every service to make it consitnt | |
| 21:20:37 | admiyo | https://www.youtube.com/watch?v=5G-LYCfABJY | |
| 21:20:49 | admiyo | I am so sorry | |
| 21:22:00 | admiyo | It was made harder when everyone decided to move policy in to code, and hard-code the defaults. Before, when everyone had to use a policy file, it was simpler to say "replace yours with this one" | |
| 21:22:35 | admiyo | And when Red Hat went with TripleO and everything had to be generated from a Puppet manifest, I made an honest effort, and then gave up | |
| 21:22:52 | admiyo | I really felt like people wanted to keep it broken. | |
| 21:23:01 | admiyo | #"os_compute_api:os-migrations:index": "rule:context_is_admin" | |
| 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 | 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:00 | sean-k-mooney[m] | glance now only uses unifed limits | |
| 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. | |