| *** zseguin is now known as Guest16914 | 06:31 | |
| opendevreview | Andre Aranha proposed openstack/python-keystoneclient master: Allow specifying project and domain IDs at create time https://review.opendev.org/c/openstack/python-keystoneclient/+/1003519 | 12:10 |
|---|---|---|
| gtema | #startmeeting keystone | 15:03 |
| opendevmeet | Meeting started Wed Sep 2 15:03:55 2026 UTC and is due to finish in 60 minutes. The chair is gtema. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:03 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:03 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:03 |
| gtema | Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct | 15:04 |
| gtema | #link https://openinfra.dev/legal/code-of-conduct | 15:04 |
| gtema | #topic roll call | 15:04 |
| gtema | bbobrov, d34dh0r53, xek, gmann, dmendiza[m], dmendiza, mharley, jph, gtema, cardoe, deydra | 15:04 |
| cardoe | o/ | 15:04 |
| gtema | ehm, not that many | 15:05 |
| dmendiza[m] | 🙋♂️ | 15:06 |
| gtema | oh yeah, looks better | 15:06 |
| moutazchaara[m] | /o | 15:06 |
| gtema | #topic review past meeting work items | 15:06 |
| gtema | #link https://meetings.opendev.org/meetings/keystone/2026 | 15:06 |
| gtema | last meeting was month ago and it was pretty empty, so no actions | 15:07 |
| gtema | #topic liaison updates | 15:07 |
| gtema | I do not have many. We are also in the Feature Freeze | 15:07 |
| gtema | s/many/any | 15:07 |
| d34dh0r53 | o/ sorry, was in a meeting that went long | 15:08 |
| gtema | n.p. Dave Wilde (d34dh0r53) | 15:08 |
| gtema | #topic specification | 15:08 |
| gtema | #topic Secure RBAC (dmendiza) | 15:08 |
| gtema | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:08 |
| gtema | aren't we done with it? | 15:09 |
| dmendiza[m] | I remember there was something pending, but I don't remember what it was? 🤔 | 15:09 |
| gtema | well, most of us need to recall things forgotten during PTO or whatever else was disturbing | 15:10 |
| dmendiza[m] | Yeah, big move for me. Finally at my house, but everything is in chaos. It'll be a few weeks before everything is unpacked and renovation projects are wrapped up. 😅 | 15:11 |
| dmendiza[m] | I'll look through evesdrop and figure out what it was | 15:12 |
| gtema | ok, let's move on | 15:12 |
| gtema | #topic Secuirty Compliance Testing (dmendiza) | 15:12 |
| gtema | #link https://review.opendev.org/c/openstack/devstack/+/957969 | 15:12 |
| dmendiza[m] | Need to dus off the cobwebs from those patches | 15:13 |
| dmendiza[m] | No progress until Indri probably | 15:13 |
| gtema | ok, next up | 15:13 |
| gtema | #topic User Specified Project/User UUIDs (dmendiza, alee) | 15:13 |
| gtema | #link https://review.opendev.org/c/openstack/keystone-specs/+/997320 | 15:13 |
| gtema | I've seen work on specs restarted, that's good | 15:14 |
| gtema | not sure there would be any other updates on that one | 15:15 |
| gtema | next one | 15:15 |
| gtema | #topic Add IP allowlist for users, domains, and projects | 15:15 |
| gtema | #link https://blueprints.launchpad.net/keystone/+spec/keystone-ip-allowlist | 15:16 |
| gtema | #link https://review.opendev.org/c/openstack/keystone/+/985406 | 15:16 |
| gtema | most likely those interested in that topic are not here | 15:16 |
| gtema | I remember I was providing some initial feedback to the spec, later was thinking further about that having a sligtly different idea, but haven't re-checked the spec due to other prios | 15:17 |
| gtema | next | 15:17 |
| gtema | #topic keystone-rs | 15:18 |
| gtema | I am just back from PTO, so not much update here as well | 15:18 |
| gtema | but I have started working on switching the whole control plane of openstack to mTLS switching to JWT tokens | 15:18 |
| gtema | this is a pretty massive one, so I do not expect to end it in next few days ;-) But the plan is fixed and goes good | 15:19 |
| gtema | ok, next one | 15:20 |
| gtema | #topic open discussion | 15:20 |
| cardoe | https://review.opendev.org/c/openstack/keystone/+/979789 is one I want to revisit | 15:20 |
| cardoe | You can denial of service keystone by just running skyline and having federated users. | 15:20 |
| gtema | yeah, I am just unsure we want to grant system scope to federated users | 15:21 |
| cardoe | You already can and it's in the test. | 15:22 |
| cardoe | And I do. | 15:22 |
| gtema | and you crash | 15:22 |
| cardoe | system-scope should be for non-project scoped objects like neutron network segment ranges and nova public flavors. | 15:22 |
| cardoe | I crash with skyline. | 15:22 |
| gtema | we do not have the payload what the change is doing | 15:23 |
| cardoe | ironic uses system-scope for non-project scoped objects already. | 15:23 |
| cardoe | I don't use any local users. | 15:23 |
| gtema | and I think lack of system scope payload for federated users was intentional | 15:23 |
| cardoe | I mean the function has to return a class today. There's a fallout case which returns a None and crashes keystone. | 15:24 |
| cardoe | It should throw an exception of invalid then. | 15:24 |
| gtema | I have no problem with throwing exception or whatever else. To repeat I am not sure we want to support properly system scope for federated users in the token payload | 15:25 |
| cardoe | https://opendev.org/openstack/keystone/src/commit/f4c4b1924356551c3130593bef96a97cb5e83b63/keystone/token/providers/fernet/core.py#L50 is the function I'm referring to. | 15:25 |
| gtema | but the change is explicitly allowing this | 15:26 |
| gtema | I remember what you are referring to | 15:26 |
| cardoe | I don't know why we'd exclude system scope for federated users. | 15:28 |
| cardoe | I don't put my users into keystone and they're federated in. | 15:28 |
| gtema | because it's privileged | 15:29 |
| cardoe | My ironic admins get a system-scope token | 15:29 |
| cardoe | No more privileged than project scoped admin for many projects. | 15:29 |
| gtema | I dislike the whole system-scope idea as a whole | 15:29 |
| gtema | right, and you should not be having project admin, if only things were done correctly | 15:30 |
| gtema | sad that there are no other people with opinions | 15:33 |
| gtema | cardoe, if I recall correctly we were discussing that in the referred method we could (at least as intended) to fallback to the unscoped token. Do you remember details? | 15:35 |
| gtema | I am just really wondering that you say you already use system scope tokens for federated users, what can not really work properly since we do not have this token payload | 15:37 |
| cardoe | I've got a patched keystone. | 15:42 |
| gtema | how cool that we then wonder that things are going differently | 15:43 |
| cardoe | This is just how I'm experimenting. Not what I'm running in prod. | 15:43 |
| cardoe | You've commented on my email on the ML wrt this. | 15:44 |
| gtema | anyway, we need more cores actively present to decide whether we want to allow this payload or not. If not than we would need to go for other solution | 15:44 |
| cardoe | gimme 5 minutes and I'll be back | 15:45 |
| gtema | ok, we go on for now with next topics | 15:45 |
| gtema | #topic bug review | 15:45 |
| gtema | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:46 |
| d34dh0r53 | I'm still not sure which is part of the problem, I see both sides which is why I'm very much in favor of the rip and replace | 15:46 |
| gtema | rip and replace what exactly? the federation or the system scope? | 15:47 |
| gtema | or keystone as whole? | 15:47 |
| gtema | :) | 15:47 |
| gtema | back to bugs | 15:49 |
| gtema | we have 2 bugs in keystone | 15:49 |
| gtema | https://bugs.launchpad.net/keystone/+bug/2165018#link | 15:49 |
| gtema | #link https://bugs.launchpad.net/keystone/+bug/2165018 | 15:49 |
| gtema | and | 15:49 |
| gtema | #link https://bugs.launchpad.net/keystone/+bug/2165143 | 15:49 |
| gtema | I will have a look at the first one to fix the jsonschema | 15:50 |
| gtema | for the other one I need to check, the job is indeed failing since ages, but it's a non-voting one | 15:54 |
| gtema | to be short: other deliverables are not having new public bugs | 15:55 |
| gtema | #topic conclusion | 15:55 |
| chung00lee[m] | Hello. I've reported a bug at https://bugs.launchpad.net/keystone/+bug/2163597 and submitted a patch at https://review.opendev.org/c/openstack/keystone/+/1001033. Could you please take a look when you have a chance? | 15:56 |
| gtema | ack | 15:57 |
| gtema | this is a mine field territory for sure, but let's see | 15:57 |
| gtema | anything else to say, folks? | 15:58 |
| gtema | okay, time is up | 15:59 |
| gtema | thanks for participation | 16:00 |
| gtema | and see you around | 16:00 |
| gtema | #endmeeting | 16:00 |
| opendevmeet | Meeting ended Wed Sep 2 16:00:16 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-09-02-15.03.html | 16:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-09-02-15.03.txt | 16:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-09-02-15.03.log.html | 16:00 |
| cardoe | gtema: sorry I had a 1:1 at the 30 minute mark... I thought it was going to go quickly. | 16:05 |
| gtema | I am at my EOB, but we can still chat a bit | 16:05 |
| cardoe | gtema: so for me conceptually we have resources in different OpenStack projects which are "system" wide. | 16:06 |
| cardoe | For example neutron agents, which can be deleted. They don't belong to a project and never will. | 16:06 |
| cardoe | And they can be edited. | 16:06 |
| cardoe | So that's a cloud admin type persona | 16:06 |
| cardoe | Today neutron lets any project-scoped role:admin operate on those. | 16:06 |
| cardoe | But that just feels wrong from a design. | 16:07 |
| gtema | correct | 16:07 |
| cardoe | So I'm just trying to have the discussion on the ML around the right shape of the problem with the various projects. | 16:07 |
| gtema | same for nova with it's is_admin | 16:07 |
| cardoe | yep | 16:07 |
| cardoe | So just experimentally, I've patched some things to try and have real hands on things for folks when discussing with them. | 16:08 |
| gtema | and since more and more people recognize those problems to use a chance and rethink the whole madness from scratch instead on implementing another workaround how OpenStack used to do for a while | 16:08 |
| gtema | I strongly believe we should not fix system scope, we should evaluate whether we are correct with our authz model | 16:09 |
| cardoe | Ultimately for me in prod however, all my users will be federated. | 16:09 |
| gtema | including root? | 16:09 |
| cardoe | yeah and that'd be good with me too. If you've got some replacement suggestions let's get it on the ML | 16:10 |
| gtema | keystone has the absolute admin as a local user, and I am not sure you can do much about this | 16:10 |
| cardoe | yeah so that's hardcoded in there in the default domain and that'll stay | 16:10 |
| gtema | I don't want to open another shit storm over ML, this is something what should be discussed among interested and dedicated people in PTG | 16:11 |
| cardoe | Sure that works for me. | 16:11 |
| gtema | you know how people react on my "let's rethink" statements over ML | 16:11 |
| gtema | my idea is how I described in keystone-rs update: switch control plane to mTLS so that services do not need dedicated users to talk to each other anymore. Next step is switch to OpenPolicyAgent for policies (as we were presenting last summit). With that OPA can also talk to keystone asking whether user is allowed to this this or that | 16:13 |
| gtema | then we switch to JWT away from fernet | 16:14 |
| gtema | then we should go back introducing project_id to the URLs of the project owned resources | 16:14 |
| gtema | this way we remove authorization binding within tokens and authz can be relieved from scope/role/persona bindings | 16:15 |
| gtema | that's a short story | 16:16 |
| gtema | most can be done out of keystone deliverables | 16:16 |
| gtema | but projects would need to catch up | 16:16 |
| cardoe | Yeah | 16:17 |
| gtema | that's also one of those reasons I am not actively reviewing new features to python keystone. For me we need a strategical switch better yesterday than today | 16:18 |
| gtema | we need big changes, not continuing the workaround path | 16:21 |
| cardoe | I understand. Unfortunately it's the system we've got today. | 16:21 |
| cardoe | I'm happy to review stuff that exists today. | 16:21 |
| gtema | that doesn't help. We have bunch of workarounds left by people who were promising support while fighting for adding new features. Now it is a badly designed code no current core purely understand or "supports". We do not want to accept things we do not commit to | 16:23 |
| gtema | last security vulnerabilities are demoing this problem strongly - we can't close holes just because it is not possible with all those workarounds from every side in every method | 16:24 |
| opendevreview | Merged openstack/keystoneauth master: trivial: Update docs for Adapter.register_conf_options https://review.opendev.org/c/openstack/keystoneauth/+/1003230 | 21:00 |
| opendevreview | Merged openstack/keystonemiddleware master: Drop remaining logic for identity v2 API https://review.opendev.org/c/openstack/keystonemiddleware/+/979376 | 21:58 |
| opendevreview | Merged openstack/keystoneauth master: loading: Accept OptGroup https://review.opendev.org/c/openstack/keystoneauth/+/1003231 | 23:52 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!