Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-10-16
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
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.

Earlier   Later