| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-12 | |||
| 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? | |
| 16:26:02 | sean-k-mooney | no it should be a 200 | |
| 16:26:04 | gmann | with new default project_id is compared for all | |
| 16:26:08 | dansmith | the action has a project_id, I'm looking to see where we get it from, but normally it's context | |
| 16:26:14 | dansmith | because it's the person doing the action | |
| 16:26:21 | dansmith | so that would mean system_admin has to be refused | |
| 16:26:49 | gmann | system admin case there is no proejct id so would not be compared | |
| 16:27:05 | dansmith | which means they can't shut down an instance | |
| 16:27:05 | gmann | i mean system admin power for all projects | |
| 16:27:12 | gmann | they can | |
| 16:27:45 | sean-k-mooney | im going to chefck it now | |
| 16:28:11 | gmann | i mean with our current default policy, system admin can stop any instance, project member/admin can stop their own instance | |