| *** dasm|off is now known as dasm | 13:04 | |
| dansmith | gmann: I just had a thought on the rbac stuff | 14:19 |
|---|---|---|
| dansmith | gmann: for something like nova, do we really want to *remove* scope_types, or just set them all to 'project'? | 14:19 |
| dansmith | if we could potentially have system scoped tokens in the system, we want to 403 those all the time, but I'm not sure what the default is | 14:20 |
| dansmith | like, I'm not sure if it's better to enable scope checking and have everything require project, or disable scope checking and/or remove scope_types entirely | 14:20 |
| *** diablo_rojo is now known as Guest3525 | 14:43 | |
| *** vhari_ is now known as help | 15:18 | |
| *** help is now known as Guest3531 | 15:19 | |
| *** vhari is now known as Guest3536 | 15:32 | |
| *** Guest3531 is now known as vhari | 15:32 | |
| *** diablo_rojo__ is now known as diablo_rojo | 15:54 | |
| *** diablo_rojo is now known as Guest3544 | 17:40 | |
| gmann | dansmith: if policy rule does not have scope_type then oslo policy just ignore the scope checks and it will pass even system scoped is used for project scoped policy with right personas. | 18:05 |
| dansmith | gmann: ack, so is the better move to just convert everything to project? | 18:05 |
| gmann | dansmith: slaweq : the only benefits of keeping scope_type in policy is if in future we want to add system scope there. | 18:06 |
| dansmith | I dunno, | 18:06 |
| dansmith | if people might be using system scope for ironic or something similar, | 18:06 |
| dansmith | and they try to show up with a system scoped token to nova, things will break in weird ways, like trying to create an instance action record | 18:07 |
| dansmith | but if we have scope_types=project, then we'll just 403 them immediately, right? | 18:07 |
| gmann | dansmith: only concern for converting everything to project scoped is it will break if operator system scoped token like if they are using ironic scoped token in same deployment. why nova fail for scope things even nova does not ship scope feature. | 18:07 |
| gmann | dansmith: and if we do not have scope_type at all then nova will continue working for such case also | 18:08 |
| dansmith | nova will work for creating a flavor with a system scoped token,m | 18:08 |
| dansmith | but it will fail in the middle of an action for something like reboot with a 500 right? | 18:08 |
| gmann | dansmith: no, even in flavor also if we make everything as project scoped then it will fail | 18:09 |
| dansmith | right, | 18:09 |
| dansmith | I'm saying if we remove scope_types completely, | 18:09 |
| dansmith | a system scoped token will still work to create a flavor, | 18:09 |
| gmann | ohk | 18:09 |
| dansmith | but will fail with 500 (or some other very confusing database-looking error like "project_id column cannot be NULL") if you try to reboot an instance | 18:10 |
| dansmith | but if we leave everything as =project, | 18:10 |
| gmann | ah you mean system token as they do not have project id, | 18:10 |
| gmann | yeah | 18:10 |
| dansmith | then any time you try to use a system scoped token you'll get 403 | 18:10 |
| gmann | good point to fail early and with right one | 18:10 |
| gmann | right error | 18:10 |
| dansmith | right | 18:10 |
| gmann | because from keystone perspective now, unscoped token is not project scoped by default | 18:11 |
| *** akahat|ruck is now known as akahat|out | 18:11 | |
| dansmith | they _are_ project-scoped today no? | 18:12 |
| dansmith | I thought there was no such thing as an unscoped token | 18:12 |
| gmann | I mean from perspective of system scoped with no project id and project scoped with project id. unscoped one not sure have project id or not | 18:13 |
| dansmith | I thought all tokens were project-scoped today | 18:13 |
| gmann | previously it was i think long back. I remember the tempest change. | 18:13 |
| gmann | you mean by default? tempest make it by default explicitly not sure if keystone has token default to project ? | 18:14 |
| gmann | knikolla: dmendiza[m] ^^? | 18:14 |
| dansmith | I thought they were all project by default | 18:14 |
| dansmith | even if not, if you've got scoping turned on (or whatever) and are using it in some of your services (i.e. ironic) then you'd turn on scope checking in nova, to make sure nobody showed up with a non-project scoped token | 18:14 |
| gmann | yeah | 18:14 |
| gmann | I agree on making everything project scoped but we should make enforce_scope enable by default at the same time when we enable new default by default | 18:15 |
| gmann | dansmith: and keep enforce_scope configurable (enable by default per service ) or at the end we want to remove it like what we initially planned? | 18:16 |
| gmann | not having that configurable seems less confusion to operator | 18:16 |
| dansmith | I guess my point is, I think that if all rules are scope=project then enforce_scope is effectively a no-op for people today, except that it would catch system scope accidents | 18:17 |
| dansmith | and if so, then sure enable by default | 18:17 |
| gmann | yeah, it is better to let it go away all together for 1. service will keep scope like ironic 2. services will have scope to single scoped token there it does not matter | 18:19 |
| gmann | dansmith: let me update the patch. and I will send it on ML also to notify and review from projects. | 18:21 |
| dansmith | it would be nice if we could get an answer from keystone people, but yeah, sounds good | 18:21 |
| gmann | yeah, let's see when knikolla or dmendiza[m] can answer meanwhile I will update it with keeping scope_type as project | 18:23 |
| gmann | I will work on nova WIP changes in parallel so that we can catch if something we missed or need to change in goal documents | 18:23 |
| dansmith | gmann: I was going to do the nova scope-ectomy this morning when I asked | 18:24 |
| dansmith | I'll s/system/project/ and see what happens | 18:24 |
| gmann | dansmith: ok, main part of we need to update unit test a lot for those. and some base rule change | 18:25 |
| dansmith | yeah | 18:26 |
| dansmith | *only* 122 unit fails | 18:35 |
| knikolla | there is the concept of an unscoped token already https://docs.openstack.org/keystone/latest/admin/tokens-overview.html#authorization-scopes | 18:57 |
| opendevreview | Ghanshyam proposed openstack/governance master: Updating the RBAC goal as per new direction in zed cycle https://review.opendev.org/c/openstack/governance/+/847418 | 18:58 |
| knikolla | this is what a user gets when they initially authenticate with keystone, before scoping to a project | 18:58 |
| gmann | dansmith: slaweq ^^ updated document please check | 18:58 |
| gmann | knikolla: ok and that unscoped token will not have project_id ? | 18:58 |
| knikolla | user -> auth unscoped -> query project list -> scope to project | 18:58 |
| dansmith | knikolla: but does anyone show up to nova with an unscoped token ever? | 18:58 |
| knikolla | no, because an unscoped token doesn't have a catalog | 18:59 |
| dansmith | right okay | 18:59 |
| knikolla | i guess they could try to feed that token into nova manually, but with the current way that policy works, it would be rejected (no role, no project). | 19:00 |
| gmann | ok, then scoping policy to 'project' explicitly is right way | 19:00 |
| knikolla | so nova is backtracking from system scope if i skimmed the above discussion correctly? | 19:01 |
| dansmith | we're recommending it for almost everyone | 19:02 |
| gmann | knikolla: as we are not give scope implementation/feature from nova or other services, we were discussing these option 1. remove the scope_type itself so oslo policy will not do the scope check 2. scope everything to project | 19:02 |
| dansmith | gmann has an update to the goal proposed which summarizes | 19:02 |
| gmann | yeah | 19:02 |
| gmann | knikolla: also please check from keystone perspective that removing the scope implementation from keystone policy is ok and scope everything in keystone also to 'project' or 'domain' (basically remove the scope which break heat create stack etc)? this section https://review.opendev.org/c/openstack/governance/+/847418/3/goals/selected/consistent-and-secure-rbac.rst#216 | 19:04 |
| dansmith | gmann: I thought we said keep it optionally for keystone? | 19:05 |
| dansmith | so that you could separate your system admins in keystone from your nova/project admins | 19:05 |
| gmann | dansmith: I rethink on that and realized that if we keep in keystone then heat stack will be broken for same reason of requiring two scoped token | 19:05 |
| dansmith | if they have users in their stack you mean | 19:06 |
| dansmith | is that common? | 19:06 |
| gmann | if they create new users or so | 19:06 |
| gmann | if we keep scope things in keystone then the need system or domain scoped token to create user in keystone and then project scoped token to do nova/neutron things | 19:08 |
| knikolla | I fully agree that we should focus on the project level personas and defer scoping discussions. I fear that fully backtracking on it is going to cause unnecessary work right now and defer work on those project level personas. | 19:08 |
| dansmith | knikolla: backtrack on what specifically? | 19:08 |
| knikolla | "removing the scope implementation from keystone policy is ok" | 19:09 |
| dansmith | doesn't keystone still have scope checks in the rules? | 19:09 |
| dansmith | *in the check strings | 19:11 |
| dansmith | *in the check strings | 19:11 |
| gmann | dansmith: yes that is there which we need to update | 19:11 |
| dansmith | right, so that has to go in order to use the persona stuff | 19:11 |
| gmann | https://github.com/openstack/keystone/blob/master/keystone/common/policies/base.py#L47 | 19:11 |
| knikolla | ah, reading the spec i understood better. so it's about making sure that keystone works with project scope. While being our choice whether to support system or not, we need to support project. | 19:12 |
| gmann | dansmith: yeah so 1. remove the scope string from check_str 2. make scope_type to 'project' or 'domain' whatever it was before the new scope implementation | 19:12 |
| dansmith | yeah | 19:12 |
| knikolla | gmann: is it go and remove, or is it go and make sure that if it's there, it doesn't break project scope? | 19:13 |
| knikolla | that makes the difference between system scope being optional, and system scope being undesired | 19:13 |
| gmann | knikolla: it will break project scoped for sure, as it has 'system:all' in check_str | 19:13 |
| gmann | knikolla: dansmith in that case we can do keystone scope to both system and project so that project and system scoped token both keep working? | 19:14 |
| dansmith | I guess, not sure what the point of that is, other than just for people that already have it turned on in keystone maybe? | 19:20 |
| knikolla | I'm thinking of a deployment with just Keystone + Ironic (not familiar with what else would be needed, I'm assuming here). | 19:21 |
| gmann | yeah that one, I am not sure of anyone has moved to keystone with scope enable | 19:22 |
| knikolla | Whether they have moved or not, it's a feature that keystone supports for specific deployments, and we can't remove it from our API. | 19:22 |
| knikolla | We'd still support assigning system roles, and getting system scoped tokens, and validating them. | 19:22 |
| gmann | yes that is true. its just change in keystone API | 19:23 |
| gmann | I think adding 'project' in scope_type also everywhere and keep existing scope also will server both purpose 1. continue working for project scoped token 2. work for ironic (any standalone service use scope) + keystone deployment using system scoped or so | 19:25 |
| dansmith | well, hence my thought to leave the system scope as optional in keystone, | 19:29 |
| dansmith | even if you have to say "this is incompatible with heat", which it is today | 19:29 |
| gmann | dansmith: optional you mean disable enforce_scope by default always? | 19:31 |
| knikolla | we could have just had keystonemiddleware inject a dummy/special project id when it encounters a system scoped token | 19:31 |
| knikolla | if we're going back to that anyway, requiring admins to scope to a specific project | 19:31 |
| dansmith | gmann: meaning move it into scope_types, and allow the admin to turn it on or off via enforce_scope, default to off because it's not fully compatible | 19:31 |
| gmann | dansmith: yeah, that is one way. as long we do not enable it by default it should be ok. | 19:32 |
| gmann | and anyone enabling knows it can break heat stack or so | 19:32 |
| *** dasm is now known as dasm|afk | 19:34 | |
| gmann | so basically only change in keystone: 1. remove the scope string from check_str so that with scope check disable everything work for project scoped token as it was previously | 19:34 |
| knikolla | we can't disable scope check entirely because of domain scoped tokens | 19:35 |
| gmann | dansmith: only drawback with this approach is we need to keep enforce_scope in oslo policy forever | 19:35 |
| dansmith | gmann: well, we kinda need to do that anyway don't we? if ironic wants to be able to use it | 19:36 |
| gmann | knikolla: oh so you do that via olso.policy only and controlled by enforce_scope ? | 19:36 |
| knikolla | i don't know? i just assumed it's the same mechanism | 19:36 |
| gmann | dansmith: at some point like 3rd milestone, still we can enable it for ironic also like scope check always and not configurable | 19:37 |
| gmann | enforce_scope is basically the migration to new policy things only | 19:38 |
| knikolla | ah, i see. my initial reaction to "disable scope check everything" took the phrase literally. | 19:39 |
| knikolla | when it's "ignore system scope on everything" | 19:39 |
| gmann | knikolla: yeah, domain scope for the policy it was before system-scope implementation should stay same | 19:40 |
| gmann | knikolla: dansmith for example create user - https://github.com/openstack/keystone/blob/master/keystone/common/policies/user.py#L114 | 19:43 |
| gmann | knikolla: dansmith system and domain scoped was added in this policy and legacy old policy did not have any scope so in this case we should delete both scope rught | 19:43 |
| dansmith | have they already shipped a release where system_scope was allowed? | 19:44 |
| dansmith | if so, I don't think we can just remove it | 19:44 |
| gmann | dansmith: I think yes but disable by default. | 19:45 |
| knikolla | so you're saying to completely remove scope_types? | 19:45 |
| gmann | I think either add the 'project' scope everywhere or keep it same but do not enable it by default anytime. | 19:46 |
| gmann | knikolla: completely removing scope_type is not good for ironic_keystone or the domain scope things you mentioned | 19:46 |
| knikolla | gmann: that's why i keep asking about it, haha. | 19:47 |
| gmann | I like adding project scoped everywhere so it will not break the things but work for every token | 19:47 |
| knikolla | I would really appreciate not breaking how things are right now. And we can't remove system scoped tokens or domain scoped tokens from keystone unless we do a v4 API. | 19:49 |
| knikolla | And if I were to do a v4 API, you would prefer I didn't, lol. | 19:49 |
| gmann | yeah, let's go for that only then. "keystone to add project scope in existing scope_type implementation" | 19:51 |
| gmann | dansmith: knikolla you both ok with this ^^ ? | 19:51 |
| dansmith | sure | 19:51 |
| knikolla | sure, i'm okay with preserving today's behavior and making sure the policies we wrote for a system scope world work without it. | 19:52 |
| gmann | cool, I will update the goal documentation | 19:53 |
| knikolla | But man, that v4 API would be so cool, it'd have blockchains, and AI, and social networks | 19:54 |
| gmann | :) | 19:55 |
| fungi | imagine how many peole will try to cram into the forum sessions for that | 19:58 |
| fungi | like the old jokes we used to make about decoy "quantum" sessions just to draw all the lookie-lous out of where we had productive topics | 19:59 |
| knikolla | we'll get everyone that attends NFTs | 20:00 |
| fungi | and you get an nft, and you get an nft... nfts for everyone! | 20:02 |
| opendevreview | Ghanshyam proposed openstack/governance master: Updating the RBAC goal as per new direction in zed cycle https://review.opendev.org/c/openstack/governance/+/847418 | 20:35 |
| gmann | dansmith: knikolla ^^ added the keystone change details | 20:35 |
| mnaser | i have an instance_extra database filled with `VolumeLimitExceeded: Maximum number of volumes allowed (20) exceeded for quota 'volumes'.` | 20:41 |
| mnaser | sorry, instance_faults* | 20:41 |
| mnaser | is there a way for us to segment actual cloud faults vs user faults? | 20:41 |
| opendevreview | Ghanshyam proposed openstack/governance master: Updating the RBAC goal as per new direction in zed cycle https://review.opendev.org/c/openstack/governance/+/847418 | 21:04 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!