| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-10 | |||
| 15:27:31 | gmann | yes | |
| 15:27:46 | stephenfin | Instead of adding e.g. a 'project_id' field to the request body for that | |
| 15:27:52 | stephenfin | Gotcha | |
| 15:27:57 | gmann | exactly | |
| 15:28:48 | stephenfin | So my gut says for this to happen, we'd have to insist on tenant-isolation | |
| 15:29:10 | gmann | gibi: stephenfin but if we want to be more secure, I think returning no host if no matching 'filter_tenant_id' is also fine for me | |
| 15:29:46 | gmann | and if we get any use case to allow non-'filter_tenant_id=project_id' host then we can see | |
| 15:30:07 | gmann | i mean the current way stephenfin doing. | |
| 15:30:15 | stephenfin | I think that's necessary. Listing all hosts in a deployment is too much power | |
| 15:31:01 | gibi | I agree | |
| 15:31:02 | stephenfin | (Continuing to think out loud) Even with that though, it's still odd that we will now allow users to list some hypervisors but we won't show them the 'OS-EXT-SRV-ATTR:hypervisor_hostname' attribute | |
| 15:31:02 | gmann | yeah, and it contradict our new concept of system vs project .. | |
| 15:31:30 | stephenfin | But maybe not as odd as having to ask a system admin to create an instance for you | |
| 15:31:45 | stephenfin | gmann: This is a tricky problem :) | |
| 15:32:34 | gmann | stephenfin: humm, yeah but let it be strict use case of 'you want to create server on host so you can get hypervisor list but no where else we will return host info' | |
| 15:33:13 | gibi | how I see 1) if there is strict tenant isolation and I'm the admin of that tenant then it is OK that I can see the hosts dedicated to my tenant and also it is OK that I can specify which host a VM lands on 2) if there is no strict tenant isolation then a project admin should not see more hypervisor info than a project member and also should not be able to specify which host a VM lands on | |
| 15:33:44 | gmann | +1 | |
| 15:33:52 | gibi | in short if there is isolation then inside an isolated buble the project admin can do whathever | |
| 15:33:59 | gibi | I don't care | |
| 15:34:05 | gibi | but as soon as tenants interact | |
| 15:34:15 | sean-k-mooney | gibi: i can live it that. i was leanign to be more generous and say if ther eis not strict isolation for this tenat | |
| 15:34:16 | gibi | the project admin should no have super power | |
| 15:34:22 | sean-k-mooney | then it can see all host that are not isolated | |
| 15:34:39 | stephenfin | gibi: so should we add another check to 'POST /servers'? | |
| 15:34:40 | gmann | can we add this info in api-ref? this will clarify the usage for this API. | |
| 15:34:50 | sean-k-mooney | since that would be the set of host they could boot on | |
| 15:34:51 | gmann | at lest by seeing how confusing those API combination is | |
| 15:34:59 | stephenfin | if I'm a project admin, the host I request must belong to an aggregate I'm isolated to | |
| 15:35:10 | gibi | agree ^^ | |
| 15:35:12 | sean-k-mooney | requireing isolation is ok too | |
| 15:35:16 | gmann | stephenfin: gibi for POST server we do not need as they do not know the host info | |
| 15:35:35 | stephenfin | gmann: you could conceivably guess | |
| 15:35:40 | gmann | ohk on agrregate check for POST eyx | |
| 15:35:41 | gmann | yes | |
| 15:35:59 | stephenfin | What do we return? HTTP 403? | |
| 15:36:16 | stephenfin | I'm not sure if this warrants a microversion or not. Policy changes like this are weird | |
| 15:36:19 | sean-k-mooney | i think that is what the existing policy would return | |
| 15:36:33 | sean-k-mooney | if a project_member did it | |
| 15:36:39 | openstackgerrit | Dan Smith proposed openstack/nova master: Make nova-ceph-multistore use policy.yaml https://review.opendev.org/c/openstack/nova/+/779815 | |
| 15:36:40 | stephenfin | not for a project admin though | |
| 15:36:40 | gmann | yeah 403 is better, if they do not pass policy permision or and host does not elong/allow them | |
| 15:37:01 | stephenfin | currently they can guess a hostname and request that they be booted on that | |
| 15:37:02 | gmann | yeah for project admin, policy allow | |
| 15:37:11 | sean-k-mooney | stephenfin: ya and the filter will prevent it | |
| 15:37:17 | sean-k-mooney | if the host is not in there set | |
| 15:37:21 | stephenfin | right, but it didn't before | |
| 15:37:23 | sean-k-mooney | well assuming your using it | |
| 15:37:25 | stephenfin | so that's a change in behavior | |
| 15:37:38 | gmann | or by bribing the system user :) | |
| 15:37:39 | stephenfin | ergo, what do we respond with and does this need a microversion | |
| 15:37:52 | sean-k-mooney | stephenfin: not the aggreate tenatn isolation fitler or placment version would block the boot if isolatio was configured | |
| 15:38:10 | stephenfin | but not if it wasn't | |
| 15:38:18 | sean-k-mooney | correct | |
| 15:38:24 | gmann | for non isolated cloud, it is change in behavior | |
| 15:38:40 | sean-k-mooney | if it was not then even as a normal user you can guess the host by using the AZ:host syntax | |
| 15:39:02 | sean-k-mooney | i dont think we need to do the check on server create | |
| 15:39:14 | sean-k-mooney | we should leave that up to placment/the schduler fileters | |
| 15:39:29 | sean-k-mooney | for /os-hyperviors we shoudl check | |
| 15:39:57 | gmann | but for non isolated cloud, anyone can boot on host if they know host name? | |
| 15:40:09 | sean-k-mooney | with an az yes | |
| 15:40:35 | sean-k-mooney | you can jsut do --avaiablity-zone $az_name:$hostname | |
| 15:40:37 | gmann | but we are restricting in list hypervisors, do not return if no tenant isolation | |
| 15:40:50 | sean-k-mooney | i think --host is admin only? | |
| 15:41:18 | sean-k-mooney | gmann: i was originally suggeting returning all hyperviors if no isolation for what it worth | |
| 15:41:43 | gmann | yeah but with current discussion it seem that is too much info | |
| 15:42:13 | sean-k-mooney | ya it seams to have pivioted | |
| 15:42:22 | stephenfin | sean-k-mooney: '--hypervisor-hostname' is project-admin scoped https://github.com/openstack/nova/blob/master/nova/policies/servers.py#L217 | |
| 15:42:31 | sean-k-mooney | my view on this is its the admins choice to grant project admin to a tenant | |
| 15:42:48 | gmann | IMO, if we restrict hypervisor list then we should do the same for boot instance also otherwise we are opening a loop hole in our API | |
| 15:42:53 | sean-k-mooney | so if they care about restircting the view they shoudl configure isolation | |
| 15:42:58 | sean-k-mooney | if they dont then they dont | |
| 15:43:18 | sean-k-mooney | gmann: we are restricting the hypervior list using the schduler metadta | |
| 15:43:37 | sean-k-mooney | gmann: so if you have isolation configured you get it for free | |
| 15:43:45 | gmann | sean-k-mooney: and what we discussed now is restrict if no tenant isolcation too | |
| 15:43:45 | stephenfin | can we defer this to Xena? | |
| 15:44:01 | stephenfin | this is starting to feel like it warrants its own spec | |
| 15:44:09 | sean-k-mooney | yep so we should keep the consitent | |
| 15:44:09 | gmann | yeah may be we should. | |
| 15:44:21 | gmann | and let discuss in PTG on all cases | |
| 15:44:26 | stephenfin | given the security implications and discussion around API changes | |
| 15:44:30 | sean-k-mooney | either restic both or dont | |
| 15:44:32 | stephenfin | *changes to other APIs | |
| 15:44:44 | sean-k-mooney | when no isolation is configured for the tenant | |
| 15:44:56 | gmann | and we can discuss host info in GET server also for such project admin | |
| 15:45:03 | stephenfin | yeah, I'm in favour of the same behavior for both listing hypervisors and creating servers on a particular hypervisor | |
| 15:45:20 | gmann | yeah, same behavior is needed whatever we agreed to | |
| 15:45:24 | sean-k-mooney | gmann: getting hypervior_hostname is proably valid if you can do the hypervior list | |
| 15:46:02 | gmann | yeah, and i think we return that in PUT/REBUILD server API also which also we can discuss | |
| 15:46:48 | sean-k-mooney | it basicaly come down too this. show project admins be aware of the hypervior that there vms can run on | |
| 15:46:53 | gmann | so 1. we can update the current spec to remove the policy change 2create new spec for Xena and discuss in PTG ? | |
| 15:46:55 | sean-k-mooney | if yes then it should see it on all apis | |
| 15:47:05 | sean-k-mooney | where its relevent | |
| 15:48:01 | gmann | gibi: sean-k-mooney stephenfin ^^ hope it is ok to update spec at this stage as this is to remove the things we agreed to do | |
| 15:48:02 | sean-k-mooney | and then there is the quetion of if it should require tenatn isolation or not | |
| 15:48:08 | gmann | not on adding anything new | |
| 15:48:27 | sean-k-mooney | gmann: we can update specs at any time to reflect reality | |
| 15:48:38 | stephenfin | gmann: Yeah, I'll update the spec and add an item to the PTG to discuss this | |
| 15:48:49 | gmann | +1, thanks | |
| 15:48:50 | sean-k-mooney | gmann: this wont get moved into implemneted anyway | |
| 15:49:00 | gmann | sean-k-mooney: oh why? | |