| *** mhen_ is now known as mhen | 02:20 | |
| *** EugenMayer4401809 is now known as EugenMayer440180 | 10:49 | |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit stable/2025.2: fixture: Mock out services, regions https://review.opendev.org/c/openstack/oslo.limit/+/969406 | 12:52 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit stable/2025.2: Handle missing endpoint, region, service https://review.opendev.org/c/openstack/oslo.limit/+/969407 | 12:52 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit master: Fix region query https://review.opendev.org/c/openstack/oslo.limit/+/969413 | 13:11 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit master: Fix region query https://review.opendev.org/c/openstack/oslo.limit/+/969413 | 13:55 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit master: Delay string interpolations at logging calls https://review.opendev.org/c/openstack/oslo.limit/+/969442 | 13:55 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.policy master: Delay string interpolations at logging calls https://review.opendev.org/c/openstack/oslo.policy/+/969448 | 14:03 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.policy master: Delay string interpolations at logging calls https://review.opendev.org/c/openstack/oslo.policy/+/969448 | 14:38 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit master: Delay string interpolations at logging calls https://review.opendev.org/c/openstack/oslo.limit/+/969442 | 14:38 |
| d34dh0r53 | #startmeeting keystone | 15:02 |
| opendevmeet | Meeting started Wed Dec 3 15:02:02 2025 UTC and is due to finish in 60 minutes. The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:02 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:02 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:02 |
| d34dh0r53 | Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct | 15:02 |
| d34dh0r53 | #link https://openinfra.dev/legal/code-of-conduct | 15:02 |
| d34dh0r53 | #topic roll call | 15:02 |
| 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 |
| cardoe | o/ (been a while since I've been able to listen in) | 15:03 |
| gtema | O/ | 15:03 |
| moutazchaara[m] | O/ | 15:05 |
| cardoe | be curious to ask some questions of you folks during the free time | 15:05 |
| moutazchaara[m] | gtema: Hi, [you were right about the token invalidation process as it should be part of the group changes.](https://review.opendev.org/c/openstack/keystone/+/967048/comments/abbdbb21_811d0a29)... (full message at <https://matrix.org/oftc/media/v1/media/download/AUNTxPSWNk-4tZUPaDAx94By_GFKtEcvc6Wi056FxTcCD3MrF-Vvm0ZTtwB8phqVs1jQ1jBhnkMAeQ827lzIUUlCebLN2eCwAG1hdHJpeC5vcmcvYlNqUUVDaVJYd2lvWlF5ZWVlYndvblJv>) | 15:11 |
| gtema | I have seen that. I am this week on the PTO and not really having enough time to review the stuff. Your explanation looks like I was expecting, so it should be correct. Maybe we will have some code review comments, but functionally it should be correct | 15:12 |
| moutazchaara[m] | gtema: np, ok so it make sense. i only found this out while doing manual testing. These scenarios are very hard to cover it with unit tests. Will try to add more coverage in the mean time... | 15:13 |
| gtema | I know, I am not going to insist on the unittests | 15:14 |
| d34dh0r53 | sorry, got pulled away for a minute | 15:15 |
| gtema | all good Dave | 15:16 |
| d34dh0r53 | #topic review past meeting work items | 15:16 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-11-26-15.07.html | 15:16 |
| d34dh0r53 | no action items from the last meeting | 15:16 |
| d34dh0r53 | #topic liaison updates | 15:16 |
| d34dh0r53 | nothing from me | 15:16 |
| gtema | nothing here as well | 15:17 |
| d34dh0r53 | #topic specification OAuth 2.0 (hiromu) | 15:17 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext | 15:17 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability | 15:17 |
| d34dh0r53 | no updates from me on this one | 15:17 |
| d34dh0r53 | #topic specification Secure RBAC (dmendiza) | 15:17 |
| d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:17 |
| d34dh0r53 | 2026.1 Release Timeline | 15:17 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_new_defaults=True | 15:18 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_scope=True | 15:18 |
| d34dh0r53 | I didn't do my bespoke dmendiza ping | 15:18 |
| gtema | oh lol | 15:18 |
| cardoe | So that OAuth 2.0 parts just seem tests? | 15:22 |
| gtema | yes, should be | 15:24 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit stable/2025.2: fixture: Mock out services, regions https://review.opendev.org/c/openstack/oslo.limit/+/969406 | 15:26 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit stable/2025.2: Handle missing endpoint, region, service https://review.opendev.org/c/openstack/oslo.limit/+/969407 | 15:26 |
| cardoe | okay if I ask questions? | 15:27 |
| d34dh0r53 | Yeah, the OAuth 2.0 is tests that are blocked waiting on tacker | 15:27 |
| d34dh0r53 | cardoe: please do | 15:27 |
| cardoe | So I previously mentioned I'm working with OIDC and with the keystone-ng work I just wanted to see if my approach to things was lining up with a use case. | 15:28 |
| gtema | cool | 15:29 |
| cardoe | So we've got folks that'll be assigned into different groups on the identity system and they'll get a groups claim for those groups. | 15:29 |
| cardoe | I also want to have a good flow for device auth (for the CLI) but I also need machine authentication and that's one place where things are a little gross. | 15:30 |
| gtema | the rust cli (osc) does support the cli flow | 15:30 |
| cardoe | link? | 15:31 |
| gtema | the machine access is to be solved with service accounts, but in the meanwhile you can use jwt auth | 15:31 |
| gtema | https://github.com/gtema/openstack/ | 15:31 |
| cardoe | I've attempted to use v3oidcdeviceauthz but I use mnaser's websso plugin that I previously suggested we merge in. | 15:32 |
| gtema | I also started updating docs for that - i.e. https://openstack-experimental.github.io/keystone/federation/keycloak.html | 15:32 |
| gtema | the rust cli also support the websso plugin | 15:32 |
| cardoe | We'll be getting websso into gophercloud soon as well. | 15:33 |
| cardoe | So you think I should make a static account and then map the OIDC to it with client credentials? | 15:33 |
| gtema | from my pov this is a no-go. I mean gophercloud itself is ok, but you can't have this in the TF or anything without a human attached | 15:34 |
| gtema | which credentials do you mean? | 15:34 |
| cardoe | other terraform providers have an option for web client auth | 15:34 |
| cardoe | OIDC client credentials | 15:34 |
| cardoe | As far as keycloak, I'd really hope we test against something other than keycloak. There's a number of keycloak-isms that I've tried to battle in keystone today. | 15:35 |
| gtema | hmm, okay | 15:35 |
| mnaser | we (historically) have told people to use app creds if they want to use terraform or whatnot | 15:35 |
| gtema | wrt keycloak - my docs describe the okta as well | 15:35 |
| gtema | and I am willing to add that for others (like Entra, etc), just need to find whether others offer dev-based accounts | 15:36 |
| cardoe | Yeah making a service account and using app creds is what we do today. | 15:36 |
| gtema | mnaser - that is also my "perception" right now | 15:36 |
| cardoe | OIDC users can use app creds as well but they stop working once the expiration hits | 15:36 |
| cardoe | gtema: dex is probably an easy test as well. | 15:37 |
| gtema | cardoe - under service account I really mean service account - not a regular user with just the jwt login | 15:37 |
| gtema | yeah, right, will look at dex soon | 15:37 |
| cardoe | gtema: explain the service account... in keystone or you're saying in keycloak/etc? | 15:37 |
| gtema | maybe even tomorrow - I am adding the "enabled" flag to idp and mapping in the v4 now and will check how complex it would be to add dex functests | 15:38 |
| cardoe | So the last item is really the projects and how to map it all out. | 15:38 |
| mnaser | we have built this gross use case once for a customer lol - https://vexxhost.github.io/atmosphere/user/auth.html#using-external-token-from-identity-provider | 15:38 |
| cardoe | There's a want so that all the project_ids are identical across the different regions. | 15:39 |
| gtema | cardoe - I was briefly describing this during the summit and also during the ptg. Conceptually this is a new type of account that can only auth using the jwt and has the logic similar to appcreds (binds to scopes with roles) and certain additional protection | 15:39 |
| cardoe | So I've got a global keystone that's really just my official project store and group mapping. | 15:39 |
| cardoe | gtema: ah okay. yeah I missed that session cause I was triple booked :/ | 15:39 |
| gtema | wrt project_id - just yesterday I was writing here that we can extend project creation api with specifying the id upon creation in v4 | 15:40 |
| cardoe | then regional keystones and have a custom auth plugin that's really just grabbing the projects so that they're in scope during the mapping time to creaet them | 15:41 |
| cardoe | Could we not allow project_id in v3 for a specific permission? | 15:42 |
| cardoe | I think domain_id can be set on a domain creation for a permission? | 15:42 |
| gtema | i don't think it is possible now | 15:43 |
| gtema | with global and regional keystones you also do not have the same user_id | 15:43 |
| gtema | well, the unique_id is same, but i.e. for nova/neutron it is still different | 15:44 |
| cardoe | So dealing with OpenStack Helm | 15:44 |
| cardoe | I've tried to get the PTL to split up the service accounts... he's done nova, cinder, and neutron but a bit different than my goal. | 15:45 |
| cardoe | My goal was each part of the service used its own... like nova-conductor vs nova-api | 15:45 |
| cardoe | Since I've got a keystone in each region, the different users aren't really an issue... but for OIDC I'm using the OIDC sub for the user_id in mapping so its consistent | 15:46 |
| gtema | should we maybe try to get a sync call to discuss on that? it is not a tiny thing for typing | 15:46 |
| gtema | I also want to understand how people are thinking to approach the multiregional keystone - I have too many ? in my head | 15:47 |
| cardoe | sure thing. I'm happy to help. | 15:48 |
| cardoe | I just want an easy setup that follows along patterns that are in the goals of the project. | 15:48 |
| cardoe | Don't wanna go off on my own thing | 15:49 |
| gtema | I was even thinking into something similar to SCIM just for provisioning domains/projects with one central keystone managing that and those pushing this info to the regions (or pull) | 15:49 |
| gtema | you are right in time - I am gathering the functional requirements to address this properly with ng | 15:49 |
| gtema | sorry Dave Wilde (d34dh0r53) let's go back to the agenda to finish it quickly | 15:51 |
| gtema | and we can continue chatting afterwards | 15:51 |
| d34dh0r53 | ack, I was just about to jump in | 15:53 |
| d34dh0r53 | next topic | 15:53 |
| d34dh0r53 | #topic specification Secuirty Compliance Testing (dmendiza) | 15:53 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/devstack/+/957969 | 15:53 |
| d34dh0r53 | I don't think dmendiza is around | 15:53 |
| d34dh0r53 | #topic specification OpenAPI support (gtema) | 15:53 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone | 15:54 |
| gtema | nothing on that | 15:54 |
| d34dh0r53 | #topic open discussion | 15:55 |
| stanislav-z | do you review new bugs later? or now is the time? | 15:56 |
| cardoe | mnaser: just looked at your link... that's exactly what we had to do.. | 15:56 |
| d34dh0r53 | we're about to do that Stanislav Zaprudskiy | 15:56 |
| d34dh0r53 | #topic bug review | 15:56 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:56 |
| d34dh0r53 | looks like we have a couple of new bugs for Keystone | 15:57 |
| d34dh0r53 | first up | 15:57 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2131658 | 15:57 |
| gtema | I have responded in them just an hour ago | 15:57 |
| d34dh0r53 | ack, reading that now | 15:57 |
| moutazchaara[m] | d34dh0r53: Seen that response thanks, and i think it can be included in the patch that i'm on. | 15:59 |
| d34dh0r53 | ack, thanks moutaz.chaara | 15:59 |
| d34dh0r53 | next up | 15:59 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2133706 | 15:59 |
| gtema | we touched that during the ptg iirc | 16:00 |
| gtema | it was a coincidence and I do not know how we could resolve that now | 16:00 |
| gtema | the thing is gone now | 16:00 |
| bbobrov | i have an idea | 16:01 |
| bbobrov | we could revert the change for 2025.1 only | 16:01 |
| bbobrov | actually leave the module deleted in 2025.2 and 2026.1 | 16:01 |
| gtema | there was a proposal to backport the migration procedure to 2024.2 | 16:01 |
| bbobrov | 2024.2 is a SLURP release - optional | 16:02 |
| gtema | and 2024.1 is now gone - great | 16:02 |
| bbobrov | the official openstack messaging is that people can skip and upgrade directly from 2024.1 to 2025.1 without any downsides | 16:02 |
| d34dh0r53 | revert from 2025.1 seems reasonable, do you see downsides gtema ? | 16:04 |
| bbobrov | also, 2025.1 is not supposed to run on python3.13 - https://governance.openstack.org/tc/reference/runtimes/2025.1.html | 16:04 |
| bbobrov | only on 3.12 | 16:04 |
| gtema | hmm. okay | 16:04 |
| bbobrov | 3.13 is also not mandatory for 2025.2 - https://governance.openstack.org/tc/reference/runtimes/2025.2.html | 16:05 |
| gtema | https://review.opendev.org/c/openstack/keystone/+/959279 is the one I mentioned above | 16:06 |
| gtema | it was actually into the 2024.1 | 16:06 |
| d34dh0r53 | could we backport that into 2025.1? | 16:07 |
| gtema | we were both unsure in the approach anyway ;-) | 16:08 |
| gtema | but yes, it can | 16:08 |
| gtema | it just need certain runtime for everything to be "migrated" | 16:08 |
| bbobrov | is it really a backport? The patch doesn't seem to be present in the current master. It seems to be a direct commit to a stable branch | 16:10 |
| gtema | right - we were discussing back those days exactly that we commit it directly back to the branch | 16:11 |
| gtema | it SHOULD NOT exist in master | 16:11 |
| bbobrov | so both restoration and migration patches need to be applied to 2025.1, and nothing needs to be done with the rest of releases. | 16:11 |
| bbobrov | (except maybe a removal note moved to 2025.2) | 16:11 |
| gtema | the main point of concern was and stays - this hashing method was marked deprecated 10 years ago. The fact that those are still there means nobody rotated password - this is just purely wrong | 16:12 |
| d34dh0r53 | indeed | 16:13 |
| d34dh0r53 | I'm good with either approach, but I think applying all of the patches to 2025.1 is the best option for long term maintainability | 16:14 |
| gtema | from the maintainability we should not do anything and mark that before upgrading to 2025.1 affected passwords must be rotated | 16:15 |
| bbobrov | keystone deleted a supported hashing mechanism without any warning. | 16:16 |
| gtema | that is the safest and most reasonable approach fmpov | 16:16 |
| gtema | bbobrov - people were warned 10 years ago that the hashing method is doomed | 16:16 |
| bbobrov | gtema: could you point me to the deprecation notice about it in keystone? | 16:16 |
| gtema | I know what you mean, still | 16:16 |
| gtema | it was not such a deprecation how you would expect this, I wasn't with OpenStack back those days. Will try to grep through logs | 16:17 |
| bbobrov | it seems that the notice is OSSN-0081 | 16:19 |
| gtema | see in https://docs.openstack.org/releasenotes/keystone/stein.html "The deprecated option crypt_strength is removed now. It was only useful for sha512_crypt password hashes which has been superseded by more secure hashing implementations." | 16:20 |
| gtema | but your hint to the OSSN is great | 16:21 |
| gtema | anyway - I admit it was a mistake to land deprecation note and dropping in a single release though | 16:22 |
| gtema | just a bad timing | 16:22 |
| d34dh0r53 | poor timing | 16:25 |
| gtema | we could backport the deprecation note to 2024.2 | 16:26 |
| bbobrov | 2024.2 is a slurp release, it is usually skipped | 16:26 |
| gtema | ah damn | 16:26 |
| d34dh0r53 | We could do as bbobrov suggested and just add a release note ensuring that folks rotate their passwords | 16:27 |
| gtema | maybe add this as a pre-upgrade note to 2025.1 | 16:27 |
| bbobrov | that's the problem - there are many people who "own" different users, and running after them convincing them to rotate is time-consuming. | 16:28 |
| gtema | from what we have seen this case usually affects service users and not the regular ones | 16:29 |
| gtema | in the security compliance we can now also enforce password rotation ;-) | 16:29 |
| bbobrov | stanislav-z: it is unclear from the bugreport - does keystone crash with a ValueError or is there a more graceful error handling? | 16:30 |
| gtema | I think users are not able to login anymore, nothing else | 16:31 |
| stanislav-z | it doesn't crash | 16:31 |
| bbobrov | i see a huge traceback in the logs, but don't know what the users got - 401 or 500 | 16:35 |
| gtema | should be 401 - tracebacks are known | 16:35 |
| gtema | we are heavily overtime now, let's come to the end pls | 16:38 |
| gtema | Dave Wilde (d34dh0r53): ?? | 16:44 |
| bbobrov | maybe he decided to end the meeting asynchronously and is already asleep :D | 16:45 |
| gtema | he has a lunch time by now | 16:45 |
| gtema | I think I can't even end the meeting since he started it | 16:45 |
| gtema | but lemme try | 16:46 |
| gtema | #endmeeting | 16:46 |
| opendevmeet | Meeting ended Wed Dec 3 16:46:06 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:46 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-12-03-15.02.html | 16:46 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-12-03-15.02.txt | 16:46 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-12-03-15.02.log.html | 16:46 |
| gtema | wow, it worked | 16:46 |
| gtema | thanks everybody for participation. It was a surprisingly long meeting where last ones were empty | 16:46 |
| d34dh0r53 | sorry | 16:46 |
| d34dh0r53 | yeah, got pulled into another conversation | 16:46 |
| d34dh0r53 | we didn't have any other bugs | 16:47 |
| gtema | good | 16:47 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!