| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-12 | |||
| 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 | |
| 16:50:46 | sean-k-mooney | i think we need 1 coffee 2 a whiteborad or virtual alternitve and 3 verbal realtime comunication | |
| 16:51:05 | dansmith | yes, I would really like to do this via voice | |
| 16:51:05 | sean-k-mooney | and just fix the bug to fail eailer untile ^ | |
| 16:51:20 | gmann | yeah, +1 on voice call | |
| 16:52:18 | sean-k-mooney | i think the main issue is what keysotn is provideign via this mechanim is not how i woudl expect RBAC to work from other systems i have looked at | |
| 16:52:52 | lbragstad | sean-k-mooney can you give me some example references for how you expect this to work? i'd like to dig into those | |
| 16:54:12 | sean-k-mooney | im not sure i can directly. i was more thinkin of a set of scope privalge delegations rather then 3 indipened types of tokens | |
| 16:55:00 | sean-k-mooney | e.g. i was still expectin git to be possibel to create a singel system token that could be used like the old admin role | |
| 16:55:19 | sean-k-mooney | but that cant be done as far as i can see | |
| 16:55:28 | dansmith | so in kerberos, | |
| 16:55:47 | dansmith | I can use my same account to get a token, an admin token, and I think a token in any group I have access to right? | |
| 16:55:56 | dansmith | it's been a long time for me, but..I think that's right | |
| 16:55:59 | sean-k-mooney | by the way i was thinking of my litel experince with oath2 | |
| 16:56:23 | sean-k-mooney | dansmith: i think so an di was expecting to be able to do something similar | |
| 16:56:35 | dansmith | I would expect that if I have sysadmin powers, I should be able to effectively newgrp my way into any project to make a request as that project, without having to add myself to that project | |
| 16:56:44 | dansmith | sean-k-mooney: right, that's how this should work IMHO | |
| 16:56:57 | dansmith | don't act like you have no affiliation, just allow system admins to have any affiliation they want that makes sense | |
| 16:57:21 | sean-k-mooney | basicaly i was hopeing for an "openstack token issue -type project -id <whatever>" | |
| 16:57:31 | dansmith | EXACTLY | |
| 16:57:38 | dansmith | EFFING EXACTLY what I've been trying to say | |
| 16:58:07 | sean-k-mooney | then my user would still be me for audinging | |
| 16:58:14 | dansmith | EFFING EXACTLY | |
| 16:58:25 | sean-k-mooney | but the project in the contex would be the one that was specifed | |
| 16:58:25 | dansmith | assuming you mean "auditing" :) | |
| 16:58:29 | dansmith | right | |
| 16:58:31 | sean-k-mooney | hehe yes | |
| 16:58:39 | sean-k-mooney | seanspeak is flexible | |
| 16:58:53 | elod | lyarwood: thank you both for checking the release patches and backporting your gate fixing patch! \o/ | |
| 16:58:54 | gmann | but how you handle for multiple project token issue needed | |
| 16:58:55 | dansmith | and I left my decoder ring in the other room | |
| 16:59:22 | dansmith | gmann: not sure what you mean.. when do you ever do one thing as two projects? | |
| 16:59:52 | gmann | i mean as system admin i want multiple project resource to operate | |
| 17:00:15 | sean-k-mooney | in one api call? | |
| 17:00:29 | gmann | no independent | |
| 17:00:33 | lbragstad | gmann like listing all instances in a deployment? | |
| 17:00:41 | dansmith | lbragstad: no that's different | |
| 17:00:51 | gmann | and without storing or passing projct_id in request | |
| 17:00:56 | sean-k-mooney | that we can support directly with a system_admin token | |
| 17:01:01 | dansmith | gmann: you get a token before each call, just like you would in unix: newgrp teamA; do thing; newgrp teamB; do thing | |
| 17:01:03 | gmann | hummm, i think let's do voice call | |
| 17:01:44 | dansmith | ++ voice call :) | |
| 17:02:01 | sean-k-mooney | lbragstad: anyway i hope you see where i was coming form | |
| 17:02:15 | sean-k-mooney | better go work on the last vdpa patch | |
| 17:02:42 | lbragstad | sean-k-mooney yep - i think i get the general idea | |
| 17:06:58 | gmann | dansmith: sean-k-mooney lbragstad added this in ptg etherpad too (L213)- https://etherpad.opendev.org/p/nova-xena-ptg | |
| 17:07:32 | gmann | when we can have voice call before ptg? | |
| 17:08:17 | sean-k-mooney | i would suggest not until after RC1 | |