| opendevreview | Merged openstack/keystone stable/2025.1: Use branch constraints for tempest venv on stable/2025.1 https://review.opendev.org/c/openstack/keystone/+/989203 | 03:11 |
|---|---|---|
| opendevreview | Merged openstack/keystone stable/2025.1: Enforce app cred project boundary on EC2 credential paths https://review.opendev.org/c/openstack/keystone/+/988237 | 06:05 |
| *** darmach1002 is now known as darmach100 | 11:09 | |
| opendevreview | Erlon R. Cruz proposed openstack/keystonemiddleware master: DNM: Revert "Change service_token_roles_required default config" https://review.opendev.org/c/openstack/keystonemiddleware/+/989365 | 11:51 |
| dmendiza[m] | 🙋♂️ | 15:04 |
| gtema | wow, dmendiza is here before the special ping ;-) | 15:04 |
| gtema | is Dave Wilde (d34dh0r53) around? | 15:05 |
| gtema | #startmeeting keystone | 15:05 |
| opendevmeet | Meeting started Wed May 20 15:05:14 2026 UTC and is due to finish in 60 minutes. The chair is gtema. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:05 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:05 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:05 |
| gtema | Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct | 15:05 |
| gtema | #link https://openinfra.dev/legal/code-of-conduct | 15:05 |
| gtema | #topic roll call | 15:06 |
| gtema | 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:06 |
| d34dh0r53 | o/ | 15:06 |
| gtema | o/ | 15:06 |
| gtema | #topic review past meeting work items | 15:08 |
| gtema | #link https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-05-13-15.00.html | 15:08 |
| gtema | no actions logged and I know I still haven't worked on adding doc notes on changed behavios wrt 403 vs 403 | 15:09 |
| gtema | #topic liaison updates | 15:09 |
| gtema | I do not have anything from me | 15:09 |
| gtema | looks like no other updates as well, then moving on | 15:11 |
| gtema | #topic specification | 15:11 |
| gtema | #topic Secure RBAC (dmendiza) | 15:11 |
| gtema | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:11 |
| dmendiza[m] | #link https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/986031 | 15:13 |
| dmendiza[m] | merged | 15:13 |
| dmendiza[m] | so SRBAC is now being tested (and voting) for keystone and keystone-tempest-plugin | 15:13 |
| dmendiza[m] | Haven't had a chance to look into the overrides, but that's what I'm doing next | 15:13 |
| gtema | so the item can be removed from the agenda? | 15:13 |
| dmendiza[m] | not quite ... we still want to make sure were good to go when enforce_scope gets removed from oslo.policy | 15:14 |
| gtema | okay, got it | 15:14 |
| gtema | anything else on that one? | 15:15 |
| dmendiza[m] | Nothing else today | 15:15 |
| gtema | ok | 15:15 |
| gtema | #topic Secuirty Compliance Testing (dmendiza) | 15:16 |
| gtema | #link https://review.opendev.org/c/openstack/devstack/+/957969 | 15:16 |
| dmendiza[m] | No progress this week | 15:18 |
| gtema | okay, then moving on | 15:19 |
| gtema | #topic keystone-rs | 15:19 |
| gtema | #link https://github.com/openstack-experimental/keystone | 15:19 |
| gtema | I do not have much to report on that since I am still refactoring the Token concept to be not the primary auth entity | 15:19 |
| gtema | but there are good news as well - we got students to work on the project | 15:20 |
| gtema | I still had no chance to meet them and arrange the work, but we are definitely going to have support here | 15:20 |
| gtema | somebody also raised an issue questioning whether OpenPolicyAgent should be used or whether from scratch we should go towards Cedar | 15:21 |
| gtema | benefit of Cedar is that it is written in Rust so it can be easily embedded vs running OPA as a side car. The disadvantage is that it is then harder to get OpenStack to Cedar | 15:22 |
| gtema | but yeah, this is an idea that is worth a wide discussion in my eyes | 15:23 |
| gtema | #topic open discussion | 15:23 |
| bbobrov | o/ | 15:23 |
| bbobrov | i have a maybe silly question about SRBAC. | 15:23 |
| bbobrov | i read in https://bugs.launchpad.net/horizon/+bug/968696 that in nova "admin" is something like a "cloud admin" - can do everything everywhere cross-project | 15:23 |
| bbobrov | (last comment from sean mooney in the very end) | 15:24 |
| bbobrov | and "elevated access inside project" is "manager" on project | 15:24 |
| bbobrov | and in keystone "admin" is still confined inside the project, so keystone doesn't do "project manager" | 15:24 |
| bbobrov | am i reading it right? | 15:24 |
| * bbobrov looks at dmendiza[m] maybe? | 15:26 | |
| dmendiza[m] | 🙋♂️ | 15:26 |
| gtema | I don't know. I guess there are as many perceptions as people in OpenStack. In Keystoe we have project manager, and I totally get that the "admin" role make only sense on something like a system scope | 15:27 |
| dmendiza[m] | Right, so, historically admin role means root | 15:27 |
| dmendiza[m] | also, historically the only scope was project | 15:27 |
| dmendiza[m] | so, may policies across the many openstack projects only check tokens to see if the user has been assigned admin on some scope | 15:28 |
| dmendiza[m] | but they do not care about what scope it is | 15:28 |
| dmendiza[m] | so granting admin on any project/domain/system has the side effect of satisfying those policies | 15:28 |
| dmendiza[m] | hence "admin anywhere is admin everywhere" | 15:28 |
| dmendiza[m] | System Admin persona (granting admin role to a user on the system scope) was proposed to be a solution for this, but efforts fizzled out | 15:29 |
| bbobrov | but do we have "project manager" in keystone? | 15:29 |
| bbobrov | or differently - does "manager" on project P with default policies give me any elevated access inside a project/ | 15:30 |
| gtema | sure, but in Keystone project scope does not make much sense | 15:30 |
| dmendiza[m] | Right, so what you're asking is "do we have any policies in keystone for which the "manager" role is allowed to do something when granted on a project scope" | 15:30 |
| dmendiza[m] | and I don't know the answer off the top of my head | 15:30 |
| dmendiza[m] | But yeah, would not be that useful in Keystone | 15:30 |
| bbobrov | gtema: Then who assigns project members? | 15:31 |
| gtema | majority of operations in KS are domain scoped | 15:31 |
| dmendiza[m] | historically the admin/root user would create assign users, | 15:31 |
| gtema | and the idea was to grant manager on the domain (in the scope of Keystone) to allow user to manage users and projects in this domain | 15:31 |
| dmendiza[m] | but Domain Manager persona was introduced to provide self-management from an end user perspective | 15:31 |
| gtema | what the manager roles gives outside of keystone is not in our hands | 15:31 |
| bbobrov | i have the following flow in my head. Domain admin creates a project and assigns a project admin. Project admin then invites other users who become project members. Where is the flow in my logic? | 15:32 |
| dmendiza[m] | s/admin/manager | 15:32 |
| bbobrov | *flaw | 15:32 |
| gtema | manager on the project does not give you anything in keystone | 15:32 |
| dmendiza[m] | the cloud operator (system-admin or project-admin or domain-admin) creates a user and creates a domain for that user. Then they assign "manager" role to that user | 15:32 |
| dmendiza[m] | from that point forward the Domain Manager can add users to their domain | 15:33 |
| dmendiza[m] | and grant roles that only apply in that domain | 15:33 |
| dmendiza[m] | (excluding admin role) | 15:33 |
| gtema | correct | 15:33 |
| bbobrov | so here then another view. In keystone project admin can (should?) create role assignments on their project (and only on their project). In nova project admin can access everything cross-project. Am i wrong? | 15:34 |
| gtema | from Keystone point of view there MUST NEVER be project admin except of the mentioned root user | 15:35 |
| gtema | admin role granted on project or domain is still root and is not isolated to be handed over to users | 15:36 |
| bbobrov | oh ok, i understand then. Who assignes role "member" on a project then? | 15:36 |
| gtema | domain manager is the one that should assign roles to users of the domain on projects of the domain | 15:36 |
| bbobrov | undestood, thanks. | 15:37 |
| gtema | welcome | 15:37 |
| gtema | in my "SPIFFE" work I am introducing identities which are not backed by regular users and can be used by other services (like nova) to limit them to only validate token, and similar stuff | 15:38 |
| gtema | at the end we would be able to rethink the root problem as such | 15:38 |
| gtema | anything else for open discussion? | 15:39 |
| gtema | #topic bug review | 15:40 |
| gtema | very quick - I went through all of the projects and there are no new bugs | 15:40 |
| gtema | #topic conclusion | 15:41 |
| gtema | thanks everyone for participation | 15:41 |
| gtema | #endmeeting | 15:41 |
| opendevmeet | Meeting ended Wed May 20 15:41:55 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:41 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-05-20-15.05.html | 15:41 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-05-20-15.05.txt | 15:41 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-05-20-15.05.log.html | 15:41 |
| d34dh0r53 | Thanks gtema | 15:44 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!