15:01:36 <dmendiza[m]> #startmeeting keystone
15:01:36 <opendevmeet> Meeting started Tue Jan 25 15:01:36 2022 UTC and is due to finish in 60 minutes.  The chair is dmendiza[m]. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:36 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:36 <opendevmeet> The meeting name has been set to 'keystone'
15:01:56 <dmendiza[m]> #topic Roll Call
15:02:01 <dmendiza[m]> Courtesy ping for ayoung, bbobrov, crisloma, d34dh0r53, dpar, dstanek, gagehugo, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, spilla, ruan_he, wxy, sonuk, vishakha,Ajay, rafaelweingartner, xek
15:02:07 <knikolla> o/
15:02:09 <d34dh0r53> o/
15:02:48 <dmendiza[m]> As usual, the agenda etherpad is over here: https://etherpad.opendev.org/p/keystone-weekly-meeting
15:03:21 <dmendiza[m]> OK, let's get started
15:03:31 <dmendiza[m]> #topic Review Past Meeting Action Items
15:03:57 <xek> o/
15:03:59 <dmendiza[m]> #link https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-01-18-15.00.html
15:04:01 <dmendiza[m]> We didn't have any
15:04:03 <dmendiza[m]> #topic Liaison Updates
15:04:09 <dmendiza[m]> knikolla: any updates this week?
15:04:29 <knikolla> no updates, need to catch up
15:04:41 <dmendiza[m]> You need some help with that?
15:04:47 <dmendiza[m]> I need to catch up on Oslo stuff
15:04:51 <dmendiza[m]> for Barbican
15:05:08 <dmendiza[m]> I could definitely keep an eye out for Keystone stuff too
15:06:49 <knikolla> thanks! we used to have a rotating bug duty position which involved keeping up with mailing list, bugs, etc. we can bring that back.
15:07:32 <dmendiza[m]> Yeah, that sounds interesting.  I'm sure d34dh0r53 would want to help out too
15:07:35 * dmendiza[m] nudges d34dh0r53
15:08:09 <knikolla> the etherpad is linked in the meeting agenda https://etherpad.opendev.org/p/keystone-l1-duty
15:08:16 <d34dh0r53> yeah, that sounds like something I can help with
15:09:57 <dmendiza[m]> Let's try to do that this week.
15:10:06 <dmendiza[m]> I'll take this week, and we can do a handoff next week
15:10:11 <dmendiza[m]> during this meeting
15:10:43 <dmendiza[m]> #info dmendiza[m] is on L1 duty this week
15:11:17 <dmendiza[m]> OK, moving on ...
15:11:37 <dmendiza[m]> #topic Specs
15:11:46 <dmendiza[m]> Let's start with OAuth 2.0
15:11:54 <dmendiza[m]> #link https://review.opendev.org/c/openstack/keystone-specs/+/813152
15:12:08 <dmendiza[m]> Looks like knikolla has a +2 review on it
15:12:26 <dmendiza[m]> maybe we can get gagehugo to take a look this week
15:12:37 <dmendiza[m]> it would be awesome to get that landed so h_asahina can start work on that
15:14:09 <dmendiza[m]> Moving on to S-RBAC
15:14:11 <dmendiza[m]> #link https://review.opendev.org/c/openstack/governance/+/815158
15:14:22 <dmendiza[m]> looks like the follow-up to the Yoga goals is still under review
15:14:28 <dmendiza[m]> I need to go review this myself
15:16:36 <dmendiza[m]> There's also two more specs that need review
15:16:41 <dmendiza[m]> related to S-RBAC
15:16:52 <dmendiza[m]> #link https://review.opendev.org/c/openstack/keystone-specs/+/818603
15:17:02 <dmendiza[m]> > Describe the need for a default manager role
15:17:05 <dmendiza[m]> and also
15:17:11 <dmendiza[m]> #link https://review.opendev.org/c/openstack/keystone-specs/+/818616
15:17:27 <dmendiza[m]> > Describe the need for a default service role
15:17:36 <dmendiza[m]> Both will be needed for S-RBAC
15:18:36 <dmendiza[m]> There's one more spec that is < 90 days old
15:18:41 <dmendiza[m]> #link https://review.opendev.org/c/openstack/keystone-specs/+/618144
15:19:46 <dmendiza[m]> > Reparent Projects
15:20:04 <dmendiza[m]> I have not looked into that last one at all.  I'll try to catch up on specs this week
15:21:09 <dmendiza[m]> #topic Open Discussion
15:21:22 <dmendiza[m]> Any other topics before we move on to the Bug Review?
15:26:04 <dmendiza[m]> OK, moving on ...
15:26:08 <dmendiza[m]> #topic Bug Review
15:26:21 <dmendiza[m]> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0
15:28:03 <dmendiza[m]> Hmm... Not sure how far back we need to look
15:28:09 <dmendiza[m]> let's start with mid-december
15:28:13 <dmendiza[m]> since it's been a while
15:28:16 <dmendiza[m]> #link https://bugs.launchpad.net/keystone/+bug/1954425
15:28:33 <dmendiza[m]> > Administrator can't create trusts on behalf of users
15:32:33 <dmendiza[m]> Interesting case
15:32:44 <dmendiza[m]> I don't have any historical context to answer why admins are not allowed
15:34:49 <knikolla> I know there are limitations with system scoped tokens when the operation requires a project_id in the context, but this bug seems to mention that this wouldn't be the case since all required parameters are in the request.
15:35:17 <knikolla> I don't have a strong opinion whether to allow admins to create trusts for users, or not.
15:35:29 <dmendiza[m]> Yeah, I was going to say, in the context of S-RBAC, a project-admin would be a persona that is used by an operator
15:35:41 <dmendiza[m]> so it would make sense for an operator to allow the creation of trusts
15:35:51 <dmendiza[m]> *to allow an operator to create them
15:36:13 <dmendiza[m]> and maybe it also makes sense for a project-manager to be able to create trusts for users in their project?
15:39:33 <dmendiza[m]> I'll take this bug
15:39:50 <dmendiza[m]> Next
15:39:51 <dmendiza[m]> #link https://bugs.launchpad.net/keystone/+bug/1954665
15:39:52 <knikolla> i'm a bit hesitant, just because a trust delegates permissions from a user to another user, and my spider sense is tingling when you're delegating someone else's permissions, even if you're an admin.
15:40:48 <dmendiza[m]> perhaps a better option would be to move the hard-coded deny to a policy
15:41:04 <dmendiza[m]> then someone who wants to do it can create a custom policy for that trust endpoint
15:42:23 <knikolla> I delegate to people with more of a security background than I have on this.
15:42:44 <knikolla> You can accomplish a lot of what they're trying to do by using other mechanisms already.
15:43:01 <knikolla> Groups, new users, application credentials, etc.
15:44:26 <knikolla> I think this also the only mechanism that we have that allows impersonation, with the token actually getting the user_id of the trustor.
15:45:48 <dmendiza[m]> Hmmm... good points
15:46:02 <dmendiza[m]> Maybe we can talk about it some more for the Friday reviewathon
15:47:01 <knikolla> sounds good
15:47:51 <dmendiza[m]> OK, moving on to
15:47:52 <dmendiza[m]> >  default opt out from non-existing event (authenticate.failed)
15:48:03 <dmendiza[m]> (linked above)
15:48:18 <dmendiza[m]> Seems pretty straightforward
15:48:28 <dmendiza[m]> looks like there may be a mismatch in queue names
15:51:11 <knikolla> even though there was a typo, we're still changing default behavior
15:51:54 <knikolla> At the very minimum it requires a release note
15:52:37 <knikolla> On the other hand of the spectrum we can update the config text to mention that only authentication failures are sent.
16:00:18 <dmendiza[m]> I think the issue is that we're using the string as defined in pycadf
16:00:35 <dmendiza[m]> #link https://opendev.org/openstack/keystone/src/branch/master/keystone/notifications.py#L587-L589
16:00:51 <dmendiza[m]> which is defined as "failure"
16:00:54 <dmendiza[m]> #link https://opendev.org/openstack/pycadf/src/branch/master/pycadf/cadftaxonomy.py#L76
16:01:04 <dmendiza[m]> so we will never emit an event called "failed"
16:01:56 <dmendiza[m]> In any case, we're out of time for the week
16:01:59 <dmendiza[m]> we can pick this again next week
16:02:06 <dmendiza[m]> thanks for joining, y'all!
16:02:14 <dmendiza[m]> #endmeeting