| *** mhen_ is now known as mhen | 02:30 | |
| *** debian is now known as Guest1463 | 12:21 | |
| d34dh0r53 | #startmeeting keystone | 15:01 |
|---|---|---|
| opendevmeet | Meeting started Wed Feb 4 15:01:45 2026 UTC and is due to finish in 60 minutes. The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:01 |
| d34dh0r53 | Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct | 15:01 |
| d34dh0r53 | #link https://openinfra.dev/legal/code-of-conduct | 15:01 |
| d34dh0r53 | #topic roll call | 15:01 |
| gtema | o/ | 15:01 |
| d34dh0r53 | admiyo, bbobrov, crisloma, d34dh0r53, dpar, dstanek, hrybacki, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, ruan_he, wxy, sonuk, vishakha, Ajay, rafaelwe, xek, gmann, zaitcev, reqa, dmendiza[m], dmendiza, mharley, jph, gtema, cardoe, deydra | 15:02 |
| d34dh0r53 | hey gtema | 15:02 |
| gtema | hey hey. I was in the train to FOSDEM on friday and not sure you got my reply | 15:02 |
| * d34dh0r53 is working on a bespoke artisan ping for dmendiza | 15:02 | |
| d34dh0r53 | gtema: yeah, I saw it, no worries | 15:03 |
| d34dh0r53 | #topic review past meeting work items | 15:05 |
| gtema | are we alone? | 15:05 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-01-14-15.04.html | 15:05 |
| d34dh0r53 | Yeah, I think so | 15:06 |
| d34dh0r53 | no action items from last week | 15:06 |
| gtema | uhm, makes no sense to make a meeting in full form I guess | 15:06 |
| dmendiza[m] | lmao, appreciate the artisan ping | 15:06 |
| d34dh0r53 | lol | 15:06 |
| gtema | oh nice :) | 15:07 |
| d34dh0r53 | #topic liaison updates | 15:07 |
| d34dh0r53 | just going to continue quickly for the logs since I started the meeting | 15:08 |
| d34dh0r53 | nothing from me | 15:08 |
| gtema | nothing on my side either | 15:08 |
| d34dh0r53 | #topic specification Secure RBAC (dmendiza) | 15:08 |
| d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:08 |
| d34dh0r53 | 2026.1 Release Timeline | 15:08 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_new_defaults=True | 15:08 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_scope=True | 15:08 |
| dmendiza[m] | Yeahhhhh, I haven't done much upstreaming lately 😅 | 15:09 |
| dmendiza[m] | New year's resolution not going great. | 15:09 |
| gtema | I'm so sorry for you | 15:09 |
| d34dh0r53 | no worries, thanks dmendiza | 15:11 |
| d34dh0r53 | #topic specification Secuirty Compliance Testing (dmendiza) | 15:11 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/devstack/+/957969 | 15:11 |
| dmendiza[m] | Same same | 15:12 |
| dmendiza[m] | I need to bring back Upstream Fridays | 15:12 |
| d34dh0r53 | 👍 | 15:13 |
| d34dh0r53 | #topic specification OpenAPI support (gtema) | 15:13 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone | 15:13 |
| gtema | no changes on that particular side | 15:14 |
| gtema | Maybe I should drop it from the agenda since amount of changes is very low recently | 15:14 |
| d34dh0r53 | ack, how much is there left to do? | 15:15 |
| gtema | well, I was never starting to work on the oauth2 side and some other of the very esoteric parts | 15:15 |
| gtema | from the basic functionality pretty much everything is covered | 15:16 |
| gtema | Sadly I needed to rollback OpenAPI rendering for the docs since python ecosystem broke again | 15:16 |
| d34dh0r53 | yeah, that's a bummer | 15:18 |
| d34dh0r53 | I'll take it off of the weekly agenda, we can re-add later if needed | 15:18 |
| gtema | maybe I find time to fix it again, but lets see. | 15:18 |
| gtema | Ok, will remove it for now | 15:18 |
| d34dh0r53 | #topic keystone-rs | 15:19 |
| d34dh0r53 | #link https://github.com/openstack-experimental/keystone | 15:19 |
| gtema | that one is big :) | 15:19 |
| gtema | 1) I started working on adding service accounts (basically a nonlocal user) | 15:19 |
| gtema | it required to add a new user_option to be able to clearly identify based on the datamodel that we have now | 15:20 |
| gtema | 2. at FOSDEM had a very fruitful discussion with jpevrard and got new crazy idea how we can improve service-to-service communication based on the mTLS (but in a manageable way) | 15:21 |
| gtema | so that the same mechanism can be also used by the users | 15:21 |
| gtema | This marks for me OpenStack landing in the zero-trust era fully | 15:22 |
| gtema | and the same method can be used for the user workload authentication (VM started by nova can authenticate to keystone) | 15:22 |
| gtema | I am currently trying to write down all thought on that drawing pictures so that we can discuss it in a wider round | 15:22 |
| gtema | 3. preparing the kubernetes token review exchange, but that is technically even obsolete by the previous thing. Still I make sense to implement it as well | 15:23 |
| gtema | so far that's it | 15:24 |
| d34dh0r53 | wow, awesome | 15:24 |
| gtema | our discussion from recently - how services communicate with keystone (passwords, appcreds, scopes, etc) are all covered by this idea | 15:25 |
| gtema | and it is also a prerequisite for implementing better confidential VMs on OpenStack | 15:25 |
| d34dh0r53 | s/passwords,appcreds,scopes,etc/mtls/g or is it a different layer? | 15:26 |
| gtema | this all belongs together | 15:27 |
| cardoe | Kubernetes Token Review would be a +1 from me. We run our OpenStack in k8s. And would love if each service used its k8s service account. | 15:27 |
| d34dh0r53 | Yeah, that's also a +1 from us | 15:27 |
| gtema | I mean that use of mtls helps us to solve the problem of hardcoding credentials between services and struggles of using appcreds due to need of system scope | 15:27 |
| d34dh0r53 | Yeah, I wonder how much work it will be for the service accounts to implement mtls | 15:28 |
| d34dh0r53 | err, services | 15:28 |
| gtema | lemme bring everything to the e-paper and we can discuss it. | 15:28 |
| cardoe | We're using trust-manager from cert-manager for doing the CA and TLS certs right now afaik. | 15:29 |
| cardoe | I've gotta jump into a video call in 1 minute but I just wanted to drop an issue I've seen recently. | 15:29 |
| gtema | we support mtls already now, but it is so unflexible | 15:29 |
| cardoe | https://launchpad.net/bugs/2139467 and https://review.opendev.org/c/openstack/keystone/+/975342 is the patch (I need to fix a pep8 issue) | 15:29 |
| gtema | ack, cardoe, will look at it | 15:30 |
| opendevreview | Doug Goldstein proposed openstack/keystone master: avoid crash with federated tokens and fernet https://review.opendev.org/c/openstack/keystone/+/975342 | 15:30 |
| cardoe | master skyline causes keystone to crash when using any federation | 15:31 |
| gtema | :) | 15:32 |
| d34dh0r53 | ack, let's move on to bug review then since we bled into | 15:33 |
| d34dh0r53 | #topic open discussion | 15:33 |
| d34dh0r53 | #topic bug review | 15:33 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:33 |
| d34dh0r53 | several new keystone bugs, starting from the top which is the one we just discussed | 15:33 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2139467 | 15:34 |
| d34dh0r53 | we'll review ASAP cardoe | 15:34 |
| d34dh0r53 | next up | 15:34 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2139235 | 15:34 |
| d34dh0r53 | looks like we need to clean up some eventlet code in python-keystoneclient | 15:35 |
| gtema | I've seen we use keystoneclient in the keystonemiddleware. It does not look good from it's deprecation pov and we would been to address this as well | 15:37 |
| d34dh0r53 | Yeah, we really need to get on with deprecating it | 15:37 |
| d34dh0r53 | next up | 15:39 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2138725 | 15:39 |
| d34dh0r53 | This is something we should fix, not necessarily backport though | 15:41 |
| d34dh0r53 | next up | 15:41 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2138545 | 15:41 |
| d34dh0r53 | Yep, we need to fix this as well | 15:42 |
| d34dh0r53 | Lot's of good keystone bugs for upstream Friday ;-) | 15:43 |
| d34dh0r53 | #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 | 15:43 |
| gtema | :) | 15:43 |
| d34dh0r53 | no bugs in keystoneclient other than what we just talked about | 15:43 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 | 15:43 |
| d34dh0r53 | keystoneauth is good to go | 15:44 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 | 15:44 |
| d34dh0r53 | one new bug in keystonemiddleware | 15:44 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystonemiddleware/+bug/2138528 | 15:45 |
| d34dh0r53 | we need to kill this code | 15:45 |
| gtema | yeah, right. We need to kill a lot of code ;-) | 15:45 |
| d34dh0r53 | indeed | 15:45 |
| d34dh0r53 | next up | 15:46 |
| d34dh0r53 | #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 | 15:46 |
| d34dh0r53 | nothing new in pycadf | 15:46 |
| d34dh0r53 | #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 | 15:46 |
| d34dh0r53 | nor in ldappool | 15:46 |
| d34dh0r53 | #topic conclusion | 15:46 |
| d34dh0r53 | Thanks folks! | 15:47 |
| gtema | cool. This friday I am here for the reviewathon | 15:47 |
| d34dh0r53 | cool, see you then | 15:47 |
| d34dh0r53 | #endmeeting | 15:47 |
| opendevmeet | Meeting ended Wed Feb 4 15:47:46 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:47 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-02-04-15.01.html | 15:47 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-02-04-15.01.txt | 15:47 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-02-04-15.01.log.html | 15:47 |
| gtema | see ya guys | 15:48 |
| opendevreview | David Wilde proposed openstack/python-keystoneclient master: Remove eventlet support from cms module https://review.opendev.org/c/openstack/python-keystoneclient/+/975650 | 15:59 |
| opendevreview | Grzegorz Grasza proposed openstack/keystonemiddleware master: Remove ec2_token and s3_token middleware https://review.opendev.org/c/openstack/keystonemiddleware/+/975293 | 16:03 |
| *** croeland1 is now known as croelandt | 16:15 | |
| andrewbogott__ | gtema, d34dh0r53, can you assist me with https://bugs.launchpad.net/keystone/+bug/2140354? I imagine I have something going on in my ldap schema that you didn't anticipate. | 17:08 |
| gtema | :) | 17:08 |
| gtema | actually enabled is a must. I would rather say it is not a schema issue but your ldap configuration. I barely remember there was some other issue with the enabled flag in ldap | 17:10 |
| gtema | maybe there is a misconfiguration on your side that went unnoticed till now | 17:11 |
| andrewbogott__ | Typically I would consider a new schema requirement that breaks an existing deployment to be a regression, do you disagree? | 17:11 |
| gtema | strongly - when a bug is fixed it is not a regression | 17:12 |
| andrewbogott__ | ok... what bug is now fixed? | 17:12 |
| gtema | I don't mean a certain bug fix in this particular case - it is a general statment | 17:12 |
| gtema | https://docs.openstack.org/api-ref/identity/v3/index.html#show-user-details says the 'enabled' field is not optional and must be returned. Now schema enforces this | 17:13 |
| gtema | I am not an ldap expert, but do you set the [ldap].user_enabled_attribute and/or [ldap]user_enabled_default in the config? Maybe this is missing? The point is that 'enabled' is far more than a simply stupid parameter, half of the security protections in keystone are relying on it | 17:16 |
| andrewbogott__ | the code in keystone/identity/backends/ldap/core.py has an interesting if/elif section which, if neither condition is traversed, fails to set 'enabled' on the user object. | 17:17 |
| andrewbogott__ | https://review.opendev.org/c/openstack/keystone/+/958205/5/keystone/identity/backends/ldap/core.py | 17:17 |
| andrewbogott__ | so it seems we need a fix there to cover that case | 17:17 |
| andrewbogott__ | (that case being the one where all related keystone settings are left as default) | 17:18 |
| gtema | defaults are never good. Imagine you set the user to disabled in the ldap, but keystone does not see it properly (i.e. named differently) - the user will be eventually still able to continue using keystone | 17:18 |
| andrewbogott__ | (which seems like a kind of reasonable case) | 17:18 |
| andrewbogott__ | well -- even so this breakage is an extremely weird place. If we're going to reject ambiguous ldap records it needs to be on loading. | 17:18 |
| gtema | can you check whether https://review.opendev.org/c/openstack/keystone/+/972077 is affecting you | 17:20 |
| gtema | or https://review.opendev.org/c/openstack/keystone/+/958205 | 17:20 |
| andrewbogott__ | that second one is the same patch i just pasted above :) But yes, let me add some debug lines and see what we're actually getting from the ldap server. | 17:21 |
| gtema | ah ok, sorry | 17:22 |
| andrewbogott__ | yep, as I suspected, kind is never 'enabled'. I take that to mean that my ldap records simply don't have an 'enabled' setting. | 17:28 |
| gtema | perhaps | 17:29 |
| andrewbogott__ | gtema: I'm having a moment of disorientation. I'm trying to dig through the code that handles the ldap config and the mapping of the 'enabled' flag and I can't find any code in the keystone tree that checks user_enabled_attribute. Is it possible that that was simply never implemented? Or am I missing some oblique uses of that flag? | 18:41 |
| gtema | as said, I am not an ldap user and therefore this code is also not very famillar with the code. @xek should know better, but he is most likely done for today | 18:43 |
| andrewbogott__ | fair | 18:46 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!