Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-11-09
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
20:48:31 sean-k-mooney so that with project_admin you coudl list hosts and only see those hosts
20:48:41 sean-k-mooney so no system reader
20:48:54 sean-k-mooney needed to boot to a host you are allowed to boot too
20:49:28 sean-k-mooney if you are not limited to an aggreate i guess that would list all hosts
20:49:30 gmann but host is not project level info right
20:49:38 sean-k-mooney it kind of is
20:49:48 sean-k-mooney we supprot assocating tenats/project to aggreates
20:50:00 sean-k-mooney via either a placment prefilter or a schduler post filter

Earlier   Later