| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-09 | |||
| 20:05:21 | sean-k-mooney | gmann:is there a spec or something covering the use of token scopes with nova. i dont see anythin after the ussuri spec https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/policy-defaults-refresh.html | |
| 20:05:44 | sean-k-mooney | that does nto cover the domains | |
| 20:06:06 | sean-k-mooney | the 4 scopes in https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/policy-defaults-refresh.html#use-cases make sense to me | |
| 20:06:41 | sean-k-mooney | but i dont see a defeintion for system_member, project_admin, domain_(reader, member or admin) | |
| 20:07:36 | sean-k-mooney | we have some interset down stream in supporting a 3*3 matix (reader, memeber, admin) *( project, domain, system) | |
| 20:08:38 | sean-k-mooney | but i dont recall ever disscuing domains or proejct admin and system memebr in the context of nova upstream | |
| 20:09:52 | sean-k-mooney | https://review.opendev.org/#/c/698397/14/etc/rbac-persona-accounts.yaml.sample has entries for all 9 roles | |
| 20:10:31 | sean-k-mooney | but given we have not had any specs or cross project session on this im having a hard time relateing that to how we would support this in nova | |
| 20:10:50 | sean-k-mooney | gmann: i know there was a pop up team but any pointers on where this might have been discussed | |
| 20:12:55 | sean-k-mooney | melwitt: johnthetubaguy any input on ^ | |
| 20:16:21 | gmann | sean-k-mooney: we have project_admin in nova for case like creating server with host specify but system_member is not there as not needed from current policy rules | |
| 20:16:41 | gmann | also domain scope (it's three pesona) | |
| 20:16:56 | sean-k-mooney | do you have docs for this | |
| 20:17:06 | sean-k-mooney | there were only 4 included in the spec | |
| 20:17:12 | sean-k-mooney | project_admin was not one of them | |
| 20:17:17 | gmann | yeah, I updated policy doc for that | |
| 20:18:04 | sean-k-mooney | ok because form a spec point of vew we only ever approved system_admin, project_memeber system_reader and project_reader | |
| 20:18:32 | gmann | sean-k-mooney: this does not include what all combination nova support but give an idea on new policy - https://docs.openstack.org/nova/latest/configuration/policy-concepts.html | |
| 20:18:33 | sean-k-mooney | so since this is an api cahnge im kind of confused why we dont have a spec for supporting other scopes and ropels in nova | |
| 20:19:23 | melwitt | yeah, that ^ is the doc I was searching for wrt the support in nova | |
| 20:19:24 | gmann | sean-k-mooney: project_admin came up during implementation only and that is for create server with specific request (like force host, zero disk flavor etc) on;y | |
| 20:19:45 | sean-k-mooney | ok but are we actully using it in code | |
| 20:20:10 | sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/policy-defaults-refresh.html is the only spec that exist for this so really without a spec to add it we should not be useing in the api right | |
| 20:20:58 | gmann | as part of policy defaults yes but we do not change token in nova right? whatever token is used for API access will be validated against the policy values | |
| 20:21:45 | sean-k-mooney | my concern is really for domains im concerend that a domain member may not have a project | |
| 20:21:56 | gmann | sean-k-mooney: I am not sure about supporting other scopes. if we want domain scope control in nova then we need to see what all nova API operations are domain level and system level. | |
| 20:22:01 | sean-k-mooney | maybe they do but if they dont then that will break our api assumtions | |
| 20:22:11 | gmann | i never thought of domain in nova. | |
| 20:22:28 | sean-k-mooney | its come up downstream my responce is right now we dont support it | |
| 20:22:38 | gmann | and they use domain member user to access nova API ? | |
| 20:22:49 | sean-k-mooney | well its not a thing yet | |
| 20:23:06 | sean-k-mooney | we have a request to supprot RBAC for osp 17 which will be based on wallaby | |
| 20:23:15 | melwitt | yeah, my understanding is that we now have the code needed to handle scoped tokens in nova, so the way that they get used is someone (a user) has to request scoped tokens and use them when they call nova and then policy can validate the token against the policy | |
| 20:23:18 | gmann | ok, in that case they can assign admin/member/reader role on required project | |
| 20:23:27 | sean-k-mooney | but since domain was never discussed upstream i wanted to push back to just the 4 roles we intended to support | |
| 20:24:17 | sean-k-mooney | melwitt: right but we need to agree what scopes and roles are required for each endpoint | |
| 20:24:32 | sean-k-mooney | and what each scope/roles allows you to do | |
| 20:24:40 | gmann | sean-k-mooney: these are combination we support currently - https://github.com/openstack/nova/blob/master/nova/policies/base.py#L48-L54 | |
| 20:25:00 | gmann | sean-k-mooney: i can add these in policy doc so that we do not need to point these to code | |
| 20:25:20 | sean-k-mooney | project admin is the only one im not expecting since we nver approved that in a spect | |
| 20:25:46 | sean-k-mooney | the rest make sense to me | |
| 20:26:33 | sean-k-mooney | for example we discussed in the ptg that prject admisn shoudl not be aware of the hosts vms run on | |
| 20:26:41 | gmann | sean-k-mooney: also html policy doc mention the scope of each policy/API as part of oplicy documentation - https://docs.openstack.org/nova/latest/configuration/policy.html | |
| 20:26:45 | sean-k-mooney | but you mentioned that one of the usecase was allowing them to boot on a host | |
| 20:26:53 | gmann | yeah | |
| 20:27:10 | sean-k-mooney | have we released with project_admin yet | |
| 20:27:15 | gmann | you remember in PTG we discuss about it | |
| 20:27:35 | sean-k-mooney | i rememebr the one two weeks ago | |
| 20:29:18 | gmann | my initial thought while adding PROJECT_ADMIN was that this is temp and TODO will remove this - https://github.com/openstack/nova/blob/45e8fa3ade54313754fbea245ad546097150486d/nova/policies/servers.py#L179 | |
| 20:29:35 | sean-k-mooney | i kind of which there was a spec for projecft admin because i really ame not sure that the current usaged in the api are valid | |
| 20:29:59 | sean-k-mooney | gmann: we cant remove it | |
| 20:29:59 | gmann | but as we discussed in PTG, I think it make sense to keep it and ask users to assign appropriate role to let users to boot on specific host | |
| 20:30:14 | sean-k-mooney | well not without a microverion | |
| 20:30:48 | gmann | this is policy default change so microversion not required if we change any of these | |
| 20:30:52 | sean-k-mooney | making it sys_admin i think make sense | |
| 20:31:10 | sean-k-mooney | from an interoperablity point of view im not sure i agree | |
| 20:31:30 | gmann | sean-k-mooney: that is the things we discussed in PTG. my proposal was sys_admin and take project_id as request param. | |
| 20:31:30 | sean-k-mooney | for this case since i kind fo want to revert this out and make it system_admin im happy to agree | |
| 20:32:07 | sean-k-mooney | that is a different usecase | |
| 20:32:14 | gmann | but with sys_adm, project_id needs to be passed for which sys admin want to create server for | |
| 20:33:07 | sean-k-mooney | yes so that is the actuall cloud admin creating a server in a project in responce to a supprot request or something | |
| 20:33:29 | sean-k-mooney | that is differnet for giving a customer a project adminsitarto role and allowign them to do it in a self service manner | |
| 20:33:39 | sean-k-mooney | that is what project_admin role would mean | |
| 20:34:04 | sean-k-mooney | gmann: im fine with the sysadmin doing what your proposing | |
| 20:34:38 | sean-k-mooney | but ithe proejct_admin persona im describing i dont think shoudl have any awareness of hosts | |
| 20:35:39 | sean-k-mooney | gmann: anyway thanks ill review the docs you linked. | |
| 20:36:05 | gmann | that was my thought while proposing this but johnthetubaguy melwitt point was it is asking cloud admin to give extra role to user (project_admin or system_reader to know host info) to allow users to boot on specific host | |
| 20:36:55 | sean-k-mooney | so that is something i think we need to actully discuss if we are every to use those poices by default in code | |
| 20:37:01 | sean-k-mooney | vai a spec | |
| 20:37:29 | sean-k-mooney | becaue you are fundimentally change the way the api works allowing operation to work for a different set of users | |
| 20:37:38 | gmann | which make sense to me too after PTG discussion. so from nova API side we say 'sustem_reader is role you need to know host info' and 'project_admin is role to boot instance on requested host' so you can assign those based on users req | |
| 20:38:30 | sean-k-mooney | ya although i think there are more details to be worked out | |
| 20:38:32 | gmann | sean-k-mooney: right, for migrating to new policy, cloud provider needs to change the existing users token | |
| 20:39:02 | sean-k-mooney | like shold a project admin be allowed to do a live migration? | |
| 20:39:30 | sean-k-mooney | shoudl they see the host in the server show (based on the above no unles they have system_reader) | |
| 20:40:42 | gmann | sean-k-mooney: as default policy no but live migration case we opened for system as well as project scope also. in case use case is to allow users to perform live migration. | |
| 20:40:46 | sean-k-mooney | giving the proejct admin system reader also feels slightly wrong | |
| 20:41:18 | gmann | sean-k-mooney: let me propose doc update what we agreed in PTG and then we can see how it looks like. it is too much asking to providers or ok. | |
| 20:41:19 | sean-k-mooney | e.g. im not sure you should have readonly access to everything | |
| 20:41:53 | sean-k-mooney | gmann: well im trying to gague the impact to us downstream from a support point of view | |
| 20:43:10 | gmann | If provider want to allow any users to boot on requested host then giving system_reader to them not bad so that they can access host info. | |
| 20:43:43 | sean-k-mooney | gmann: tehy could also acess other info right | |
| 20:43:51 | sean-k-mooney | e.g. list all servers | |
| 20:43:59 | sean-k-mooney | or all keypairs | |
| 20:44:09 | sean-k-mooney | for all users | |
| 20:44:15 | gmann | yeah that is one issue. | |
| 20:44:25 | sean-k-mooney | that makes it a non starter for me | |
| 20:44:42 | sean-k-mooney | system reader is basically full admin but readonly right | |
| 20:45:06 | sean-k-mooney | so i could use it to find the fix ips of other tenants insntances | |
| 20:45:43 | sean-k-mooney | if it was not scoped to noava i could hten list the security groups to find open ports and try connecting to them | |
| 20:45:47 | gmann | well with override policy they can restrict, like list server for all is controlled with separate policy. list keypairs can be restricted with user_id | |
| 20:46:15 | sean-k-mooney | ok | |
| 20:46:21 | sean-k-mooney | but im worried about the support matrix | |
| 20:46:24 | gmann | but i agree that is open things for them which was point in PTG also | |
| 20:46:49 | sean-k-mooney | e.g. use agreeing to support anythong other then the nova default by default with our custoemrs | |
| 20:47:12 | gmann | may be admin need to carefully select such users and trust them if they are allowed to boot on requested host ? | |
| 20:47:35 | sean-k-mooney | maybe but that basically to me say we can never enabel this by default | |
| 20:47:43 | sean-k-mooney | well | |
| 20:47:54 | sean-k-mooney | no its the use fo system_reader that is too heavy here | |
| 20:48:16 | sean-k-mooney | i kind fo would liek if we could use the tenant isolation aggreate info | |