15:00:28 <d34dh0r53> #startmeeting keystone
15:00:28 <opendevmeet> Meeting started Wed Nov 29 15:00:28 2023 UTC and is due to finish in 60 minutes.  The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:28 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:28 <opendevmeet> The meeting name has been set to 'keystone'
15:00:50 <d34dh0r53> #topic roll call
15:00:56 <d34dh0r53> admiyo, bbobrov, crisloma, d34dh0r53, dpar, dstanek, hrybacki, knikolla[m], lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, ruan_he, wxy, sonuk, vishakha, Ajay, rafaelwe, xek, gmann, zaitcev, reqa, dmendiza[m]
15:00:58 <d34dh0r53> o/
15:00:59 <bbobrov> hello
15:01:03 <xek> o/
15:01:48 <hiromu> o/
15:02:56 <dmendiza[m]> 🙋‍♂️
15:03:56 <d34dh0r53> #topic review past meeting work items
15:04:10 <d34dh0r53> two action items assigned to me, no updates
15:04:27 <d34dh0r53> #action d34dh0r53 Look into adding/restoring a known issues section to our documentation
15:04:34 <d34dh0r53> #action d34dh0r53 add https://bugs.launchpad.net/keystone/+bug/1305950 to the known issues section of our documentation
15:04:49 <d34dh0r53> #topic liaison updates
15:05:01 <d34dh0r53> nothing from VMT or Release Management
15:05:08 <d34dh0r53> anyone else have anything?
15:05:56 <gtema> specs?
15:06:07 <d34dh0r53> #topic specification OAuth 2.0 (hiromu)
15:06:39 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext
15:06:40 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability
15:06:40 <hiromu> I wrote one topic on the etherpad
15:06:40 <hiromu> https://etherpad.opendev.org/p/keystone-weekly-meeting
15:06:42 <d34dh0r53> External OAuth 2.0 Specification
15:06:44 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/861554
15:06:46 <d34dh0r53> OAuth 2.0 Implementation
15:06:48 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls
15:06:50 <d34dh0r53> OAuth 2.0 Documentation
15:06:52 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/838108
15:06:54 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystoneauth/+/838104
15:07:30 <d34dh0r53> ack hiromu, reading it now
15:10:01 <hiromu> in short, we gave up to reload oslo config without restarting services (i.e., hot-reloading) and decided to restart services in Zuul job
15:10:45 <d34dh0r53> I think the service restart is probably the best option
15:11:00 <hiromu> okay
15:11:58 <hiromu> we'll implement Zuul job with that option
15:12:08 <hiromu> btw, you mentioned job spin up is expensive in the second last meeting. What does that mean specifically?
15:12:32 <d34dh0r53> As to job spin up, I think that was referring to the time it takes to setup VMs, install packages, clone repos, etc...
15:12:45 <d34dh0r53> all the things that Zuul needs to do before the actual testing of code
15:13:00 <hiromu> I see, but I think sping up happens in parallel.
15:13:29 <hiromu> /sping/spin/
15:14:08 <d34dh0r53> It does, but parallel jobs also require more nodes which takes away from the resource pool, we just need to be good citizens and minimize our footprint as much as possible.
15:14:32 <d34dh0r53> But if that's the only way we can do it, then that is how we'll do it
15:15:13 <hiromu> I agree. We'll try the way that can minimize the resources usage first
15:15:23 <d34dh0r53> excellent, thanks hiromu!
15:15:37 <hiromu> :)
15:16:17 <d34dh0r53> anything else for OAuth 2.0?
15:16:29 <hiromu> nothing else. thanks.
15:16:38 <d34dh0r53> #topic specification Secure RBAC (dmendiza[m])
15:16:49 <d34dh0r53> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_
15:16:51 <d34dh0r53> 2024.1 Release Timeline
15:16:53 <d34dh0r53> Update oslo.policy in keystone to enforce_new_defaults=True
15:16:55 <d34dh0r53> Update oslo.policy in keystone to enforce_scope=True
15:17:00 <dmendiza[m]> I don't have anything to report. 😅
15:17:45 <d34dh0r53> no worries, thanks dmendiza[m]
15:17:46 <bbobrov> i just want to say that none of our services can live with these options =True. For all services we have to make them =False
15:18:24 <bbobrov> but we have an old cloud with own policies
15:19:08 <dmendiza[m]> Yeah, those options only apply to the default policy values
15:21:04 <d34dh0r53> right
15:23:34 <d34dh0r53> gtema: I added your spec under the specifications section of the doc and I've updated the wiki page with the correct meeting information
15:23:41 <d34dh0r53> gtema: thank you for pointing that out
15:23:55 <d34dh0r53> #topic specification Add schema version and support to "domain" attribute in mapping rules (gtema)
15:24:07 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/748042
15:24:09 <gtema> right, basically it is a long runner
15:24:24 <gtema> it was put on hold and forgotten. Now we try to revivew
15:24:27 <d34dh0r53> I noticed that, I'll take a look at it this week
15:24:28 <gtema> revive it
15:24:57 <gtema> in PTG it was promised to land it asap and Kristi already reviewed it
15:25:23 <gtema> ok, thanks. We really depend on it and need some progress finally
15:25:43 <d34dh0r53> yep, sorry it slipped through the cracks
15:26:02 <d34dh0r53> it's on the etherpad now :)
15:26:11 <gtema> btw, which time is the review session fridays? I was not able to find it
15:26:39 <d34dh0r53> I think I'll add that to the wiki, 15:00 UTC on Fridays
15:26:50 <d34dh0r53> I can send a calendar invite if you'd like
15:27:07 <gtema> yes, pls (artem.goncharov@gmail.com)
15:28:29 <d34dh0r53> ack
15:29:04 <d34dh0r53> #action d34dh0r53 email gtema (artem.goncharov@gmail.com) a reviewathon invite
15:29:34 <d34dh0r53> #action d34dh0r53 add reviewathon information to the Keystone Meetings page on the Openstack Wiki
15:30:04 <d34dh0r53> #topic open discussion
15:30:41 <d34dh0r53> domain scoping for "GET /v3/domains" (mhen)
15:30:50 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2041611
15:30:58 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/900028
15:32:55 <d34dh0r53> I think we need to review this in the reviewathon
15:34:08 <d34dh0r53> next up
15:34:15 <d34dh0r53> PCI DSS: analyzing failed login attempts (bbobrov)
15:34:21 <bbobrov> that's me
15:34:50 <bbobrov> PCI DSS requires us to analyze failed login attemps, for example, to catch bruteforce or password stuffing attacks
15:35:07 <d34dh0r53> right
15:35:12 <bbobrov> it is a bit hard to do right now with keystone
15:35:21 <bbobrov> we do have authenticate.failure events or even log messages
15:35:41 <bbobrov> but the logs messages don't say who failed to authenticate
15:35:51 <bbobrov> that is why we use the events
15:36:18 <bbobrov> however, we ran into the fact that most failures are just users running their scripts with bad passwords
15:36:31 <bbobrov> and we have many users. And chasing them one by one is not possible
15:37:27 <bbobrov> so a typical attack would be trying many passwords. We obviously cannot log the passwords or their hashes. But maybe we could log/emit notification with, for example, one last hash digit
15:37:59 <bbobrov> the question is, how useful would this feature be in keystone, and how it could be implemented, if useful
15:38:17 <d34dh0r53> yeah, I see the issue, differentiating between attacks and bad scripts
15:38:27 <d34dh0r53> I'm thinking about how sshd handles it
15:39:46 <bbobrov> i guess the general advice for sshd is to use keys instead of passwords
15:40:18 <bbobrov> which would be also good for keystone, no doubt, and even implementable
15:40:37 <d34dh0r53> right, but sshd logs that user-x tried y times IIRC
15:41:34 <d34dh0r53> I think it would definitely be useful for keystone to have something that would help with this PCI requirement
15:41:46 <bbobrov> anyway, i was thinking towards a logged_password auth plugin, that would replace the standard password auth
15:42:20 <bbobrov> since it would cover all password authentication, including via ldap
15:42:45 <bbobrov> how reasonable does it sound? Any obvious things against?
15:43:33 <d34dh0r53> It sounds reasonable to me, and nothing obvious jumps out
15:44:38 <bbobrov> cool, i will try to come up with a patch then
15:44:52 <bbobrov> (and i guess this needs a spec)
15:45:20 <d34dh0r53> yeah, this needs a spec, that's a good place to start
15:45:38 <bbobrov> actually, i might see a problem with the auth plugin now - the notification is emitted elsewhere
15:46:07 <bbobrov> the auth plugin can log, but can not notify
15:50:51 <d34dh0r53> ack, moving on for time
15:51:04 <d34dh0r53> #topic bug review
15:51:09 <d34dh0r53> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0
15:51:35 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2042744
15:51:53 <d34dh0r53> I think there's a bad package in Ubuntu
15:52:02 <d34dh0r53> but it may have been fixed
15:52:14 <d34dh0r53> has anyone here run into this issue?
15:53:15 <d34dh0r53> also #link https://bugs.launchpad.net/keystone/+bug/2044624
15:53:23 <d34dh0r53> thanks for submitting a fix for this bbobrov
15:54:15 <bbobrov> there is actually an open question what the correct response would be
15:54:30 <bbobrov> 200 or 401, given that the user does not exist any more
15:55:52 <bbobrov> easier was to just hide the error. The token at that point is useless anyway, since the user does note exist
15:56:14 <d34dh0r53> yeah, that seems fine to me
15:56:48 <d34dh0r53> I'll take a look at ubuntu and see if keystone-manage is still broken
15:56:55 <d34dh0r53> next up keystoneauth
15:57:03 <d34dh0r53> #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0
15:57:09 <d34dh0r53> err, pyton-keystoneclient
15:57:18 <d34dh0r53> which has no new issues
15:57:32 <d34dh0r53> now it's keystoneauths turn
15:57:33 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0
15:58:04 <d34dh0r53> nothing new there, on to keystonemiddleware
15:58:09 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0
15:58:22 <d34dh0r53> no new bugs there either
15:58:27 <d34dh0r53> #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0
15:58:40 <d34dh0r53> pycadf is good
15:58:44 <d34dh0r53> #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0
15:58:52 <d34dh0r53> ldappool is also good
15:58:56 <d34dh0r53> #topic conclusion
15:59:09 <d34dh0r53> I'm updating the Wiki with the reviewathon information
15:59:21 <d34dh0r53> if anyone would like an email invite please let me know
15:59:28 <bbobrov> please also update the wiki with the correct time and place for this meeting
15:59:35 <d34dh0r53> already done :)
15:59:41 <d34dh0r53> sorry about the confusion
15:59:52 <bbobrov> thanks
16:00:06 <d34dh0r53> Thanks all!
16:00:09 <d34dh0r53> #endmeeting