| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 20:39:04 | admiyo | sean-k-mooney[m], let me take a look at the Nova API policy enforcement to make sure I understand the approach. | |
| 20:39:29 | sean-k-mooney[m] | while i dan and gman all took part in the discusion the direction was not set by the nova comunity | |
| 20:40:20 | admiyo | sean-k-mooney[m], I am aggressive on it, because it has been met with ignorance for a long time, and I put a lot of effort in to it. And because it was one of the reasons that the project was long term hurt in adoption. But I am going to do my due diligence now to see if I understand the state of it. | |
| 20:40:50 | admiyo | I did talk with the Keystone devs and there are aspects to this solution that they did not understand, and so I don't trust that the solution is in place yet. | |
| 20:44:50 | gmann | I agree that we might have solved all the cases for access control but seeing the back and forth approach for so many years, we are trying to mainly solve 1. project personas (mainly ready role and new one called project manager )2. better service to service interaction | |
| 20:45:02 | gmann | there is idea of global reader also but its spec not yet up | |
| 20:46:09 | gmann | and i think doing these in bit and pieces taking mostly asked personas as first step is the feasible solution otherwise we could have stuck on it for another 5 years | |
| 20:48:13 | sean-k-mooney[m] | most of the intiall work was completed in https://specs.openstack.org/openstack/nova-specs/specs/train/approved/policy-default-refresh.html in 2019 | |
| 20:48:30 | sean-k-mooney[m] | we then had to rip out and redo a subset of that | |
| 20:48:36 | gmann | yeah | |
| 20:48:38 | sean-k-mooney[m] | mainly the systemscopted parts | |
| 20:48:58 | sean-k-mooney[m] | and since hten we have been focusing on the personas that operators were actully asking for | |
| 20:49:12 | sean-k-mooney[m] | the reader roles was the highest priorty | |
| 20:49:37 | sean-k-mooney[m] | then the servicer role gained impoartnace for CVE reasons and now we are working on the manager role | |
| 20:49:49 | gmann | exactly. for system scope, I will say we tried to sell this new feature to operators when they did not require it :) | |
| 20:49:55 | sean-k-mooney[m] | for that soped hiher privaldged user that is not global admin | |
| 20:50:51 | gmann | everyone mainly asked for reader role and we tried to give them system scoped concept also which made them confused and break | |
| 20:50:55 | sean-k-mooney[m] | but even before the work in train you could have had custom policy it just was not in tree so this has evovled alot over the last 10 years | |
| 20:51:28 | gmann | true, main idea is to make our default as close as what operator override to | |
| 20:51:47 | gmann | we cannot match each and every cases but match with the mostly used one | |
| 20:52:18 | sean-k-mooney[m] | which is always a blance between public cloud usecases and private cloud | |
| 20:52:30 | admiyo | You have put a lot of work in to this. | |
| 20:53:34 | admiyo | It is 7 years since I stepped away from the project, and you are still working on it. | |
| 20:53:34 | sean-k-mooney[m] | gmann has alot more then i as they have also been invovled in the tempest testing of this not just enabling it in one porject | |
| 20:54:08 | sean-k-mooney[m] | yep we littally impemetned project scopes released it and operators said no | |
| 20:54:17 | gmann | :) progress is slow I agree but If I count we have ~12 projects implemented the project personas reader role which is good | |
| 20:54:20 | sean-k-mooney[m] | so we had to rip it out as we had no path to enable it by defualt | |
| 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 | |