Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-10-16
15:09:18 sean-k-mooney admiyo: if you want to change the direciton you need to do that at the openstack level and change the grovernace resolution
15:10:11 admiyo Can you state that none of Novas APIs require Admin in order to perform operations that an end user needs to be able to do? To include project self maintainence like remove some resource where the owner has quit
15:10:46 sean-k-mooney as far as i am aware that has been true for at least 10 years
15:10:49 sean-k-mooney maybe more
15:10:51 admiyo That was not the case when we opened the bug, and it was a critical security issue.
15:11:22 admiyo Then you fixed it
15:11:43 sean-k-mooney in nova all end user creatable resocues are owned by teh project not the user with the sole excption of the ssh keypair
15:12:27 admiyo Yeah, let us avoid that rabbit hole
15:12:38 sean-k-mooney the reason is say at leat 10 years is i have worked on openstack since havana and i belive it was true for nova even then
15:12:52 admiyo I think that the issue I remember was flavors.
15:13:05 sean-k-mooney flavor s shoudl nto eb managebale by end users
15:13:27 admiyo And images in glance was an issue that they addressed.
15:14:11 admiyo So you can see, it was an Openstack wide issue, and you DID address it. And it certainly affected Nova.
15:15:04 admiyo BTW, the original implementation was done by termie, the solution of having admin projects was also suggested by him. I was justtrying to keep things consistent with how the main projects viewed things.
16:11:15 opendevreview Amit Uniyal proposed openstack/nova stable/2024.1: Reproducer test for image property hw_architecture https://review.opendev.org/c/openstack/nova/+/932531
16:11:16 opendevreview Amit Uniyal proposed openstack/nova stable/2024.1: Libvirt: updates resource provider trait list https://review.opendev.org/c/openstack/nova/+/932532
16:11:56 opendevreview Amit Uniyal proposed openstack/nova stable/2023.2: Reproducer test for image property hw_architecture https://review.opendev.org/c/openstack/nova/+/932533
16:11:57 opendevreview Amit Uniyal proposed openstack/nova stable/2023.2: Libvirt: updates resource provider trait list https://review.opendev.org/c/openstack/nova/+/932534
16:13:07 opendevreview Amit Uniyal proposed openstack/nova stable/2023.1: Reproducer test for image property hw_architecture https://review.opendev.org/c/openstack/nova/+/932536
16:13:08 opendevreview Amit Uniyal proposed openstack/nova stable/2023.1: Libvirt: updates resource provider trait list https://review.opendev.org/c/openstack/nova/+/932537
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 apart, I am trying to make sense of the landscape.
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: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 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.

Earlier   Later