| opendevreview | Takashi Kajinami proposed openstack/keystonemiddleware master: Remove six https://review.opendev.org/c/openstack/keystonemiddleware/+/841180 | 00:09 |
|---|---|---|
| *** dviroel|afk is now known as dviroel | 11:28 | |
| knikolla | gmann: is there a srbac meeting today? if not, when is it? | 13:18 |
| *** dasm|off is now known as dasm | 13:31 | |
| gmann | knikolla: yes, its in an 5 min from now https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popup_Team#Meeting | 13:55 |
| gmann | knikolla: dansmith dmendiza[m] RBAC meeting started in https://meet.google.com/gie-derw-eer | 14:01 |
| opendevreview | Julia Kreger proposed openstack/keystoneauth master: WIP: Only include parameters not present upon redirect https://review.opendev.org/c/openstack/keystoneauth/+/841169 | 14:13 |
| *** dviroel is now known as dviroel|lunch|afk | 14:53 | |
| dmendiza[m] | #startmeeting keystone | 15: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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:01 |
| knikolla | o/ | 15:01 |
| dmendiza[m] | #topic Roll Call | 15:01 |
| h-asahina | o/ | 15:01 |
| bbobrov | henlo | 15:01 |
| dmendiza[m] | Hi y'all! | 15:02 |
| dmendiza[m] | As usual the agenda is over here: | 15:03 |
| dmendiza[m] | #link https://etherpad.opendev.org/p/keystone-weekly-meeting | 15:03 |
| 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 |
| d34dh0r53 | o/ | 15:03 |
| dmendiza[m] | #topic Review Past Meeting Action Items | 15:03 |
| dmendiza[m] | #link https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-05-03-15.26.html | 15:03 |
| d34dh0r53 | lurking today, conflict with another meeting | 15:03 |
| dmendiza[m] | We didn't have any š | 15:03 |
| dmendiza[m] | #topic Liaison Updates | 15:04 |
| dmendiza[m] | I don't have any updates this week | 15:04 |
| dmendiza[m] | ... | 15:05 |
| dmendiza[m] | Although now that I think about it | 15:05 |
| dmendiza[m] | Zed-1 Milestone is next week | 15:05 |
| dmendiza[m] | #link https://releases.openstack.org/zed/schedule.html | 15:05 |
| dmendiza[m] | I'm not sure if we have any deadlines for Zed-1? | 15:05 |
| dmendiza[m] | I'm guessing probably not | 15:06 |
| dmendiza[m] | OK, moving on | 15:09 |
| dmendiza[m] | #topic OAuth 2.0 | 15:09 |
| dmendiza[m] | Do we have any updates this week? | 15:09 |
| h-asahina | From us no update. | 15:09 |
| h-asahina | We are planning to apply comments within this month. | 15:11 |
| *** afaranha__ is now known as afaranha | 15:11 | |
| dmendiza[m] | thanks h-asahina | 15:11 |
| h-asahina | thank you too for your review :) | 15:11 |
| dmendiza[m] | #topic Secure RBAC | 15:12 |
| dmendiza[m] | We had a pop-up meeting this morning right before this meeting. | 15:12 |
| dmendiza[m] | We discussed the "service" role spec, and gmann will be updating some comments there with the discussion points. | 15:13 |
| dmendiza[m] | We also agreed to enable the new defaults in Keystone this cycle | 15:13 |
| dmendiza[m] | enabled by default, that is | 15:13 |
| dmendiza[m] | new defaults by default. :D | 15:13 |
| dmendiza[m] | So we'll work on a patch for that. | 15:14 |
| dmendiza[m] | The next pop-up will be in 2 weeks on May 24th @ 1400 UTC | 15:14 |
| dmendiza[m] | Any questions/comments about Secure RBAC? | 15:15 |
| dmendiza[m] | OK, moving on | 15:17 |
| dmendiza[m] | #topic Gate inherited assignments from parent (bbobrov) | 15:17 |
| bbobrov | hi | 15:17 |
| dmendiza[m] | #link https://review.opendev.org/c/openstack/keystone-specs/+/334364 | 15:17 |
| bbobrov | this spec is from 2016, so we can send it to school soon | 15:17 |
| dmendiza[m] | haha | 15:18 |
| bbobrov | originally it was proposed by Henry Nash when he was working on his hierarchical-everything project | 15:18 |
| bbobrov | i reworked the spec and simplified it | 15:18 |
| bbobrov | the tldr version is that some projects in the hierarchy need to be exempt from inherited role assignments | 15:18 |
| 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:18 |
| 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 |
| bbobrov | please comment and review | 15:19 |
| bbobrov | i will implement it when if accepted | 15:20 |
| knikolla | thanks! makes sense to me | 15:20 |
| dmendiza[m] | yeah, we'll review the spec and go from there | 15:23 |
| dmendiza[m] | Anything else on this topic for now? bbobrov ? | 15:24 |
| bbobrov | nope, thanks | 15:24 |
| dmendiza[m] | Cool, I'll add the spec to the Reviewathon this Friday | 15:24 |
| dmendiza[m] | #topic bandit seems to be broken, cannot build keystone from git | 15:25 |
| dmendiza[m] | I think this is admiyo 's topic | 15:25 |
| dmendiza[m] | I have not tried to build a fresh clone | 15:25 |
| dmendiza[m] | so I'm not sure if this is currently an issue? | 15:25 |
| dmendiza[m] | I'll try to reproduce it this week and see what happens | 15:27 |
| dmendiza[m] | #topic Bug Review | 15:27 |
| dmendiza[m] | Let's start with the one that bbobrov added | 15:27 |
| dmendiza[m] | #link https://bugs.launchpad.net/keystone/+bug/1950325 | 15:28 |
| bbobrov | thank you | 15:29 |
| bbobrov | i added it on top because it is not new | 15:29 |
| 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 |
| bbobrov | I am hitting the bug more and more often and would like to fix it | 15:29 |
| 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 |
| bbobrov | In my company domain list is basically public, so i do not have a preference | 15:29 |
| knikolla | if it's domain scoped it should probably only return the domain in the token | 15:31 |
| knikolla | or at least follow the same behavior of listing projects with a project scoped token (?) | 15:32 |
| bbobrov | hmm, i wonder what the behavior will be | 15:33 |
| bbobrov | let me try real quick | 15:33 |
| 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:35 |
| knikolla | since it's weird to provide a subset that gives you a result not included in the larger set | 15:36 |
| knikolla | oh, the flag doesn't act as a filter. | 15:37 |
| knikolla | i need more coffee | 15:37 |
| bbobrov | it does not return the domain | 15:38 |
| knikolla | quoting "redrobotsounds like GET /v3/projects?is_domain=true should be the same as GET /v3/domains" | 15:38 |
| bbobrov | this is also something i was thinking about | 15:39 |
| bbobrov | also "project list" seems to return projects that i do not have access to | 15:40 |
| knikolla | if you are scoped to the domain, you can query the projects in the domain IIRC | 15:40 |
| bbobrov | i am scoped to a "is_admin" project | 15:40 |
| bbobrov | (old setup, no system-scope yet) | 15:41 |
| knikolla | if you are admin, you can query everything | 15:41 |
| bbobrov | oof | 15:41 |
| bbobrov | ok, at least nobody thinks that 40x or empty list is the way to go, right? | 15:42 |
| knikolla | it depends on what /v3/domains returns. | 15:43 |
| knikolla | i think v3/projects?is_domain=True should be equal to that | 15:43 |
| dmendiza[m] | ^^^ I still think this too | 15:44 |
| 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 |
| * dmendiza[m] is formerly known as redrobot | 15:44 | |
| 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 |
| dmendiza[m] | sounds good bbobrov | 15:45 |
| bbobrov | thanks, i have nothing else about this topic | 15:45 |
| dmendiza[m] | Cool, thanks | 15:45 |
| dmendiza[m] | Moving on to the rest of the bug review | 15:45 |
| 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 |
| dmendiza[m] | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:46 |
| dmendiza[m] | I don't think we've looked at this one yet: | 15:47 |
| dmendiza[m] | #link https://bugs.launchpad.net/keystone/+bug/1970932 | 15:47 |
| dmendiza[m] | > | 15:47 |
| dmendiza[m] | Domain Admins possibility for privilege escalation | 15:47 |
| knikolla | looks like expected behavior with the current state of the policy world | 15:49 |
| dmendiza[m] | Yeah, title seems way scarier than it actually is | 15:50 |
| knikolla | sounds like is_admin_project is kicking in and just checking the name | 15:50 |
| dmendiza[m] | oof | 15:50 |
| knikolla | so this is most probably solved by the new policy defaults | 15:51 |
| dmendiza[m] | Yup. I'll comment on there | 15:51 |
| dmendiza[m] | next | 15:51 |
| dmendiza[m] | #link https://bugs.launchpad.net/keystone/+bug/1971691 | 15:51 |
| dmendiza[m] | > Support application credentials as a source for EC2 auth | 15:52 |
| bbobrov | it feels more like a feature request | 15:52 |
| dmendiza[m] | Yep, sure does | 15:52 |
| knikolla | interesting feature idea. extends what we did for oauth 2.0 client credentials using app creds | 15:53 |
| knikolla | we could use app creds as an engine for those too. | 15:53 |
| 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:53 |
| bbobrov | but the idea is indeed that app creds are used as an engine for ec2 creds | 15:54 |
| knikolla | This definitely needs a spec | 15:54 |
| dmendiza[m] | Yeah, I'll leave a comment to please write a spec with a link to our spec doc | 15:55 |
| dmendiza[m] | That's it for keystone bugs | 15:56 |
| dmendiza[m] | moving on | 15:56 |
| dmendiza[m] | #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 | 15:56 |
| dmendiza[m] | No new python-keystoneclient bugs | 15:56 |
| dmendiza[m] | #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 | 15:57 |
| dmendiza[m] | No new keystoneauth bugs | 15:57 |
| dmendiza[m] | #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 | 15:58 |
| dmendiza[m] | No new keystonemiddleware bugs | 15:58 |
| dmendiza[m] | #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 | 15:58 |
| dmendiza[m] | and no new pycadf bugs | 15:58 |
| dmendiza[m] | #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 | 15:58 |
| dmendiza[m] | and no new ldappool bugs | 15:58 |
| dmendiza[m] | ... | 15:58 |
| dmendiza[m] | And we're just about out of time. | 15:58 |
| dmendiza[m] | Thanks for joining, y'all! | 15:58 |
| dmendiza[m] | #endmeeting | 15:58 |
| opendevmeet | Meeting ended Tue May 10 15:58:59 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:58 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-05-10-15.01.html | 15:58 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-05-10-15.01.txt | 15:58 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-05-10-15.01.log.html | 15:58 |
| alistarle | Hey folks, seems I miss the open discussion this time, so if anyone left I have a question regarding groups in mapping for federation | 15:59 |
| dmendiza[m] | Hi alistarle | 16:00 |
| alistarle | It seems that we can only assign one group at a time in the mapping, and Keystone doesn't iterate over the array of the OIDC claim | 16:00 |
| alistarle | I saw a patch to fix that in the project creation workflow : https://review.opendev.org/c/openstack/keystone/+/727891, but nothing seems to be done group side, can I propose a patch for that ? | 16:01 |
| alistarle | More precisely, keystone can't assign multiple group at a time (despite the OIDC claim is well interpreted as a python array), and it require the mapping to be done like that, not very generic: { | 16:03 |
| alistarle | "local": [ | 16:03 |
| alistarle | { | 16:03 |
| alistarle | "group": { | 16:03 |
| alistarle | "name": "/dev" | 16:03 |
| alistarle | } | 16:03 |
| alistarle | } | 16:03 |
| alistarle | ], | 16:03 |
| alistarle | "remote": [ | 16:03 |
| alistarle | { | 16:03 |
| alistarle | "type": "HTTP_OIDC_GROUPS", | 16:03 |
| alistarle | "any_one_of": [ | 16:03 |
| alistarle | "/dev" | 16:03 |
| alistarle | ] | 16:03 |
| alistarle | } | 16:03 |
| alistarle | ] | 16:03 |
| alistarle | }, | 16:03 |
| alistarle | { | 16:03 |
| alistarle | "local": [ | 16:03 |
| alistarle | { | 16:03 |
| alistarle | "group": { | 16:03 |
| alistarle | "name": "/ops" | 16:03 |
| alistarle | } | 16:03 |
| alistarle | } | 16:03 |
| alistarle | ], | 16:03 |
| alistarle | "remote": [ | 16:03 |
| alistarle | { | 16:03 |
| alistarle | "type": "HTTP_OIDC_GROUPS", | 16:03 |
| alistarle | "any_one_of": [ | 16:03 |
| alistarle | "/ops" | 16:03 |
| alistarle | ] | 16:03 |
| alistarle | } | 16:03 |
| alistarle | ] | 16:03 |
| alistarle | } | 16:03 |
| dmendiza[m] | d34dh0r53 is my go-to federation guy | 16:08 |
| dmendiza[m] | d34dh0r53: what do you think about ^^^ | 16:08 |
| dmendiza[m] | ? | 16:08 |
| *** dasm is now known as dasm|bbl | 17:27 | |
| d34dh0r53 | Yeah, that is a limitation of the mapping engine AFAIK. A patch would be great, Iād be happy to review it | 17:56 |
| d34dh0r53 | dmendiza[m], alistarle: ^ | 17:56 |
| opendevreview | Merged openstack/pycadf master: Drop lower-constraints.txt and its testing https://review.opendev.org/c/openstack/pycadf/+/840062 | 18:32 |
| *** dviroel|lunch|afk is now known as dviroel\ | 18:53 | |
| *** dviroel\ is now known as dviroel | 18:53 | |
| *** dviroel is now known as dviroel|out | 21:22 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!