Posted	Nick	Remark
#openstack-nova - 2021-03-12
16:02:01	dansmith	coming up with a strategy for what to do if a sysadmin does an instance migrate is one thing,
16:02:04	sean-k-mooney	but no one else
16:02:08	gmann	yah domain is in keystone noly afaik
16:02:10	lbragstad	keystone uses them - but it's unclear if other projects will fully adopt them
16:02:12	dansmith	but making sysadmin able to create and snapshot instances, not so much
16:03:49	sean-k-mooney	if i was to summerise. operation that create/consume reousces proably are not easy/desireable to support but other operations that change state of exising resouce may be ok
16:04:09	sean-k-mooney	for system admin that is
16:04:49	dansmith	sean-k-mooney: as a future goal, yeah.. as a short-term bug, probably need to just validate and reject anything related to instances
16:05:08	dansmith	aggregates are fine, service actions are okay, etc
16:05:50	sean-k-mooney	gmann:lbragstad: any of that ^ shocking or concerning to you ?
16:06:11	sean-k-mooney	or was that also what ye were expecting. its more or less where my mind is at too
16:06:22	lbragstad	sorry - catching up
16:06:30	sean-k-mooney	not that i have spent that much time thinking about it
16:06:45	lbragstad	ok - so domains
16:07:12	lbragstad	since domains are containers of projects, i can see a case where calling GET /v2.0/servers with domain-scoped token would yield all servers across all projects within that domain... but,
16:07:39	dansmith	sure
16:07:43	lbragstad	you can also tell keystone to inherit a domain role assignment to all containing projects
16:07:45	gmann	but system admin can also do same right?
16:07:49	lbragstad	in which case, you do that and it works today
16:08:42	lbragstad	and then nova doesn't have to fetch a hierarchy of projects from keystone - at least not right now
16:09:19	dansmith	not sure how that will yield nova showing you all instances in your sub-projects,
16:09:24	dansmith	because we would have to filter for multiples
16:09:41	dansmith	we could do it (hence the sure) but I think we'd need the hierarchy
16:09:55	lbragstad	right - i think so, too
16:10:01	lbragstad	which nova doesn't support today
16:10:04	lbragstad	afaict
16:10:05	dansmith	right
16:10:14	lbragstad	and that might just seem like a lot of extra processing
16:10:17	dansmith	you said "works today" so wanted to clarify
16:10:19	dansmith	yes
16:10:34	sean-k-mooney	did we talk about keystone midelware portentaly being able to provide us with the set of projects
16:10:47	lbragstad	what i meant there was that that same domain-admin could have an inherited role assignment on all containing project (this works today in keystone)
16:11:00	lbragstad	allowing them to get project-scoped tokens for each project within their domain
16:11:01	dansmith	domain admin is really a side thing though, right? unrelated to system_admin and no current focus on supporting it
16:11:39	lbragstad	dansmith correct - imho domain-support is on the back-back-burner
16:11:50	sean-k-mooney	so with keystone domains today you can have full admin on a subset of a cloud right and create falvors and such
16:11:52	dansmith	ack, so back to sean-k-mooney's question about how to handle system admin
16:12:00	gmann	yeah, i am also not so clear on use case of it
16:12:26	lbragstad	so - so for system-scope, here are my thoughts
16:13:13	lbragstad	i was open to leaving it up to the service to determine if they allow system-users to create resources within projects - but it would absolutely require an alternative method for supplying the project_id
16:13:24	lbragstad	(e.g., like what glance does with the owner property in the request body)
16:13:53	dansmith	I just don't think providing a project_id for every operation is reasonable
16:14:05	dansmith	an *alternate* project_id I mean
16:14:13	sean-k-mooney	neutorn added suport for project_id for networks and some other reseouce i htink
16:14:19	lbragstad	my firm opinion is that i think it would be a bad idea if nova, for example, started using fake project ids to continue allowing system-administrators to create servers on behalf of other users
16:15:34	gmann	yeah, we required that for create server on specific host use case but that could be achieving by opening the policy for get hypervisors and project admin or so do it
16:15:43	gmann	lbragstad: is there any plan to support system-ids in system scope token instead of 'all' ? i remember that was original proposal for system scope.
16:15:43	sean-k-mooney	i could maybe see this being done via midelwhere. where keystone alloed a system-admin toek to be create with a project_id
16:15:44	lbragstad	or - if servers could be created under a project called 'system' or something liek that
16:15:47	gmann	or that was dropped ?
16:15:49	openstackgerrit	Lee Yarwood proposed openstack/nova stable/rocky: [stable-only] gate: Pin CEPH_RELEASE to nautilus in LM hook https://review.opendev.org/c/openstack/nova/+/780286
16:15:55	sean-k-mooney	and then we would use that in nova as if it was a poject token
16:16:05	lbragstad	gmann not dropped - just not enough time to implement it
16:16:08	dansmith	maybe this is a dumb question, but if I have sysadmin powers and I want to create an instance for someone, can't I get a project token for that project before I create it?
16:16:10	gmann	i see
16:16:15	sean-k-mooney	lbragstad: basically allow one token type to issuee a lesser scoped token
16:16:17	lbragstad	dansmith yes - exactly
16:16:29	gmann	dansmith: yes
16:16:36	gmann	same way for project user,
16:16:40	dansmith	lbragstad: okay so system-scoped tokens need not be able to create resources directly right?
16:16:42	lbragstad	if you're an admin - you have access to all of keystone's role assignment API
16:16:52	gmann	if they want some system info in their operation then get system token or so..
16:17:08	sean-k-mooney	lbragstad: can you do it with out updateing asignemnt
16:17:28	sean-k-mooney	lbragstad: e.g. can i use a system admin credential to issue a proejct scoped token directly
16:17:38	sean-k-mooney	without assing a rule to myslef in the project
16:17:45	lbragstad	dansmith correct - i think we'd really need to think through the ramifications of doing that consistently if we decided to open that up
16:17:46	sean-k-mooney	*role
16:17:55	lbragstad	sean-k-mooney no
16:18:08	sean-k-mooney	so that would be a non invasive way to do it
16:18:23	lbragstad	but it would bypass keystone's delegation mechanism
16:18:37	sean-k-mooney	just adding proejct member and create a project toeknb does not feel like an improvment over what we have today
16:18:43	dansmith	lbragstad: I would much rather make sure system admins (the people) can get a token to do what they need in a project, vs make every operation take a project (i.e. osc server stop --project $foo)
16:18:49	lbragstad	which may have adverse side-effects on auditing
16:19:04	openstackgerrit	Lee Yarwood proposed openstack/nova stable/queens: [stable-only] gate: Pin CEPH_RELEASE to nautilus in LM hook https://review.opendev.org/c/openstack/nova/+/780287
16:19:16	lyarwood	elod: ack sorry irc dropped, looking now
16:19:27	sean-k-mooney	lbragstad: well im thinki of it kind of like app crentials
16:19:31	lyarwood	elod / melwitt ; https://review.opendev.org/q/I1d029ebe78b16ed2d4345201b515baf3701533d5 - btw that should sort the remaining ceph jobs out
16:19:56	sean-k-mooney	i have a super set of permision acroos all doemains/proejct as a system admin
16:20:05	lbragstad	sean-k-mooney application credentials are currently tied directly to projects and by default prevent you from using them to bypass authorization
16:20:09	sean-k-mooney	so i should be able to create a scoped token of a different type
16:20:24	sean-k-mooney	lbragstad: this would not be a bypsss though
16:20:49	sean-k-mooney	it would be a explict keystoen feature to allow higer privladge tokens ot issue a lower coped token
16:21:12	sean-k-mooney	but it sound like that cant be done with keystone current delegation design
16:21:23	dansmith	sounds like we should figure out what we need to do for W to not return 500 and then have a video conf about this right?
16:21:52	dansmith	i.e. ptg
16:21:53	sean-k-mooney	yep proably or wait for our PMs to say we need to support it
16:22:16	lbragstad	yeah - introducing a new way to delegate authorization makes me nervous without thinking through it over a longer period of time
16:22:31	lbragstad	agree - a video call would help
16:22:39	dansmith	we clearly need to understand what the expected usage pattern is, how that will or won't work and go from there
16:22:56	gmann	yeah
16:23:01	lbragstad	for now though - a system-admin can explicitly give themselves access to a project and do whatever they need to
16:23:02	dansmith	because it seems like there's maybe some confusion here (more than just my ignorance)
16:23:17	sean-k-mooney	lbragstad: right but today they dont have too
16:23:34	sean-k-mooney	lbragstad: i do not need to be a meber of a project as a system admin to stop a vm
16:23:42	dansmith	lbragstad: ack, so cutting off resource create for them makes sense for the 500 case currently
16:24:06	lbragstad	ok- so in that case
16:24:24	lbragstad	if i'm an admin on project `admin` and i use my token to stop a vm in project `foo`
16:24:29	lbragstad	what does nova do with my `admin` project id?
16:25:38	sean-k-mooney	for vm stop we just need the vm uuid but if we look in the logs we likely will log the action as done by the admin project
16:25:53	gmann	so it will be 403 right?

Earlier   Later