| opendevreview | Yi Feng proposed openstack/keystonemiddleware master: [WIP] Add FT for External OAuth2.0 Server Support https://review.opendev.org/c/openstack/keystonemiddleware/+/899911 | 01:34 |
|---|---|---|
| *** mhen_ is now known as mhen | 02:11 | |
| *** jph5 is now known as jph1 | 08:19 | |
| *** jph1 is now known as jph | 08:20 | |
| zigo | Deprecated use of the datetime module is all over the place in Keystone, which fails unit tests with Python 3.12 ... :( | 09:35 |
| opendevreview | Rafael Weingartner proposed openstack/keystone master: Keystone to honor the "domain" attribute mapping rules. https://review.opendev.org/c/openstack/keystone/+/739966 | 10:45 |
| opendevreview | Rafael Weingartner proposed openstack/keystone master: Keystone to honor the "domain" attribute mapping rules. https://review.opendev.org/c/openstack/keystone/+/739966 | 12:04 |
| bbobrov | zigo: lets talk about it at the meeting today | 14:56 |
| zigo | Thanks. I wont be there though ... | 14:56 |
| *** d34dh0r5- is now known as d34dh0r53 | 14:59 | |
| d34dh0r53 | #startmeeting keystone | 15:00 |
| opendevmeet | Meeting started Wed Dec 13 15:00:38 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:00 |
| d34dh0r53 | #topic roll call | 15:00 |
| 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],mharley | 15:00 |
| xek | o/ | 15:01 |
| d34dh0r53 | o/ | 15:01 |
| bbobrov | o/ | 15:01 |
| d34dh0r53 | #topic review past meeting work items | 15:03 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2023/keystone.2023-11-29-15.00.html | 15:03 |
| d34dh0r53 | d34dh0r53 Look into adding/restoring a known issues section to our documentation | 15:03 |
| d34dh0r53 | no update on this | 15:03 |
| d34dh0r53 | #action d34dh0r53 Look into adding/restoring a known issues section to our documentation | 15:03 |
| d34dh0r53 | d34dh0r53 Look into adding/restoring a known issues section to our documentation | 15:03 |
| d34dh0r53 | nor this :/ | 15:03 |
| d34dh0r53 | #action d34dh0r53 Look into adding/restoring a known issues section to our documentation | 15:03 |
| d34dh0r53 | d34dh0r53 email gtema (artem.goncharov@gmail.com) a reviewathon invite | 15:04 |
| d34dh0r53 | this has been done | 15:04 |
| d34dh0r53 | d34dh0r53 add reviewathon information to the Keystone Meetings page on the Openstack Wiki | 15:04 |
| d34dh0r53 | this one is done as well | 15:04 |
| d34dh0r53 | That does it for the past meeting action items | 15:04 |
| mharley | o/ | 15:04 |
| gtema | thks | 15:04 |
| d34dh0r53 | next up we have liaison updates | 15:04 |
| d34dh0r53 | #topic liaison updates | 15:04 |
| zigo | Didn't know that meeting was now... so: o/ | 15:04 |
| d34dh0r53 | nothing from release or vmt | 15:04 |
| d34dh0r53 | o/ zigo, welcome | 15:05 |
| d34dh0r53 | any other liaison updates? | 15:05 |
| d34dh0r53 | cool | 15:06 |
| d34dh0r53 | #topic specification OAuth 2.0 (hiromu) | 15:06 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext | 15:06 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability | 15:06 |
| d34dh0r53 | External OAuth 2.0 Specification | 15:06 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 | 15:06 |
| d34dh0r53 | OAuth 2.0 Implementation | 15:06 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls | 15:06 |
| d34dh0r53 | OAuth 2.0 Documentation | 15:06 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone/+/838108 | 15:06 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 | 15:06 |
| d34dh0r53 | hiromu: any updates or needs? | 15:07 |
| d34dh0r53 | ok, moving on | 15:09 |
| d34dh0r53 | #topic specification Secure RBAC (dmendiza[m]) | 15:09 |
| d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:09 |
| d34dh0r53 | 2024.1 Release Timeline | 15:09 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_new_defaults=True | 15:09 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_scope=True | 15:09 |
| dmendiza[m] | 🙋 | 15:12 |
| d34dh0r53 | o/ dmendiza[m] | 15:12 |
| dmendiza[m] | Heya! | 15:12 |
| dmendiza[m] | Sorry, only half paying attention. Currently also trying to listen to a company meeting. | 15:13 |
| dmendiza[m] | Yeah, so I've been updating the policies to allow project-admin to do system things. | 15:13 |
| d34dh0r53 | ack, me too | 15:13 |
| dmendiza[m] | I've got a patch up that is (expectedly) failing tempest because of the policy change: | 15:13 |
| dmendiza[m] | #link https://review.opendev.org/c/openstack/keystone/+/902730 | 15:13 |
| dmendiza[m] | Working on the tempest patch next, and then I'll update this to make the srbac job non-voting | 15:14 |
| dmendiza[m] | then a follow up to make it voting again once the tempest patch lands | 15:14 |
| d34dh0r53 | sweet, thanks for the work on that and good find :) | 15:15 |
| d34dh0r53 | next up | 15:16 |
| d34dh0r53 | #topic specification Add schema version and support to "domain" attribute in mapping rules (gtema) | 15:17 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/748042 | 15:17 |
| d34dh0r53 | this has merged | 15:17 |
| d34dh0r53 | woot | 15:17 |
| gtema | thanks | 15:17 |
| d34dh0r53 | I saw a follow on patch that I need to review | 15:17 |
| gtema | yes, now that spec needs implementation and Rafael revived old change | 15:18 |
| d34dh0r53 | sweet, do you happen to have a link handy? | 15:18 |
| gtema | https://review.opendev.org/c/openstack/keystone/+/739966 | 15:19 |
| d34dh0r53 | thanks gtema ! | 15:19 |
| d34dh0r53 | cool, moving on | 15:21 |
| d34dh0r53 | #topic open discussion | 15:21 |
| d34dh0r53 | domain scoping for "GET /v3/domains" (mhen) | 15:21 |
| d34dh0r53 | bug: #link https://bugs.launchpad.net/keystone/+bug/2041611 | 15:21 |
| d34dh0r53 | patch: #link https://review.opendev.org/c/openstack/keystone/+/900028 | 15:21 |
| d34dh0r53 | looking for reviewers | 15:21 |
| d34dh0r53 | Zuul tests fail | 15:21 |
| d34dh0r53 | "keystone_tempest_plugin.tests.rbac" seems to be the culprit | 15:21 |
| d34dh0r53 | how can patches of the keystone_tempest_plugin be integrated in a way that the patchset above incorporates it in its testing? (i.e. interlinked patchsets between keystone and keystone_tempest_plugin that depend on each other) | 15:21 |
| d34dh0r53 | I think this may be an old open discussion item but I wanted to raise it just in case | 15:22 |
| bbobrov | i am actually not sure that it is a good thing to merge | 15:22 |
| d34dh0r53 | I'm not either | 15:23 |
| bbobrov | it feels like a violation of an API stability contract | 15:23 |
| bbobrov | this is an old broadly used endpoint, and i am sure there are deployments that use the current response | 15:23 |
| bbobrov | i have a feeling that there was a discussion about this several years ago... | 15:24 |
| zigo | Is it time to talk about py3.12 ? :) | 15:26 |
| d34dh0r53 | yeah, I think we can remove the previous topic from the open discussion list and see if mhen gets back to us on bbobrov's comments on the review | 15:27 |
| bbobrov | https://meetings.opendev.org/meetings/keystone/2021/keystone.2021-11-09-15.00.html - it was discussed here | 15:27 |
| bbobrov | zigo: i think we shall get to it during the bug review, i have filed https://bugs.launchpad.net/keystone/+bug/2046355 | 15:27 |
| zigo | I tried building Keystone in Unstable, and this lead me to 2000+ unit test failures. | 15:28 |
| zigo | Most seem due to the way Keystone uses datetime. | 15:28 |
| zigo | For example utcfromtimestamp() is removed from Py 3.12. | 15:28 |
| zigo | See https://docs.python.org/3/whatsnew/3.12.html | 15:28 |
| bbobrov | previous discussion about the scope for listing domains: #link https://meetings.opendev.org/meetings/keystone/2021/keystone.2021-11-09-15.00.html | 15:28 |
| zigo | I unfortunately didn't have enough time to investigate it enough though ... | 15:29 |
| zigo | But if there's a bunch of you with enough time to try unit testing with 3.12, that'd be super useful. | 15:29 |
| zigo | See how many bugs I need to deal with: https://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=team%2Bopenstack%40tracker.debian.org&archive=no&raw=yes&bug-rev=yes&pend-exc=fixed&pend-exc=done | 15:29 |
| bbobrov | zigo: i think that utcfromtimestamp is not removed, but deprecated | 15:29 |
| zigo | We're at 47, we were at 66 yesterday ... | 15:29 |
| zigo | bbobrov: Correctly, but that makes the unit tests fail... | 15:30 |
| zigo | So it got to be fixed. | 15:30 |
| bbobrov | well, we can probably mute it for now somehow | 15:30 |
| zigo | Why not fixing completely? It didn't seem that hard to do... | 15:30 |
| dmendiza[m] | zigo we can start by adding a py312 gate, but it's not in scope for 2024.1 | 15:30 |
| dmendiza[m] | #link https://governance.openstack.org/tc/reference/runtimes/2024.1.html | 15:30 |
| zigo | atetime.datetime.utcnow() -> datetime.datetime.now(datetime.UTC) | 15:31 |
| bbobrov | zigo: well, first of all, they return different string representations | 15:31 |
| zigo | (this is an example from keystone/identity/backends/sql.py line 135, but there are more ...) | 15:31 |
| bbobrov | zigo: it also needs to be fixed in oslo.utils | 15:31 |
| zigo | Whatever you feel like works will work for me! :) | 15:32 |
| d34dh0r53 | that's what I was looking for, thanks dmendiza[m] | 15:32 |
| dmendiza[m] | I would think 2024.2 will have 3.12 as a tested runtime, and we'll likely run into all those issues then. | 15:32 |
| zigo | Once these 2000+ failures are silenced, I believe there will be more to fix, but I have no idea what and how much. | 15:34 |
| zigo | bbobrov: Are you volunteering to try fixing all py3.12 issues ? :) | 15:34 |
| bbobrov | where do i find py3.12 for that... | 15:34 |
| zigo | dmendiza[m]: It's always been the case that I've been annoying everyone early with interpreter versions, and fixing them early has always been good ... :) | 15:35 |
| zigo | bbobrov: In Debian Unstable for example. | 15:35 |
| zigo | Not sure of the Ubuntu status. | 15:35 |
| zigo | In Unstable, it's as "available version", ie not the default yet. | 15:35 |
| bbobrov | i am afraid to get out of my debian stable | 15:35 |
| zigo | Use a chroot then. | 15:36 |
| zigo | That works very well for testing. | 15:36 |
| bbobrov | zigo: i am volunteering, but i cannot promise you any timelines | 15:36 |
| zigo | That's very nice already. I'll see what I can do too. | 15:36 |
| zigo | I need to run, bye ! | 15:37 |
| d34dh0r53 | thanks bbobrov and zigo, we'll track this in the bug and reviews | 15:37 |
| d34dh0r53 | #topic bug review | 15:37 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:38 |
| d34dh0r53 | a few new bugs for keystone | 15:40 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2044624 | 15:41 |
| d34dh0r53 | there is a fix proposed that looks good, but it's failing the checks | 15:42 |
| d34dh0r53 | moving on | 15:42 |
| bbobrov | (please review the fix, the checks should be repaired now) | 15:42 |
| d34dh0r53 | ack, will do | 15:43 |
| d34dh0r53 | next up | 15:43 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2045974 | 15:43 |
| d34dh0r53 | hmm | 15:44 |
| d34dh0r53 | I like option 2 but that is indeed boiling an ocean | 15:44 |
| bbobrov | what if one gets a domain-manager role on a project? | 15:45 |
| d34dh0r53 | oops, I was commenting on the wrong link :o | 15:45 |
| gtema | idea of domain-manager (domain-admin) is actually to bring roles allowing identity operations on the domain (in domain scope) | 15:46 |
| gtema | I was not seeing the proposed spec, but what I wrote is a gist of discussions on the topic I was participating in | 15:47 |
| gtema | it is a must for any public cloud | 15:47 |
| gtema | otherwise they end up hiding keystone apis from the end user | 15:47 |
| bbobrov | why not "manager" on a domain? | 15:48 |
| gtema | doesn't matter what the name is. Or do I get your question wrong? | 15:49 |
| d34dh0r53 | the spec says manager | 15:50 |
| gtema | I see in the spec domain-manager role | 15:51 |
| bbobrov | i think the bugreport language could be a bit changed then: | 15:51 |
| bbobrov | and maybe in the spec | 15:51 |
| bbobrov | to: introduce a new "domain-manager" persona in Keystone | 15:51 |
| gtema | sounds reasonable | 15:52 |
| bbobrov | the specs talk about personas defined via policies, and propose to create them via a combination of a new role (manager) and a scope (project) | 15:52 |
| d34dh0r53 | ack, we need to move on for time, but I'll add this spec to that section of the agenda | 15:52 |
| bbobrov | the bugreport kind of suggests to add "domain" as a potential scope for the role; | 15:53 |
| gtema | you are talking about the "alternatives"? | 15:53 |
| bbobrov | gtema: lets talk after the meeting | 15:54 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2045995 | 15:54 |
| gtema | ok | 15:54 |
| d34dh0r53 | I prefer option 2 for this one but it's a lot of work | 15:54 |
| d34dh0r53 | we're definitely missing tracebacks without that patch but I think we turned the volume up too high | 15:54 |
| bbobrov | although we miss them, we don't miss too many | 15:55 |
| bbobrov | we send them to sentry, and there are almost none | 15:56 |
| d34dh0r53 | ack | 15:56 |
| bbobrov | i also don't understand how to make sure, that, if option 2 is taken, i have suceeded in fixing the issue | 15:57 |
| bbobrov | i could refer to tempest | 15:57 |
| d34dh0r53 | I think it's whack-a-mole honestly | 15:57 |
| bbobrov | but how good is tempest in testing the negative scenarios? | 15:57 |
| d34dh0r53 | I'm not sure | 15:58 |
| bbobrov | maybe we could somehow catch it in our unit tests... | 15:58 |
| d34dh0r53 | maybe, let's discuss in the bug | 15:58 |
| bbobrov | anyway, i am experimenting with option 1 right now. | 15:59 |
| d34dh0r53 | I'm open to option 1 | 15:59 |
| d34dh0r53 | let me know how it goes | 15:59 |
| d34dh0r53 | finally for keystone | 15:59 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2046355 | 15:59 |
| bbobrov | this has been discussed earlier | 15:59 |
| d34dh0r53 | we discussed this already | 15:59 |
| d34dh0r53 | I checked the other projects and we don't have any new issues in any of them | 16:00 |
| d34dh0r53 | #topic conclusion | 16:00 |
| d34dh0r53 | Thanks for the lively discussion today, and for the heads up on py3.12 | 16:00 |
| d34dh0r53 | we'll get to work on that | 16:00 |
| d34dh0r53 | anything else before we go? | 16:00 |
| d34dh0r53 | next week will be the last weekly meeting of the year, have a great rest of your week folks! | 16:01 |
| d34dh0r53 | #endmeeting | 16:01 |
| opendevmeet | Meeting ended Wed Dec 13 16:01:27 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:01 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2023/keystone.2023-12-13-15.00.html | 16:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2023/keystone.2023-12-13-15.00.txt | 16:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2023/keystone.2023-12-13-15.00.log.html | 16:01 |
| bbobrov | gtema: so about the role | 16:01 |
| gtema | yupp | 16:01 |
| bbobrov | gtema: (i don't want to discuss whether it should be implemented or not, i just want to get the description in a bit better state) | 16:02 |
| gtema | right | 16:02 |
| gtema | so for public cloud there are few personas with corresponding rights | 16:02 |
| gtema | platform admin | 16:02 |
| gtema | domain admin | 16:02 |
| gtema | project admin | 16:03 |
| gtema | regular user | 16:03 |
| gtema | what is required is to have a domain_admin capability handed over to specific users that in the domain_scope allow this user to manage users/project inside this certain domain | 16:03 |
| bbobrov | gtema: the "Consistent and Secure Default RBAC" spec talks about role "manager" and persona "project-manager". | 16:04 |
| gtema | so that the user "company" is having self-service aministration capability without needing platform admin to perform operations or implement some sort of additional API workarounds | 16:04 |
| gtema | the point is that it is not sufficient for public cloud | 16:05 |
| bbobrov | gtema: according the spec, persona project-manager is basically role manager on a project. They propose to do it via a common rule:project_manager: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#implement-support-for-project-manager-personas | 16:07 |
| gtema | project_manager is not the person who should be allowed to create users in the domain | 16:08 |
| bbobrov | gtema: the bugreport proposes to add a new role "domain-manager". I think that the language here should be changed. It should propose to add a new *persona* domain-manager. Which will be a combination of role manager on domain | 16:09 |
| gtema | but technically you still end up just defining new role | 16:09 |
| gtema | those persons are honestly speaking only confusing | 16:09 |
| bbobrov | no | 16:09 |
| gtema | "personas" I mean | 16:09 |
| bbobrov | the role "manager" is the same role from the project-manager persona | 16:10 |
| gtema | hmm | 16:11 |
| bbobrov | please note: the spec "Consistent and Secure Default RBAC" does not propose to add a role "project-manager". | 16:11 |
| gtema | yeah, but persona | 16:11 |
| bbobrov | which is a combination of scope on a project. | 16:12 |
| gtema | I see that, and exactly that is confusing (matrix of policy, persona and role) | 16:12 |
| gtema | that aside, do you agree that what I described above would require having a new role? | 16:12 |
| bbobrov | i do not have an opinion on the subject of the bugreport now, sorry | 16:13 |
| bbobrov | i just want to help set the wording right for now | 16:13 |
| gtema | I do not ask for your opinion on the bugreport. I want to know whether (from the wording pov) you agree, that having possibility to grant certain people privileges to manage users of the domain will require creating new dedicated role | 16:14 |
| bbobrov | no | 16:15 |
| gtema | how else you "could" implement that? | 16:16 |
| bbobrov | we are stepping into the bugreport subject now :) i don't see how it is different from role admin on a domain. Domain admin is supposed to do exactly that. | 16:17 |
| gtema | but there is no dedicated admin that you can hand over to the user owning a certain domain | 16:18 |
| gtema | that is exactly what the spec/bug suggests to have | 16:18 |
| bbobrov | "Consistent and Secure Default RBAC" talks about adding a new role "manager". In order to implement the spec (that i don't fully agree with, but whatever), role "manager" is supposed to be added. This role can be reused for the issue in the bugreport. | 16:19 |
| gtema | now consider following: you have an org with 5 team managers having "manager" role to manage their individual projects | 16:20 |
| bbobrov | gtema: why not? I could give a user "admin" on domain "abcd" and they can now manage users there (after small policies adjustment) | 16:20 |
| gtema | but you need to have a dedicated person (security officer) allowing adding new users or managing who is actually getting project manager roles | 16:21 |
| bbobrov | this is domain-manager persona. Which is role "manager" on a domain. | 16:22 |
| gtema | wrt "admin" - I do not know of any possibility right now to have a regular domain user managing users in the same domain (only in this domain) | 16:22 |
| bbobrov | i don't understand the problem | 16:28 |
| bbobrov | the rule to create a user now is SYSTEM_ADMIN_OR_DOMAIN_ADMIN | 16:29 |
| bbobrov | (role:admin and system_scope:all) or (role:admin and token.domain.id:%(target.user.domain_id)s) | 16:29 |
| bbobrov | which means "system scoped or domain admin" can create a user | 16:30 |
| bbobrov | if you want a non-admin user to allow to create users, it should be changed in policy.yaml to: | 16:30 |
| bbobrov | (role:member and token.domain.id:%(target.user.domain_id)s) | 16:30 |
| gtema | but isn't it roughly what is being suggested? except of allocating a new role for that | 16:32 |
| gtema | in certain clouds from security pov there must be a person with capability to manage users of the domains and user roles, but not being admin to actually also own the resources | 16:33 |
| gtema | .. to not to own the resources | 16:34 |
| bbobrov | lets leave the wording like right now then | 16:34 |
| gtema | I was just worying, that simply saying: "lets introduce a new persona" is not explaining what needs to be done. But I also understand your point that is may be rephrased | 16:35 |
| opendevreview | Merged openstack/keystone master: Fix typo in cmd/status.py https://review.opendev.org/c/openstack/keystone/+/896193 | 18:56 |
| opendevreview | Douglas Mendizábal proposed openstack/keystone master: Consistent and Secure RBAC (Phase 1) https://review.opendev.org/c/openstack/keystone/+/902730 | 20:04 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!