| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-12 | |||
| 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 | |
| 16:28:34 | dansmith | https://github.com/openstack/nova/blob/ab07507e5cfce6232fef373d07ff92ea704541da/nova/objects/instance_action.py#L56-L63 | |
| 16:28:36 | sean-k-mooney | gmann: that is what im expecting | |
| 16:28:37 | dansmith | gmann: they can't | |
| 16:28:55 | dansmith | gmann: if their project_id is going to be None, they will not be able to create an InstanceAction | |
| 16:29:05 | dansmith | which likely will fail before we even begin the call to stop the instance | |
| 16:29:55 | gmann | ah i see, they fail later even pass the policy... | |
| 16:30:00 | dansmith | right | |
| 16:30:06 | dansmith | this is what I'm saying, | |
| 16:30:15 | dansmith | looots of stuff in nova will not allow (or break) if project_id is None, | |
| 16:30:22 | dansmith | and fixing all of that seems silly to me | |
| 16:30:39 | sean-k-mooney | i just did it with horzon | |
| 16:30:41 | gmann | ah yeah, same case of "POST server" by system | |
| 16:30:42 | dansmith | I'd rather say "no tenant-isolated resource manip if you're a system_admin with no project" | |
| 16:30:46 | sean-k-mooney | it shut down fine | |
| 16:30:50 | dansmith | you have to get a project-scoped token to do those things | |
| 16:30:55 | melwitt | lyarwood++ thanks for getting that all fixed up. will go through and review | |
| 16:31:26 | sean-k-mooney | so i create a vm on my k8s project, remove my user form that proejct and then stoped it from the admin view in horizon | |
| 16:31:47 | lbragstad | sean-k-mooney are you using a system-scoped token though? | |
| 16:31:51 | dansmith | sean-k-mooney: is horizon using a system-scoped token where context.project_id is None? | |
| 16:31:58 | sean-k-mooney | no the old style ones | |
| 16:32:00 | dansmith | because that's the new thing here | |
| 16:32:04 | dansmith | right, so that's not the problem | |
| 16:32:08 | gmann | I do not think Horizon use system scope token | |
| 16:32:13 | gmann | yeah | |
| 16:32:18 | lbragstad | correct - they're still working on it | |
| 16:32:19 | sean-k-mooney | my point is system scoped tokens should work identiclaly to that | |
| 16:32:25 | dansmith | they don't | |
| 16:32:30 | sean-k-mooney | then that a problem | |
| 16:32:39 | gmann | dansmith: i agree on not putting project_id in all such APIs request body | |
| 16:32:39 | dansmith | sean-k-mooney: did you look at the bug? | |
| 16:32:53 | sean-k-mooney | yes and i suspect i know why it does not work | |
| 16:32:56 | dansmith | sean-k-mooney: it's pretty gruesomely obvious with the project_id=None being.. a big deal | |
| 16:33:02 | dansmith | gmann: ++ | |
| 16:33:34 | gmann | yeah, if API operate on project_id form context then system token is not useful | |
| 16:33:46 | sean-k-mooney | yep | |
| 16:33:49 | gmann | which is our most server APIs/action | |
| 16:33:59 | sean-k-mooney | unless we can populate the context in some way | |
| 16:34:17 | gmann | but some of them we might be able to make it work if we use 'id' itself instead of context | |
| 16:34:24 | gmann | like in stop sevrer case, | |
| 16:34:50 | gmann | except POST server, we should be able to fix those right? | |
| 16:34:53 | dansmith | well, I suggested one way is to have a default project id in config that we use for system-scoped tokens, but even still, that's pretty gross | |
| 16:35:13 | sean-k-mooney | i dont like that but maybe | |
| 16:35:18 | dansmith | I don't either | |
| 16:35:25 | gmann | yeah | |