15:01:01 <dmendiza[m]> #startmeeting keystone
15:01:01 <opendevmeet> Meeting started Tue May 10 15:01:01 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:01 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:01 <opendevmeet> The meeting name has been set to 'keystone'
15:01:06 <knikolla> o/
15:01:19 <dmendiza[m]> #topic Roll Call
15:01:22 <h-asahina> o/
15:01:44 <bbobrov> henlo
15:02:11 <dmendiza[m]> Hi y'all!
15:03:02 <dmendiza[m]> As usual the agenda is over here:
15:03:17 <dmendiza[m]> #link https://etherpad.opendev.org/p/keystone-weekly-meeting
15:03:25 <dmendiza[m]> Courtesy ping for admiyo, bbobrov, crisloma, d34dh0r53, dpar, dstanek, hrybacki, knikolla, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, ruan_he, wxy, sonuk, vishakha, Ajay, rafaelwe
15:03:41 <d34dh0r53> o/
15:03:46 <dmendiza[m]> #topic Review Past Meeting Action Items
15:03:48 <dmendiza[m]> #link https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-05-03-15.26.html
15:03:49 <d34dh0r53> lurking today, conflict with another meeting
15:03:55 <dmendiza[m]> We didn't have any 🎉
15:04:23 <dmendiza[m]> #topic Liaison Updates
15:04:34 <dmendiza[m]> I don't have any updates this week
15:05:11 <dmendiza[m]> ...
15:05:15 <dmendiza[m]> Although now that I think about it
15:05:22 <dmendiza[m]> Zed-1 Milestone is next week
15:05:32 <dmendiza[m]> #link https://releases.openstack.org/zed/schedule.html
15:05:42 <dmendiza[m]> I'm not sure if we have any deadlines for Zed-1?
15:06:43 <dmendiza[m]> I'm guessing probably not
15:09:17 <dmendiza[m]> OK, moving on
15:09:21 <dmendiza[m]> #topic OAuth 2.0
15:09:27 <dmendiza[m]> Do we have any updates this week?
15:09:57 <h-asahina> From us no update.
15:11:01 <h-asahina> We are planning to apply comments within this month.
15:11:08 <dmendiza[m]> thanks h-asahina
15:11:52 <h-asahina> thank you too for your review :)
15:12:21 <dmendiza[m]> #topic Secure RBAC
15:12:44 <dmendiza[m]> We had a pop-up meeting this morning right before this meeting.
15:13:05 <dmendiza[m]> We discussed the "service" role spec, and gmann will be updating some comments there with the discussion points.
15:13:25 <dmendiza[m]> We also agreed to enable the new defaults in Keystone this cycle
15:13:39 <dmendiza[m]> enabled by default, that is
15:13:48 <dmendiza[m]> new defaults by default. :D
15:14:00 <dmendiza[m]> So we'll work on a patch for that.
15:14:28 <dmendiza[m]> The next pop-up will be in 2 weeks on May 24th @ 1400 UTC
15:15:10 <dmendiza[m]> Any questions/comments about Secure RBAC?
15:17:31 <dmendiza[m]> OK, moving on
15:17:42 <dmendiza[m]> #topic Gate inherited assignments from parent (bbobrov)
15:17:49 <bbobrov> hi
15:17:50 <dmendiza[m]> #link https://review.opendev.org/c/openstack/keystone-specs/+/334364
15:17:59 <bbobrov> this spec is from 2016, so we can send it to school soon
15:18:07 <dmendiza[m]> haha
15:18:11 <bbobrov> originally it was proposed by Henry Nash when he was working on his hierarchical-everything project
15:18:21 <bbobrov> i reworked the spec and simplified it
15:18:30 <bbobrov> the tldr version is that some projects in the hierarchy need to be exempt from inherited role assignments
15:18:45 <bbobrov> my current proposal is to make it as simple as possible. The project has a tag -> it is exempt. Its subtree is not affected
15:19:16 <bbobrov> we can also affect the subtree. It should not be much harder, but i do not have a usecase for that - we use an almost-flat hierarchy in my company
15:19:34 <bbobrov> please comment and review
15:20:02 <bbobrov> i will implement it when if accepted
15:20:54 <knikolla> thanks! makes sense to me
15:23:09 <dmendiza[m]> yeah, we'll review the spec and go from there
15:24:06 <dmendiza[m]> Anything else on this topic for now? bbobrov ?
15:24:13 <bbobrov> nope, thanks
15:24:31 <dmendiza[m]> Cool, I'll add the spec to the Reviewathon this Friday
15:25:28 <dmendiza[m]> #topic bandit seems to be broken, cannot build keystone from git
15:25:39 <dmendiza[m]> I think this is admiyo 's topic
15:25:49 <dmendiza[m]> I have not tried to build a fresh clone
15:25:56 <dmendiza[m]> so I'm not sure if this is currently an issue?
15:27:46 <dmendiza[m]> I'll try to reproduce it this week and see what happens
15:27:52 <dmendiza[m]> #topic Bug Review
15:27:58 <dmendiza[m]> Let's start with the one that bbobrov added
15:28:07 <dmendiza[m]> #link https://bugs.launchpad.net/keystone/+bug/1950325
15:29:03 <bbobrov> thank you
15:29:10 <bbobrov> i added it on top because it is not new
15:29:13 <bbobrov> Past discussion about this bug: https://meetings.opendev.org/irclogs/%23openstack-keystone/%23openstack-keystone.2021-11-09.log.html#t2021-11-09T15:29:30
15:29:25 <bbobrov> I am hitting the bug more and more often and would like to fix it
15:29:43 <bbobrov> What was the agreement on the way to fix it? Do we return the domains the user has access to? Do we return only 1 domain (the one the token is scoped to)? Do we return all domains?
15:29:54 <bbobrov> In my company domain list is basically public, so i do not have a preference
15:31:31 <knikolla> if it's domain scoped it should probably only return the domain in the token
15:32:20 <knikolla> or at least follow the same behavior of listing projects with a project scoped token (?)
15:33:09 <bbobrov> hmm, i wonder what the behavior will be
15:33:13 <bbobrov> let me try real quick
15:35:57 <knikolla> i think my comment from back then makes sense. if /projects returns the domain in the unfiltered list, then /projects?is_domain=true should also return it
15:36:24 <knikolla> since it's weird to provide a subset that gives you a result not included in the larger set
15:37:07 <knikolla> oh, the flag doesn't act as a filter.
15:37:12 <knikolla> i need more coffee
15:38:17 <bbobrov> it does not return the domain
15:38:54 <knikolla> quoting "redrobot	sounds like GET /v3/projects?is_domain=true should be the same as GET /v3/domains"
15:39:17 <bbobrov> this is also something i was thinking about
15:40:11 <bbobrov> also "project list" seems to return projects that i do not have access to
15:40:38 <knikolla> if you are scoped to the domain, you can query the projects in the domain IIRC
15:40:56 <bbobrov> i am scoped to a "is_admin" project
15:41:12 <bbobrov> (old setup, no system-scope yet)
15:41:30 <knikolla> if you are admin, you can query everything
15:41:43 <bbobrov> oof
15:42:16 <bbobrov> ok, at least nobody thinks that 40x or empty list is the way to go, right?
15:43:11 <knikolla> it depends on what /v3/domains returns.
15:43:28 <knikolla> i think v3/projects?is_domain=True should be equal to that
15:44:24 <dmendiza[m]> ^^^ I still think this too
15:44:26 <knikolla> i don't know if having a role on a domain allows you to query that domain, so empty list may be a valid response.
15:44:30 * dmendiza[m] is formerly known as redrobot
15:45:11 <bbobrov> ok. I will then propose a change that will make that request behave the same way as a request to /v3/domains, and we can go from there
15:45:32 <dmendiza[m]> sounds good bbobrov
15:45:41 <bbobrov> thanks, i have nothing else about this topic
15:45:50 <dmendiza[m]> Cool, thanks
15:45:58 <dmendiza[m]> Moving on to the rest of the bug review
15:46:06 <knikolla> if you're looking for domains a user can scope to, we also have this https://docs.openstack.org/api-ref/identity/v3/?expanded=get-available-domain-scopes-detail#get-available-domain-scopes
15:46:11 <dmendiza[m]> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0
15:47:00 <dmendiza[m]> I don't think we've looked at this one yet:
15:47:05 <dmendiza[m]> #link https://bugs.launchpad.net/keystone/+bug/1970932
15:47:18 <dmendiza[m]> >
15:47:18 <dmendiza[m]> Domain Admins possibility for privilege escalation
15:49:37 <knikolla> looks like expected behavior with the current state of the policy world
15:50:08 <dmendiza[m]> Yeah, title seems way scarier than it actually is
15:50:19 <knikolla> sounds like is_admin_project is kicking in and just checking the name
15:50:29 <dmendiza[m]> oof
15:51:08 <knikolla> so this is most probably solved by the new policy defaults
15:51:39 <dmendiza[m]> Yup.  I'll comment on there
15:51:49 <dmendiza[m]> next
15:51:50 <dmendiza[m]> #link https://bugs.launchpad.net/keystone/+bug/1971691
15:52:05 <dmendiza[m]> >  Support application credentials as a source for EC2 auth
15:52:42 <bbobrov> it feels more like a feature request
15:52:54 <dmendiza[m]> Yep, sure does
15:53:03 <knikolla> interesting feature idea. extends what we did for oauth 2.0  client credentials using app creds
15:53:18 <knikolla> we could use app creds as an engine for those too.
15:53:36 <bbobrov> the reporter and i work in the same company, so i am interested in the feature too, but i do not have a direct understanding the usecase
15:54:02 <bbobrov> but the idea is indeed that app creds are used as an engine for ec2 creds
15:54:53 <knikolla> This definitely needs a spec
15:55:58 <dmendiza[m]> Yeah, I'll leave a comment to please write a spec with a link to our spec doc
15:56:42 <dmendiza[m]> That's it for keystone bugs
15:56:44 <dmendiza[m]> moving on
15:56:45 <dmendiza[m]> #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0
15:56:56 <dmendiza[m]> No new python-keystoneclient bugs
15:57:12 <dmendiza[m]> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0
15:57:34 <dmendiza[m]> No new keystoneauth bugs
15:58:01 <dmendiza[m]> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0
15:58:09 <dmendiza[m]> No new keystonemiddleware bugs
15:58:19 <dmendiza[m]> #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0
15:58:25 <dmendiza[m]> and no new pycadf bugs
15:58:35 <dmendiza[m]> #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0
15:58:39 <dmendiza[m]> and no new ldappool bugs
15:58:41 <dmendiza[m]> ...
15:58:49 <dmendiza[m]> And we're just about out of time.
15:58:56 <dmendiza[m]> Thanks for joining, y'all!
15:58:59 <dmendiza[m]> #endmeeting