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

Earlier   Later