Wednesday, 2025-04-02

*** mhen_ is now known as mhen01:41
opendevreviewPiotr Korthals proposed openstack/oslo.limit master: Added ability to select identity_interface  https://review.opendev.org/c/openstack/oslo.limit/+/94612810:14
d34dh0r53#startmeeting keystone15:01
opendevmeetMeeting started Wed Apr  2 15:01:35 2025 UTC and is due to finish in 60 minutes.  The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot.15:01
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:01
opendevmeetThe meeting name has been set to 'keystone'15:01
d34dh0r53Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct15:02
d34dh0r53#link https://openinfra.dev/legal/code-of-conduct15:02
d34dh0r53#topic roll call15:02
gtemao/15:02
d34dh0r53admiyo, bbobrov, crisloma, d34dh0r53, dpar, dstanek, hrybacki, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, ruan_he, wxy, sonuk, vishakha, Ajay, rafaelwe, xek, gmann, zaitcev, reqa, dmendiza[m], dmendiza, mharley, jph, gtema, cardoe, deydra15:02
d34dh0r53dmendiza for the dingz15:03
dmendiza[m]👋15:03
d34dh0r53#topic review past meeting work items15:04
d34dh0r53#link https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-03-26-15.01.html15:05
d34dh0r53no action items from last week15:05
d34dh0r53#topic liaison updates15:05
d34dh0r53nothing from releases or VMT15:05
gtemanothing from releases? ;-)15:06
gtemawe have a release, so party :D15:06
d34dh0r53Oh yeah, duh15:07
mharley[m]o/15:07
d34dh0r53🥳15:07
dmendiza[m]🎉15:08
d34dh0r53Thank you for the reminder gtema :)15:09
d34dh0r53#topic specification OAuth 2.0 (hiromu)15:09
d34dh0r53#link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext15:09
d34dh0r53#link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability15:09
d34dh0r53External OAuth 2.0 Specification15:09
d34dh0r53#link https://review.opendev.org/c/openstack/keystone-specs/+/861554 (merged)15:09
d34dh0r53OAuth 2.0 Implementation15:09
d34dh0r53#link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls (merged)15:09
d34dh0r53OAuth 2.0 Documentation15:09
d34dh0r53#link https://review.opendev.org/c/openstack/keystone/+/838108 (merged)15:09
d34dh0r53#link https://review.opendev.org/c/openstack/keystoneauth/+/838104 (merged)15:09
d34dh0r53I'm going to do a manual rebase of #link https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/874716 today and we'll see where that gets us15:11
d34dh0r53that's all for me15:11
d34dh0r53#topic specification Secure RBAC (dmendiza[m])15:11
d34dh0r53#link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_15:11
d34dh0r53'v15:11
d34dh0r532024.1 Release Timeline15:11
d34dh0r53Update oslo.policy in keystone to enforce_new_defaults=True15:11
d34dh0r53Update oslo.policy in keystone to enforce_scope=True15:11
d34dh0r53any rbac updates dmendiza ?15:12
d34dh0r53#topic specification OpenAPI support (gtema)15:15
d34dh0r53#link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone15:15
gtemano updates. But since E is out I can return to requiring release of openstackdocstheme so that I can proceed15:16
d34dh0r53indeed15:17
d34dh0r53#topic specification Include bad password details in audit messages (stanislav-z)15:20
d34dh0r53#link https://review.opendev.org/q/topic:%22pci-dss-invalid-password-reporting%2215:20
d34dh0r53#link https://review.opendev.org/c/openstack/keystone-specs/+/915482 (merged)15:20
d34dh0r53#link https://review.opendev.org/c/openstack/keystone/+/932423 (merged)15:20
d34dh0r53#link https://review.opendev.org/c/openstack/keystone/+/945733 (merged)15:20
d34dh0r53All merged15:20
d34dh0r53woot!15:20
stanislav-zyes, thanks for the reviews and patience!15:21
d34dh0r53absolutely, thank you!15:21
d34dh0r53anything else on this one or can we archive it?15:21
stanislav-znope, I'd say all's good so far. I'm going to remove the topic from the list - or would you move it somewhere?15:22
d34dh0r53I can move it15:23
stanislav-zthanks15:23
d34dh0r53#topic open discussion15:23
d34dh0r53PTG etherpad is up15:23
d34dh0r53#link https://etherpad.opendev.org/p/apr2025-ptg-keystone15:24
gtemafew interesting topics already there ;-)15:24
d34dh0r53yeah15:24
gtemamy webinar from last week is now published (https://www.youtube.com/watch?v=0Hx4Q22ZNFU)15:24
d34dh0r53congrats!15:25
gtemait shows first results of reimplementing Keystone in Rust and authN with yubikey15:25
gtemathanks15:25
gtemait maybe something interesting to watch before we come to that point in PTG15:25
d34dh0r53Yeah, I'll watch it15:26
gtemasecond thing (actually also from that side). Does anybody remembers what is the sense of having domain bound roles if those are not injected into the token?15:26
gtemaI agree there are tons of issues with that (i.e. when domain role is named "admin - currently nothing prevents you creating such and there are no IDs in the oslo.policy check so it cannot even check what is this role about)15:27
gtemait is just confusing to have some capability that is not doing anything useful15:29
d34dh0r53I don't recall15:29
dmendiza[m]gtema: depends on what kind of token you get15:29
d34dh0r53dmendiza ^15:29
gtemanot sure, I assigned domain specific role to the user on project and domain and it is not present in domain scope and project scope15:30
dmendiza[m]when you send a request to get a token, you choose the scope - 99% of the time people use project scope, so roles assigned on a domain don't show up15:30
gtemawas not checking the system scope, but it makes even less sense15:30
dmendiza[m]there's 3 scopes:15:30
dmendiza[m]- project (the one everyone knows)15:30
dmendiza[m]- domain15:30
dmendiza[m]* system15:30
gtemaI know dmendiza - and those domain roles are not present in any of those15:30
dmendiza[m]That seems like a bug15:31
dmendiza[m]domain roles should be present on a domain scoped token15:31
gtemaI am not sure we can treat it like a bug, since as I said - nothing prevents you from creating "admin" role in the domain. So if domain_manager is capable to grant something like that oslo_policy would not even be able to differentiate such roles15:32
gtemait has to do with the design of it15:32
d34dh0r53There's a bug in keystone15:33
d34dh0r53about the domain manager role15:33
d34dh0r53#link https://bugs.launchpad.net/keystone/+bug/210598815:33
dmendiza[m]gtema: not sure I follow what you mean about "admin" role15:33
dmendiza[m]olso_policy has two ways of checking scope15:34
dmendiza[m]although, I admit, they're awkward and not ideal15:34
gtemadmendiza - role names must be unique only within the domain. So on the domain level you can create role names admin or manager/member/etc. On the oslo_policy level there is no way to differentiate whether the role is a global one of a domain specific one15:34
dmendiza[m]IIRC, Keystone reserves system-wide roles15:35
dmendiza[m]namely "admin", "manager", "member", "reader", and "service" are globally unique15:35
gtemareserves does not mean it prevents you from creating multiple admin roles in different domains15:36
gtemaand they are NOT globally unique15:36
gtemaonly within the domain. Global roles are just having a special "NULL_DOMAIN"15:36
dmendiza[m]https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html15:38
dmendiza[m]I want to say that was the relevant spec15:39
dmendiza[m]for making default roles unique15:39
gtemaI think we should at least review this (I spend couple of days already in my Rust POC reverse-engineering this topic) and discuss in PTG15:39
gtematoday I did a test and was able to get 2 admin roles15:40
gtemaone within the "null" domain and another in the customer domain15:40
dmendiza[m]Yeah, I can do some testing with Epoxy and/or master and see what the deal is15:40
gtema(with admin creds, but still)15:40
d34dh0r53👍15:40
d34dh0r53anything else for open discussion?15:41
gtemanothing from me except of simple statement that implied_role DB design is making it impossible to get implied assignments in a single DB query. Not sure how to deal with it though15:42
gtemadoesn't look like there is any way to change it, so apparently the best way is simply to read all roles and implied into memory and construct it on the "server side" away from DB15:43
d34dh0r53hmm15:43
gtemapg and mysql support recursive queries, but even with that it is insane complex to get the query right. I doubt any ORM in the world would be capable getting it right15:44
d34dh0r53are they calculated on the fly in keystone?15:44
gtemayeah, read all direct assignments15:45
gtemaand afterwards every role is resolved on the fly to expand the implied ones15:45
gtemaif your implied rules are small enough it is not a problem, but what if you have few thousand of those?15:46
gtemaBut yeah, this is not a standard case with upstream roles15:46
gtemait is relevant exactly for the above of domain specific roles and "domain_manager" capable of creating domain roles15:46
gtemaI am done, took anyway too much time today ;-)15:47
d34dh0r53no worries, useful conversation15:48
d34dh0r53we have lots to talk about at the ptg15:48
d34dh0r53#topic bug review15:48
d34dh0r53#link https://bugs.launchpad.net/keystone/?orderby=-id&start=015:48
d34dh0r53like I mentioned there is one new bug in keystone15:48
d34dh0r53#link https://bugs.launchpad.net/keystone/+bug/210598815:49
dmendiza[m]I can take a look at that15:49
d34dh0r53thanks dmendiza 15:49
d34dh0r53next up15:49
d34dh0r53#link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=015:49
d34dh0r53no new bugs for python-keystoneclient15:50
d34dh0r53#link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=015:50
d34dh0r53we have two new bugs in keystoneauth15:50
d34dh0r53first up15:50
d34dh0r53#link https://bugs.launchpad.net/keystoneauth/+bug/210590215:50
d34dh0r53is Grzegorz Grasza around?15:52
d34dh0r53both of these are related15:52
d34dh0r53#link https://bugs.launchpad.net/keystoneauth/+bug/210589115:53
d34dh0r53I'll see if I can get Grzegorz Grasza to look at these, he's on PTO today15:54
d34dh0r53#link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=015:54
d34dh0r53no new bugs in keystonemiddleware15:54
d34dh0r53#link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=015:54
d34dh0r53pycadf is good15:54
d34dh0r53#link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=015:54
d34dh0r53ldappool is also good15:54
d34dh0r53#topic conclusion15:54
d34dh0r53PTG next week, so no weekly meeting15:55
d34dh0r53have a great rest of your week :)15:55
gtemathanks Dave for still doing this meetings :)15:55
d34dh0r53you're welcome :)15:56
d34dh0r53#endmeeting15:56
opendevmeetMeeting ended Wed Apr  2 15:56:56 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:56
opendevmeetMinutes:        https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-04-02-15.01.html15:56
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-04-02-15.01.txt15:56
opendevmeetLog:            https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-04-02-15.01.log.html15:56
stanislav-zIs there a schedule for the PTG available?15:57
d34dh0r53https://ptg.opendev.org/ptg.html15:57
opendevreviewPiotr Korthals proposed openstack/oslo.limit master: Added ability to select identity_interface  https://review.opendev.org/c/openstack/oslo.limit/+/94612818:19
opendevreviewPiotr Korthals proposed openstack/oslo.limit master: Added ability to select identity_interface  https://review.opendev.org/c/openstack/oslo.limit/+/94612818:20
cardoegtema: be interested if you're looking more at OIDC so that we can establish trust relationships between accounts/users.20:28

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!