| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-12 | |||
| 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 | |
| 16:35:29 | sean-k-mooney | i would prefer to have a midelware level populatie it | |
| 16:35:34 | dansmith | which is why I'd rather say that you can't dick with an instance as a system admin | |
| 16:35:36 | dansmith | you have to get a token | |
| 16:35:52 | sean-k-mooney | that is why i was suggesting the new token delegation flow | |
| 16:36:04 | dansmith | sean-k-mooney: populate it with what? doesn't matter where it comes from.. if the user doesn't have a project.. you need to fake it or reject | |
| 16:36:06 | sean-k-mooney | e.g. sudo give me a project token | |
| 16:36:11 | dansmith | right | |
| 16:36:21 | dansmith | that is what I think needs to happen | |
| 16:37:23 | gmann | lbragstad: when we said system_id things, does system)id means some project id? or some new logical system ids | |
| 16:37:34 | lbragstad | today? | |
| 16:37:49 | lbragstad | today system means a super special string 'all' | |
| 16:37:54 | gmann | i mean in old design when keystone thought on system_id | |
| 16:38:06 | gmann | instead of 'all' | |
| 16:38:20 | lbragstad | we never had the 'system' construct in the old days? | |
| 16:38:26 | lbragstad | if i'm understanding your question | |
| 16:38:52 | lbragstad | we just used the 'admin' role for everything and didn't evaluate tenancy | |
| 16:39:08 | sean-k-mooney | lbragstad: i think the direction gmann was going was coudl we stash a project id in it | |
| 16:39:14 | gmann | lbragstad: i mean if system_id is supported then what it will be like ? some new project id or a new system id generated | |
| 16:39:24 | lbragstad | oh- ok | |
| 16:39:34 | lbragstad | i *could* be a service ID, in the future | |
| 16:39:37 | gmann | sean-k-mooney: i was thinking like this - context.project_id or context.system_id way ? | |
| 16:39:49 | sean-k-mooney | lbragstad: its ment to be like compute, storage or networking | |
| 16:39:55 | lbragstad | so - i could do something like $ openstack role add --user sean-k-mooney --system compute admin | |
| 16:40:04 | lbragstad | right | |
| 16:40:22 | lbragstad | so - then sean-k-mooney can manage nova, but can't add users to keystone | |
| 16:40:26 | lbragstad | or create public images in glance | |
| 16:40:36 | lbragstad | it would allow us to implementing constrained RBAC | |
| 16:40:39 | dansmith | does that mean system_id holds an actual project, or is system_id something else? | |
| 16:40:47 | lbragstad | system_id could be a service ID | |
| 16:40:51 | lbragstad | but not a project ID | |
| 16:40:52 | dansmith | that seems bad to me, | |
| 16:41:01 | lbragstad | the service ID seems bad? | |
| 16:41:05 | lbragstad | or the project ID seems bad? | |
| 16:41:07 | gmann | yeah but then we lose the concept of system vs project in nova ight? at least if we end up asking giving project token a sysmte role | |
| 16:41:09 | dansmith | because then if I'm going to try to audit "who shut down my instance" and I query for a project matching that ID, there is no project, right? | |
| 16:41:15 | sean-k-mooney | its really jsut a sting as proposed today | |
| 16:41:26 | sean-k-mooney | the porject would also need to have the same string in there policy right | |
| 16:41:53 | sean-k-mooney | e.g. we would have to tag all the compute apis as part of the compute system | |
| 16:41:55 | lbragstad | today - the system scope policies don't understand that concept, but neither does keystone | |