Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-03-12
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
16:42:06 gmann yeah
16:42:13 lbragstad again - i'm talking way down the road
16:42:56 lbragstad but it might be important before we get to that point and realize projects are using system by overloading it with project information
16:43:41 lbragstad dansmith yeah - in that case, you'd need to query the projects and service
16:43:49 lbragstad services*
16:44:11 dansmith lbragstad: well, we call it a project_id, so you just "need to know" that it could be either right?
16:44:40 gmann dansmith: sean-k-mooney why we cannot remove the project_id = context.project_id from here ? https://github.com/openstack/nova/blob/ab07507e5cfce6232fef373d07ff92ea704541da/nova/objects/instance_action.py#L60
16:45:03 gmann at least that will allow action APIs to eb operable form system and keep project_id in instance same as old
16:45:03 lbragstad yeah - so you're saying it could be an actual project_id or a service_id (assuming all that work actually happens in keystone)
16:45:08 dansmith gmann: we have to do it everywhere
16:45:17 dansmith gmann: and, it hides who did the thing
16:45:20 gmann yeah, that is some work we have to do
16:45:45 dansmith gmann: that object is for auditing, and if we just lie about who shut down your instance, that's... like, bad and stuff? :)
16:46:39 gmann dansmith: we can add some specific field of shut_down_by= and 'system admin' if system admin does
16:46:54 dansmith gmann: -2 on that :)
16:47:19 dansmith all of this comes because we have project-scoped resources, and now we have this user that is in "no project"
16:47:20 gmann i mean at some stage we have to consume system admin info in resources DB or so
16:47:32 lbragstad would nova be opposed to a mutually exclusive group for project_id|system_id?
16:47:33 dansmith which is why I think we shouldn't allow you to act on project-scoped resources with out.. some sort of project scope :)
16:48:12 gmann but that shrink the system token use.
16:48:20 gmann or the overall purpose
16:48:51 dansmith why not just give all system admins a single project? we can still use the system-admin part to authorize, but then we have a project_id to account for things
16:49:51 gmann i will say system_id we should add and then do context.project_id or context.system_id
16:50:00 gmann or mutual exclusive as lbragstad mentioned before

Earlier   Later