15:02:02 <d34dh0r53> #startmeeting keystone
15:02:02 <opendevmeet> Meeting started Wed Jan 15 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:02 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:02 <opendevmeet> The meeting name has been set to 'keystone'
15:02:21 <xek> o/
15:02:27 <gtema> o/
15:02:43 <d34dh0r53> Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct
15:02:46 <d34dh0r53> #link https://openinfra.dev/legal/code-of-conduct
15:02:50 <d34dh0r53> #topic roll call
15:02:58 <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
15:03:05 <d34dh0r53> and a special ding for dmendiza
15:03:15 <d34dh0r53> :)
15:03:25 <dmendiza[m]> 🙋‍♂️
15:03:30 <cardoe> o/
15:03:32 <gtema> lol
15:04:16 <d34dh0r53> o/
15:04:22 <d34dh0r53> #topic review past meeting work items
15:05:03 <d34dh0r53> #link https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-01-08-15.01.html
15:05:10 <d34dh0r53> had to update the link
15:05:18 <d34dh0r53> no action items from the last meeting
15:05:23 <d34dh0r53> #topic liaison updates
15:05:30 <d34dh0r53> nothing from releases or vmt
15:07:52 <d34dh0r53> #topic specification OAuth 2.0 (hiromu)
15:08:03 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext
15:08:06 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability
15:08:08 <d34dh0r53> External OAuth 2.0 Specification
15:08:12 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 (merged)
15:08:15 <d34dh0r53> OAuth 2.0 Implementation
15:08:19 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls
15:08:24 <d34dh0r53> OAuth 2.0 Documentation
15:08:26 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/838108 (merged)
15:08:29 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 (merged)
15:08:33 <d34dh0r53> no updates
15:10:00 <d34dh0r53> #topic specification Secure RBAC (dmendiza[m])
15:10:07 <d34dh0r53> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_
15:10:08 <d34dh0r53> 2024.1 Release Timeline
15:10:08 <d34dh0r53> Update oslo.policy in keystone to enforce_new_defaults=True
15:10:14 <d34dh0r53> Update oslo.policy in keystone to enforce_scope=True
15:10:20 <d34dh0r53> dmendiza: any SRBAC updates?
15:11:18 <dmendiza[m]> Negative...
15:11:27 <dmendiza[m]> I shoudl get back to that some time soon hopefully
15:11:55 <d34dh0r53> cool, thanks dmendiza
15:11:59 <d34dh0r53> #topic specification OpenAPI support (gtema)
15:12:02 <d34dh0r53> #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone
15:12:19 <gtema> thanks Dave for reviewing some changes
15:12:29 <gtema> generally - there are things to review and land
15:12:35 <gtema> further work is in progress
15:12:56 <xek> I'll get to reviewing those soon
15:13:03 <gtema> btw, I started work on building openapi for barbican, which is not trivial ;-)
15:13:33 <d34dh0r53> woot
15:13:41 <dmendiza[m]> Oh, yeah, Barbican API is kinda ugly in some parts
15:14:16 <gtema> not only that, I mean introspecting the code is not really possible without hardcoding routing table due to the extensive use of dynamic routing
15:14:31 <gtema> because of that I can only natively find only half of the routes
15:15:04 <gtema> I got request from somebody in the community to add this
15:15:29 <gtema> so anyway, will look further in next days, but keystone jsonschemas are in progress but need reviews ;-)
15:15:33 <gtema> nothing else on that
15:16:22 <d34dh0r53> thanks gtema
15:16:25 <d34dh0r53> #topic specification domain manager (mhen)
15:16:29 <d34dh0r53> still unmerged are:
15:16:32 <d34dh0r53> documentation: https://review.opendev.org/c/openstack/keystone/+/928135
15:16:34 <d34dh0r53> tempest tests: https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/924222
15:16:42 <d34dh0r53> dmendiza: mind taking a look at those?
15:17:10 <dmendiza[m]> Yeah... I need to get back to reviewing things 😅
15:18:06 <d34dh0r53> No worries, it's been a busy few months
15:18:29 <gtema> yeah, Christmas, New Year and such sort of things ;-)
15:19:02 <d34dh0r53> #topic specification Include bad password details in audit messages (stanislav-z)
15:19:05 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/915482
15:19:08 <d34dh0r53> #link https://review.opendev.org/q/topic:%22pci-dss-invalid-password-reporting%22
15:19:10 <d34dh0r53> 15-Jan update: there are some open conversations in the spec - would appreciate the feedback and general reviews
15:19:55 <stanislav-z> yes, turned out I had my responses in the keystone-spec submitted weeks ago, but not published 😞. but I did it today
15:20:23 <gtema> ok, will have a look this week (if nothing explodes)
15:21:13 <d34dh0r53> thanks gtema
15:21:19 <d34dh0r53> #topic open discussion
15:21:23 <d34dh0r53> nothing from me
15:21:28 <gtema> I have few things
15:21:58 <gtema> I mentioned last friday I joined SysEleven and there is interesting usage of OpenFGA for managing authorization externally
15:22:19 <gtema> so I created role-assignment plugin for communicating with openfga
15:22:58 <gtema> but noticed that if we want to delegate role assignments to the external system which itself is capable dealing with role inference and inheritance there is no way to do this in driver
15:23:28 <gtema> basically keystone role-assignment provider is enforcing lots of things which can be done in the external system (openfga/aws cedar/opa/etc)
15:23:46 <dmendiza[m]> O
15:23:48 <dmendiza[m]> O
15:23:51 <gtema> I think it would make sense to have possibility to externalize this more natively
15:23:55 <dmendiza[m]> I've got something too
15:24:37 <gtema> i.e. there is a call to list_role_assignments which gets bazilion of params and is being invoked few times
15:25:18 <gtema> which this is not necessary if external system can deal with that and it doesn't differentiate between "effective" roles and direct what might be necessary
15:25:58 <gtema> so: are you guys ok reworking role-assignment provider slightly to allow to put all logic to the external system if such system support that?
15:26:53 <gtema> basically for now it means splitting some methods to allow more granular overloading and having possibility to disable auth caching to allow roles being read dynamically from external system
15:27:43 <xek> I'm for it +1
15:28:12 <gtema> cool, thks. This is more or less for now to allow external system to make decision which roles are assigned to the user
15:29:04 <gtema> and a second question: here they do not use domains at all and (together with keycloak and openfga) manage user/projects directly under the default domain
15:29:56 <gtema> I am struggling at the moment to find enough arguments against that (to start using domains for better segregation). Do you know any reasons why this should be preferred in a public cloud?
15:30:31 <gtema> statement "it is not scalable" is not sufficient, I need something with more weight
15:31:26 <dmendiza[m]> The main use of Domains is to group Projects together.  In a public cloud you could map a client's account to be their domain.  That way a single account could own many projects while being insulated from other accounts.
15:32:05 <gtema> right, but it is also possible to grant user(s) access to projects directly bypassing domains grouping
15:32:47 <dmendiza[m]> I think the main argument for Domains would be the Domain Manager persona whereby you could have an end user manage permissions for their domain as opposed to having to call the deployer every time.
15:32:50 <gtema> I was thinking more into the performance of certain queries, quotas/limits or similar stuff
15:33:36 <gtema> correct, domain manager is here a perfect fit, but if permissions are managed externally (because they want to unify authz for openstack/kubernetes/ceph/etc all the other things)
15:34:30 <gtema> then domain manager becomes somehow unnecessary (or better to say not appliable). Anyway, I definitely ack that and it is one of the arguments, but I need a bit more
15:37:54 <dmendiza[m]> Yeah, I'm not sure about performance implications. 🤔
15:38:20 <gtema> when domain_id is part of the index then it is definitely faster to find entry
15:38:38 <gtema> but whether it is "noticable" I have no clue
15:39:24 <gtema> and since all other services do not deal with domains, but only with projects it is hard to justify
15:41:19 <gtema> anyway, if there are no known things - thanks
15:41:42 <gtema> will still try to convince from the "upstream and all other CSPs" do it this way
15:42:38 <dmendiza[m]> On my end, I still need to file a LP bug for this, but we found a breaking bug in the LDAP backend
15:43:10 <dmendiza[m]> Bugfix patch is here, but it's currently failing the gate jobs: https://review.opendev.org/c/openstack/keystone/+/939172
15:45:16 <d34dh0r53> I haven't looked yet, any idea what's failing?
15:45:49 <gtema> looks mypy is now complaining in pep8 checks
15:46:16 <gtema> I will have a look today/tomorrow whether there is a new gate blocker due to updated additional SW
15:46:31 <d34dh0r53> thanks gtema
15:46:40 <d34dh0r53> anything else for open discussion?
15:46:51 <gtema> not from me
15:47:45 <d34dh0r53> cool
15:47:46 <d34dh0r53> #topic bug review
15:47:49 <d34dh0r53> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0
15:47:56 <d34dh0r53> no new bugs in keystone
15:48:01 <d34dh0r53> #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0
15:48:12 <d34dh0r53> python-keystoneclient has no new bugs
15:48:15 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0
15:48:22 <d34dh0r53> nothing in keystoneauth either
15:48:25 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0
15:48:30 <d34dh0r53> keystonemiddleware is good
15:48:34 <d34dh0r53> #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0
15:48:45 <d34dh0r53> pycadf is also good
15:48:48 <d34dh0r53> #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0
15:48:54 <d34dh0r53> no new bugs in ldappool
15:49:00 <d34dh0r53> #topic conclusion
15:49:03 <d34dh0r53> Thanks everyone!
15:49:13 <gtema> thks guys
15:49:16 <d34dh0r53> #endmeeting