15:01:35 <d34dh0r53> #startmeeting keystone
15:01:35 <opendevmeet> Meeting started Wed Apr  2 15:01:35 2025 UTC and is due to finish in 60 minutes.  The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:35 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:35 <opendevmeet> The meeting name has been set to 'keystone'
15:02:17 <d34dh0r53> Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct
15:02:26 <d34dh0r53> #link https://openinfra.dev/legal/code-of-conduct
15:02:34 <d34dh0r53> #topic roll call
15:02:41 <gtema> o/
15:02:45 <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:24 <d34dh0r53> dmendiza for the dingz
15:03:51 <dmendiza[m]> 👋
15:04:59 <d34dh0r53> #topic review past meeting work items
15:05:04 <d34dh0r53> #link https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-03-26-15.01.html
15:05:09 <d34dh0r53> no action items from last week
15:05:16 <d34dh0r53> #topic liaison updates
15:05:22 <d34dh0r53> nothing from releases or VMT
15:06:08 <gtema> nothing from releases? ;-)
15:06:18 <gtema> we have a release, so party :D
15:07:28 <d34dh0r53> Oh yeah, duh
15:07:30 <mharley[m]> o/
15:07:40 <d34dh0r53> 🥳
15:08:27 <dmendiza[m]> 🎉
15:09:01 <d34dh0r53> Thank you for the reminder gtema :)
15:09:16 <d34dh0r53> #topic specification OAuth 2.0 (hiromu)
15:09:18 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext
15:09:22 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability
15:09:23 <d34dh0r53> External OAuth 2.0 Specification
15:09:24 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 (merged)
15:09:27 <d34dh0r53> OAuth 2.0 Implementation
15:09:30 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls (merged)
15:09:32 <d34dh0r53> OAuth 2.0 Documentation
15:09:34 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/838108 (merged)
15:09:37 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 (merged)
15:11:09 <d34dh0r53> I'm going to do a manual rebase of #link https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/874716 today and we'll see where that gets us
15:11:38 <d34dh0r53> that's all for me
15:11:42 <d34dh0r53> #topic specification Secure RBAC (dmendiza[m])
15:11:44 <d34dh0r53> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_
15:11:46 <d34dh0r53> 'v
15:11:49 <d34dh0r53> 2024.1 Release Timeline
15:11:51 <d34dh0r53> Update oslo.policy in keystone to enforce_new_defaults=True
15:11:54 <d34dh0r53> Update oslo.policy in keystone to enforce_scope=True
15:12:47 <d34dh0r53> any rbac updates dmendiza ?
15:15:44 <d34dh0r53> #topic specification OpenAPI support (gtema)
15:15:51 <d34dh0r53> #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone
15:16:26 <gtema> no updates. But since E is out I can return to requiring release of openstackdocstheme so that I can proceed
15:17:08 <d34dh0r53> indeed
15:20:40 <d34dh0r53> #topic specification Include bad password details in audit messages (stanislav-z)
15:20:41 <d34dh0r53> #link https://review.opendev.org/q/topic:%22pci-dss-invalid-password-reporting%22
15:20:43 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/915482 (merged)
15:20:44 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/932423 (merged)
15:20:46 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/945733 (merged)
15:20:48 <d34dh0r53> All merged
15:20:52 <d34dh0r53> woot!
15:21:01 <stanislav-z> yes, thanks for the reviews and patience!
15:21:20 <d34dh0r53> absolutely, thank you!
15:21:24 <d34dh0r53> anything else on this one or can we archive it?
15:22:54 <stanislav-z> nope, I'd say all's good so far. I'm going to remove the topic from the list - or would you move it somewhere?
15:23:18 <d34dh0r53> I can move it
15:23:34 <stanislav-z> thanks
15:23:47 <d34dh0r53> #topic open discussion
15:23:50 <d34dh0r53> PTG etherpad is up
15:24:03 <d34dh0r53> #link https://etherpad.opendev.org/p/apr2025-ptg-keystone
15:24:37 <gtema> few interesting topics already there ;-)
15:24:47 <d34dh0r53> yeah
15:24:59 <gtema> my webinar from last week is now published (https://www.youtube.com/watch?v=0Hx4Q22ZNFU)
15:25:21 <d34dh0r53> congrats!
15:25:28 <gtema> it shows first results of reimplementing Keystone in Rust and authN with yubikey
15:25:31 <gtema> thanks
15:25:51 <gtema> it maybe something interesting to watch before we come to that point in PTG
15:26:09 <d34dh0r53> Yeah, I'll watch it
15:26:33 <gtema> second thing (actually also from that side). Does anybody remembers what is the sense of having domain bound roles if those are not injected into the token?
15:27:50 <gtema> I agree there are tons of issues with that (i.e. when domain role is named "admin - currently nothing prevents you creating such and there are no IDs in the oslo.policy check so it cannot even check what is this role about)
15:29:01 <gtema> it is just confusing to have some capability that is not doing anything useful
15:29:13 <d34dh0r53> I don't recall
15:29:27 <dmendiza[m]> gtema: depends on what kind of token you get
15:29:35 <d34dh0r53> dmendiza ^
15:30:07 <gtema> not sure, I assigned domain specific role to the user on project and domain and it is not present in domain scope and project scope
15:30:08 <dmendiza[m]> when you send a request to get a token, you choose the scope - 99% of the time people use project scope, so roles assigned on a domain don't show up
15:30:20 <gtema> was not checking the system scope, but it makes even less sense
15:30:31 <dmendiza[m]> there's 3 scopes:
15:30:35 <dmendiza[m]> - project (the one everyone knows)
15:30:45 <dmendiza[m]> - domain
15:30:50 <dmendiza[m]> * system
15:30:52 <gtema> I know dmendiza - and those domain roles are not present in any of those
15:31:02 <dmendiza[m]> That seems like a bug
15:31:21 <dmendiza[m]> domain roles should be present on a domain scoped token
15:32:35 <gtema> I am not sure we can treat it like a bug, since as I said - nothing prevents you from creating "admin" role in the domain. So if domain_manager is capable to grant something like that oslo_policy would not even be able to differentiate such roles
15:32:58 <gtema> it has to do with the design of it
15:33:02 <d34dh0r53> There's a bug in keystone
15:33:10 <d34dh0r53> about the domain manager role
15:33:20 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2105988
15:33:29 <dmendiza[m]> gtema: not sure I follow what you mean about "admin" role
15:34:11 <dmendiza[m]> olso_policy has two ways of checking scope
15:34:18 <dmendiza[m]> although, I admit, they're awkward and not ideal
15:34:47 <gtema> dmendiza - role names must be unique only within the domain. So on the domain level you can create role names admin or manager/member/etc. On the oslo_policy level there is no way to differentiate whether the role is a global one of a domain specific one
15:35:01 <dmendiza[m]> IIRC, Keystone reserves system-wide roles
15:35:27 <dmendiza[m]> namely "admin", "manager", "member", "reader", and "service" are globally unique
15:36:21 <gtema> reserves does not mean it prevents you from creating multiple admin roles in different domains
15:36:31 <gtema> and they are NOT globally unique
15:36:50 <gtema> only within the domain. Global roles are just having a special "NULL_DOMAIN"
15:38:37 <dmendiza[m]> https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html
15:39:18 <dmendiza[m]> I want to say that was the relevant spec
15:39:24 <dmendiza[m]> for making default roles unique
15:39:55 <gtema> I think we should at least review this (I spend couple of days already in my Rust POC reverse-engineering this topic) and discuss in PTG
15:40:07 <gtema> today I did a test and was able to get 2 admin roles
15:40:23 <gtema> one within the "null" domain and another in the customer domain
15:40:27 <dmendiza[m]> Yeah, I can do some testing with Epoxy and/or master and see what the deal is
15:40:30 <gtema> (with admin creds, but still)
15:40:58 <d34dh0r53> 👍
15:41:19 <d34dh0r53> anything else for open discussion?
15:42:22 <gtema> nothing from me except of simple statement that implied_role DB design is making it impossible to get implied assignments in a single DB query. Not sure how to deal with it though
15:43:27 <gtema> doesn't look like there is any way to change it, so apparently the best way is simply to read all roles and implied into memory and construct it on the "server side" away from DB
15:43:37 <d34dh0r53> hmm
15:44:44 <gtema> pg and mysql support recursive queries, but even with that it is insane complex to get the query right. I doubt any ORM in the world would be capable getting it right
15:44:54 <d34dh0r53> are they calculated on the fly in keystone?
15:45:09 <gtema> yeah, read all direct assignments
15:45:31 <gtema> and afterwards every role is resolved on the fly to expand the implied ones
15:46:11 <gtema> if your implied rules are small enough it is not a problem, but what if you have few thousand of those?
15:46:25 <gtema> But yeah, this is not a standard case with upstream roles
15:46:57 <gtema> it is relevant exactly for the above of domain specific roles and "domain_manager" capable of creating domain roles
15:47:47 <gtema> I am done, took anyway too much time today ;-)
15:48:14 <d34dh0r53> no worries, useful conversation
15:48:20 <d34dh0r53> we have lots to talk about at the ptg
15:48:41 <d34dh0r53> #topic bug review
15:48:44 <d34dh0r53> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0
15:48:59 <d34dh0r53> like I mentioned there is one new bug in keystone
15:49:10 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2105988
15:49:32 <dmendiza[m]> I can take a look at that
15:49:41 <d34dh0r53> thanks dmendiza
15:49:51 <d34dh0r53> next up
15:49:52 <d34dh0r53> #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0
15:50:01 <d34dh0r53> no new bugs for python-keystoneclient
15:50:05 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0
15:50:29 <d34dh0r53> we have two new bugs in keystoneauth
15:50:39 <d34dh0r53> first up
15:50:46 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bug/2105902
15:52:39 <d34dh0r53> is Grzegorz Grasza around?
15:52:49 <d34dh0r53> both of these are related
15:53:14 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bug/2105891
15:54:04 <d34dh0r53> I'll see if I can get Grzegorz Grasza to look at these, he's on PTO today
15:54:16 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0
15:54:23 <d34dh0r53> no new bugs in keystonemiddleware
15:54:29 <d34dh0r53> #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0
15:54:51 <d34dh0r53> pycadf is good
15:54:53 <d34dh0r53> #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0
15:54:55 <d34dh0r53> ldappool is also good
15:54:57 <d34dh0r53> #topic conclusion
15:55:15 <d34dh0r53> PTG next week, so no weekly meeting
15:55:28 <d34dh0r53> have a great rest of your week :)
15:55:48 <gtema> thanks Dave for still doing this meetings :)
15:56:34 <d34dh0r53> you're welcome :)
15:56:56 <d34dh0r53> #endmeeting