| opendevreview | Ade Lee proposed openstack/keystone master: Allow admins to create projects, users and domains with explicit IDs https://review.opendev.org/c/openstack/keystone/+/983441 | 01:43 |
|---|---|---|
| *** ralonsoh is now known as ralonsoh_lunch | 11:23 | |
| *** ralonsoh_lunch is now known as ralonsoh | 12:48 | |
| d34dh0r53 | #startmeeting keystone | 15:02 |
| opendevmeet | Meeting started Wed May 27 15:02:37 2026 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:03 |
| d34dh0r53 | #link https://openinfra.dev/legal/code-of-conduct | 15:03 |
| d34dh0r53 | #topic roll call | 15:03 |
| gtema | o/ | 15:03 |
| 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:03 |
| d34dh0r53 | dmendiza: 👋 | 15:03 |
| d34dh0r53 | #topic review past meeting work items | 15:04 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-05-20-15.05.html | 15:05 |
| d34dh0r53 | nothing to review from last meeting | 15:05 |
| d34dh0r53 | #topic liaison updates | 15:05 |
| d34dh0r53 | nothing from me | 15:05 |
| gtema | neither from me | 15:05 |
| d34dh0r53 | #topic specification Secure RBAC (dmendiza) | 15:06 |
| d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:06 |
| d34dh0r53 | 2026.1 Release Timeline | 15:06 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_new_defaults=True | 15:06 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_scope=True | 15:06 |
| d34dh0r53 | I guess dmendiza isn't around | 15:08 |
| d34dh0r53 | #topic specification Secuirty Compliance Testing (dmendiza) | 15:08 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/devstack/+/957969 | 15:08 |
| d34dh0r53 | #topic keystone-rs | 15:08 |
| d34dh0r53 | #link https://github.com/openstack-experimental/keystone | 15:08 |
| gtema | I have completed rework of the auth to build a ValidatedSecurityContext | 15:09 |
| gtema | that gives possibility to authenticate using token, SPIFFE mTLS, etc without trying to "map" those other methods to the traditional token type | 15:09 |
| gtema | with this I have now possibility to send requests with mTLS and map them to identities | 15:10 |
| gtema | the storage for those bindings is raft | 15:10 |
| gtema | what is missing for that to be really useful is a real admin interface which gives possibility to manage mappings in a trusted environment (bootstrap) | 15:11 |
| gtema | so for that I added the admin listener which is based on the UDS and also uses SPIFFE for authentication | 15:11 |
| gtema | with the difference that in the config it is possible to specify the SVID (this is how the ID of spiffe is called). | 15:12 |
| gtema | this is the mapped in the context into the "admin" user and it allows bootstrapping keystone while already having authentication/authorization enforced without going directly into the database | 15:12 |
| gtema | idea is to extend policies with "is_admin" (which exactly stands for user authenticated as admin and not having the admin role) and in addition to that to enforce ceratin operations to be performed only through the internal/admin interface | 15:14 |
| gtema | one soft disadvantage is that with that I make SPIFFE mandatory dependency. But it is a de-facto standard nowadays anyway in any zero-trust env, so it should not be a problem | 15:14 |
| gtema | and when necessary other "fallbacks" can be implemented. Just for now this is the easiest (and actually the safest) possible method | 15:15 |
| gtema | Another topic | 15:15 |
| gtema | I had a first meeting with the students last week that would be supporting the RS development over the next 10-11 weeks. They just started onboarding, but ... I am happy to have more hands | 15:16 |
| d34dh0r53 | ack | 15:16 |
| d34dh0r53 | that's awesome! | 15:16 |
| gtema | that's it on the topic | 15:16 |
| d34dh0r53 | thanks gtema | 15:17 |
| d34dh0r53 | #topic open discussion | 15:17 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/983993 | 15:18 |
| d34dh0r53 | I need to review that one | 15:18 |
| gtema | I guess that's from 2 weeks ago. I still had no time to go thoroughly, but there were few points where I was not feeling comfortable | 15:18 |
| d34dh0r53 | okay | 15:19 |
| d34dh0r53 | anything else for open discussion? | 15:20 |
| gtema | I doubt, looks like there are only 2 of us | 15:20 |
| d34dh0r53 | yeah, let's run through the bugs | 15:20 |
| d34dh0r53 | #topic bug review | 15:20 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:20 |
| d34dh0r53 | no new bugs for keystone | 15:21 |
| d34dh0r53 | #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 | 15:21 |
| d34dh0r53 | nothing new in python-keystoneclient | 15:21 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 | 15:21 |
| d34dh0r53 | keystoneauth is good | 15:22 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 | 15:22 |
| d34dh0r53 | looks like we do have a new bug in keystonemiddleware | 15:22 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystonemiddleware/+bug/2153561 | 15:22 |
| gtema | I was proposing a fix for it but now I see there was a comment in bug afterwards that I haven't seen | 15:23 |
| * dmendiza[m] sneaks in at the last minute | 15:23 | |
| d34dh0r53 | yeah, gmann made a comment | 15:24 |
| d34dh0r53 | hi dmendiza 👋 | 15:25 |
| d34dh0r53 | I think gmann makes a good point | 15:28 |
| gtema | I am not convinced. At the end there is and always was a certain interpretation freedom (in HTTP) leading to many weird confusions | 15:29 |
| d34dh0r53 | yeah, especially with the 4xx returns | 15:30 |
| gtema | I guess the "security" aspect could be addressed by the CSP by simply forbidding all requests with x-service-token header set on the proxy level | 15:30 |
| gtema | since in the ideal world 403 means you are not authorized to do that operation, but I know who you are | 15:31 |
| gtema | which fits in this case | 15:32 |
| d34dh0r53 | yeah | 15:32 |
| gtema | I am actually wondering that the bug itself was created refering the tempest failures, and now gmann says it is not actually an issue for tempest | 15:33 |
| d34dh0r53 | I guess we should discuss it in the bug itself | 15:37 |
| d34dh0r53 | moving on to pycadf | 15:37 |
| d34dh0r53 | #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 | 15:37 |
| d34dh0r53 | no new bugs there | 15:38 |
| d34dh0r53 | #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 | 15:38 |
| d34dh0r53 | ldappool is also good | 15:38 |
| d34dh0r53 | #topic conclusion | 15:38 |
| d34dh0r53 | Thanks all! | 15:38 |
| gtema | thanks Dave | 15:38 |
| d34dh0r53 | #endmeeting | 15:38 |
| opendevmeet | Meeting ended Wed May 27 15:38:39 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:38 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-05-27-15.02.html | 15:38 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-05-27-15.02.txt | 15:38 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-05-27-15.02.log.html | 15:38 |
| gmaan | gtema: I opened the bug and then found it is tempest test bug but cinder that is why mark invalid for cinder. My main concern is not 403 vs 401 but telling that this is not right role for the service which is security leak at some way | 17:44 |
| gtema | thanks for explaining. In reality there are many more reasons why 403 may be returned (I know it is not really the case for the middleware), but imagine the keystone policy actually block token verification | 17:46 |
| gtema | and when in keystone user does not have the privilege to do something we also return 403 (sometimes of course we explicitly hide it behind 404 to not to expose resource existence) | 17:47 |
| gtema | and I think we can return 403 from the token validation (i.e. x-auth-token is not admin/service/whatever and x-subject-token is not owned by the user) | 17:51 |
| gmaan | I agree with the user token, but the service token is a little different, and I feel that, as much as we can hide internal details, it is better. User can pass their token, and if we return 403 they can get to know they need some extra role to be qualified as a service token. | 17:55 |
| gmaan | The service token use case is only to extend the user token expisr and only valid when they have the required roles, so denying that with 401 always make sense to me | 17:55 |
| gtema | I understand what you mean, but not convinced. I guess this can go really both ways and they both can be "valid" | 18:00 |
| gmaan | yeah, I am not saying this is very wrong but it can be more correct. again my opinion might differ from many but that is whsat I thought when it comes to service token | 18:01 |
| opendevreview | Artem Goncharov proposed openstack/keystonemiddleware master: Adopt pre-commit https://review.opendev.org/c/openstack/keystonemiddleware/+/989651 | 18:12 |
| opendevreview | Artem Goncharov proposed openstack/keystonemiddleware master: Enable mypy for typing in pre-commit https://review.opendev.org/c/openstack/keystonemiddleware/+/989652 | 18:12 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!