| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 17:46:26 | opendevreview | Merged openstack/placement master: Remove Python 3.8 support https://review.opendev.org/c/openstack/placement/+/925648 | |
| 18:44:34 | gmann | admiyo: we have not touched the admin role due to not breaking the users. and like sean-k-mooney mentioned project manager is something (going to be implemented in Nova soon) which can serve as higher authority than member/reader role within project | |
| 19:04:55 | opendevreview | Merged openstack/nova master: VMware: updates resource provider trait list https://review.opendev.org/c/openstack/nova/+/926522 | |
| 20:30:21 | admiyo | gmann, you could start by acking that there is a problem and not marking the bug as a woishlist item tagged will not fix. It is a real problem and requires a united effort across openstack to address. I can appreciate that the systems roles approach doesn't work for people. I had stepped back when the Keystone leadership pivoted to that approach instead of "is_admin_project" and now seeing that the other approach fell | |
| 20:30:21 | admiyo | apart, I am trying to make sense of the landscape. | |
| 20:32:57 | admiyo | If I understand correctly, you have taken the approach of "make it impossible to assign the role admin except to system wide admin users" which is a feature that was not in Keystone when I left the project, and which would have broken other projects at the time. I think it is still not correct, but it might be good-enough. | |
| 20:37:47 | sean-k-mooney[m] | admiyo: the pivort away form that happend many many years before the change in direction. the idea of a specal adming project was not how openstack worked before we started supporting python 3 | |
| 20:38:56 | sean-k-mooney[m] | admiyo: ill also note that you are taking a very agressive approach there in blaming people for a descision taht was made collectivily over the course of many years | |
| 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 | 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:53:34 | admiyo | It is 7 years since I stepped away from the project, and you are still working on it. | |
| 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 | admiyo | as opposed to crawling through all the apis. | |
| 20:57:20 | sean-k-mooney[m] | we now also use yaml instead of json for reasons | |
| 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 | sean-k-mooney[m] | ah its here https://docs.openstack.org/nova/latest/configuration/policy-concepts.html | |
| 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: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 | |