Tuesday, 2022-08-02

stephenfin#success Keystone has finally joined the Alembic club, like neutron, nova, cinder and glance before it 🎉11:01
opendevstatusstephenfin: Added success to Success page (https://wiki.openstack.org/wiki/Successes)11:01
stephenfinzzzeek: ^11:02
*** dasm|off is now known as dasm11:06
*** dviroel|out is now known as dviroel11:25
opendevreviewStephen Finucane proposed openstack/keystone master: sql: Add support for auto-generation  https://review.opendev.org/c/openstack/keystone/+/82614711:37
opendevreviewStephen Finucane proposed openstack/keystone master: sql: Fix incorrect constraints  https://review.opendev.org/c/openstack/keystone/+/85184511:37
opendevreviewStephen Finucane proposed openstack/keystone master: sql: Fix incorrect constraints  https://review.opendev.org/c/openstack/keystone/+/85184511:49
*** priteau_ is now known as priteau12:38
*** dansmith_ is now known as dansmith13:46
dmendiza[m]Thansk for all the work to get Alembic working stephenfin 14:59
dmendiza[m]#startmeeting keystone15:00
opendevmeetMeeting started Tue Aug  2 15:00:58 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:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
opendevmeetThe meeting name has been set to 'keystone'15:00
dmendiza[m]#topic Roll Call15:01
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, xek15:01
dmendiza[m]as usual the agenda is over here:15:01
dmendiza[m]#link https://etherpad.opendev.org/p/keystone-weekly-meeting15:01
dmendiza[m]OK, let's get started15:04
dmendiza[m]#topic Review Past Meeting Action Items15:04
dmendiza[m]#link https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-07-26-15.00.html15:04
dmendiza[m]We didn't have any...15:04
dmendiza[m]#topic Liaison Updates15:04
dmendiza[m]I don't have any updates this week...15:04
dmendiza[m]#topic Secure RBAC15:04
dmendiza[m]I tried to join the pop-up meeting today, but I don't think it actually happened.15:05
dmendiza[m]No updates on the "manager" role or the "service" role specs ...15:06
dmendiza[m]#topic OAuth 2.015:06
dmendiza[m]h_asahina: any updates this week?15:06
h_asahinaI've updated spec.15:06
h_asahinaplease kindly review it again.15:07
h_asahinaah, xek has already replied.15:08
h_asahinaAlso, I'd like to ask that can Yoga OAuth2.0 patch be mereged in Zed?15:08
dmendiza[m]Hi knikolla 15:09
dmendiza[m]h_asahina: we did review the spec last Friday, but I don't think knikolla has had a chance to leave feedback.  15:10
dmendiza[m]One thing that was not clear was how much of the mTLS is going to be done by the web server15:10
dmendiza[m]Keystone is typically deployed behind Apache15:10
dmendiza[m]so the mTLS heavy-lifting could be done by Apache15:10
h_asahinaIn my understanding, verification of trust chain is done by apache.15:11
dmendiza[m]Apache can be configured to provide the cert in a header15:11
h_asahinawhat we have to do is just checking whether cert matches to one that stored in DB and binding the cert to a issued OAuth2.0 token.15:12
dmendiza[m]OK, cool, I think we're all on the same page then15:12
h_asahinathat's good. knikolla: if you have additional comments I can further revise the spec.15:13
dmendiza[m]h_asahina: maybe it would be good to update the spec to clarify that cert chain validation will be done by the web server15:13
h_asahinathat makes sense. I'll do that.15:13
*** dviroel is now known as dviroel|lunch15:14
dmendiza[m]> can Yoga OAuth2.0 patch be mereged in Zed?15:14
dmendiza[m]I'm not sure what patch you're talking about?15:14
h_asahinaThe last one already has +1.15:16
knikollasorry, didn't have time to leave the feedback that we discussed on Friday15:16
knikollait basically boils down to: if we are leaving the verification to be done by Apache, and the CA is trusted, we don't need to use the credentials API at all. 15:16
knikollaWe can get this to work similarly to how federation works15:16
knikollaIf apache lets the user in to a specific endpoint, then the user is issued a token15:17
knikollaAll we have to do is make that endpoint look and work like OAuth15:17
knikollaThe token that that endpoint issues can be bound to the thumbprint of the cert used to issue it15:18
h_asahinabut apache can't confirm that the cert has DN that registered to Keystone in advance. 15:18
knikollaif you control the CA you control what certs it issues. 15:18
knikollaYou can have apache limit it to a specific group of DNs, I think. 15:19
h_asahinaI see. we can limit who can get certs via CA and also apache is capable to limit it with DN.15:20
h_asahinathat you meant?15:20
h_asahinato be honest, we don't know that apache's feature. but if it's possible that's much easier to implement.15:21
knikollaThis makes it significantly easier to implement, yes15:21
h_asahinawe'll check apache's option15:21
h_asahinaand if we can confirm it works, i'll revise the spec.15:21
knikollaTake a look at how federation works15:21
h_asahinaokey. thank you.15:22
h_asahinathanks for the info.15:22
knikollaThe user has to get through apache and go to a specific endpoint. In that endpoint, keystone loads up the environment variables that apache adds and maps the user to a user.15:22
knikollaAnd issues a token. 15:22
h_asahinathe endpoin you mentioned is token issuing endpoin?15:23
xekdoesn't the RFE have a requirement to register the DN or other identifier first?15:23
xekI don't have it on hand15:23
knikollano, it's the federation endpoint15:23
knikollaunder OS-FEDERATION15:23
knikollaxek: good question. 15:25
knikollabut I don't think the API specifices the mechanism to register the DNs15:25
xekit references the  OAuth 2.0 Dynamic Client Registration Protocol  which I'm not familiar with15:26
h_asahinain section 2.1 15:28
xekmaybe it's only for the self-signed certs15:28
h_asahina   The PKI (public key infrastructure) method of mutual-TLS OAuth client15:28
h_asahina   authentication adheres to the way in which X.509 certificates are15:28
h_asahina   traditionally used for authentication.  It relies on a validated15:28
h_asahina   certificate chain [RFC5280] and a single subject distinguished name15:28
h_asahina   (DN) or a single subject alternative name (SAN) to authenticate the15:28
h_asahina   client.Y15:28
knikollah_asahina: is conformance to the dynamic client registration RFC a requirement for ETSI NFV? 15:28
h_asahinabut the above is rfc870515:29
xekok, so as I understand it, the registration would be only required for self signed certs15:30
knikollaI think the spec requires that the DN of the cert be "expected" and match to only 1 client. 15:31
knikollaWe can make those guarantees. 15:31
h_asahinaby apache?15:32
knikolla"The client is successfully authenticated if the subject information in the certificate matches the single expected subject configured or registered for that particular client"15:32
knikollaI think it means that one client can only have one subject name and no others15:33
dmendiza[m]Would it make sense to require the DN or SAN to match the username in Keystone? 🤔15:33
knikollaI think that's how we make that guarantee, yes. 15:34
knikollaThe presence of the user signifies "registration" 15:34
h_asahinain that case, an OAuth2.0 client means a openstack user, right?15:35
h_asahinaneed to confirm that maches to our usecase15:36
h_asahinamaybe we need to separate users and `OAuth clients`15:36
knikollaI'm really hesitant to do that15:37
knikollaNothing else in OpenStack will ever use OAuth clients15:37
knikollaand we will be introducing an entire API just for this use case15:37
h_asahinayeah, I remember what you said before15:37
h_asahinaOpenStack doesn't have features to manage clients, but uses.15:38
h_asahina /uses/users/15:38
h_asahinaI'll see what we can do.15:39
h_asahinaI feel your suggestion will work for our usecase.15:39
knikollaGreat, let me know. 15:40
h_asahinagot it. I'll reply on spec or next meeting.15:40
knikollaI'm just trying to fulfill your use case in the path that creates the least amount of maintenance and work for the team. 15:40
knikollaIn a lot of cases, we already have similar mechanisms that can be adapted, like here. 15:41
knikollaWhen that is no longer the case, we can start considering bigger changes15:41
h_asahinaI see. thank you for you suggestion.15:41
h_asahinaokey. I'd like to confirm Yoga patches.15:42
h_asahinacan I do that?15:42
h_asahinaI mean Yoga patches status.15:43
dmendiza[m]h_asahina: I was confused because they're not "yoga" patches.  They're patches for the "master" branch, not "stable/yoga"15:43
dmendiza[m]I'll add them to the reivews on Friday15:43
dmendiza[m]for the Reviewathon15:43
dmendiza[m]when they merge they will merge to "master" branch, which is currently Zed15:44
h_asahinayou're right. sorry.15:44
h_asahinathank you for considering add them to reviewathon15:45
h_asahinaat least, we want to merge them within Zed cycle15:46
h_asahinaeven if merging mTLS OAuth2.0 is not possible.15:46
h_asahinasorry for taking a lot of time, but I'd like to confirm one more thing quickly.15:47
h_asahinaregarding mTLS patches, keystonemiddleware will depend on  keystoneauth1, i.e.,  mTLS keystonemiddleware will  not work properly if it is merged before keystoneauth1 is merged.15:47
h_asahinaIn other words, it will have Cross repository dependencies15:47
h_asahinaand we're planing to use `Depends-On:` to handle it15:48
h_asahinaDo you have any other options?15:48
knikollaDepends-On seems fine in this case15:49
h_asahinathat what you want to hear. thanks.15:49
h_asahinathat's all from my side. thank you for valuable adivce and discussion.15:50
dmendiza[m]Thanks, h_asahina 15:51
dmendiza[m]Ok, we've only got a few minutes left15:51
dmendiza[m]#topic Open Discussion15:51
dmendiza[m]Anything else y'all want to talk about?15:51
noonedeadpunkI was kind of wondering on proggress about the bug https://bugs.launchpad.net/keystone/+bug/1959674 Did anybody had a chance to dig into why application_Credentials do such weird things or this can be jsut safely dropped?15:53
dmendiza[m]noonedeadpunk: I don't think anyone has looked into it15:54
noonedeadpunkjsut fix is super trivial from the first sight15:55
noonedeadpunkbut I'm really afraid about just doing it as I can imagine some intention behind 15:55
dmendiza[m]We'd be happy to review a patch if you want to make one15:55
noonedeadpunkok, gotcha then will push it soon15:56
dmendiza[m]Thanks, noonedeadpunk 15:57
dmendiza[m]Cool, that's about all the time we have for today15:57
dmendiza[m]thanks for joining, eveyrone!15:57
opendevmeetMeeting ended Tue Aug  2 15:57:52 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:57
opendevmeetMinutes:        https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-08-02-15.00.html15:57
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-08-02-15.00.txt15:57
opendevmeetLog:            https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-08-02-15.00.log.html15:57
*** dviroel|lunch is now known as dviroel|16:15
*** dviroel| is now known as dviroel16:15
opendevreviewStephen Finucane proposed openstack/keystone master: requirements: Bump linter requirements  https://review.opendev.org/c/openstack/keystone/+/85190816:19
opendevreviewStephen Finucane proposed openstack/keystone master: sql: Add support for auto-generation  https://review.opendev.org/c/openstack/keystone/+/82614716:19
opendevreviewStephen Finucane proposed openstack/keystone master: sql: Fix incorrect constraints  https://review.opendev.org/c/openstack/keystone/+/85184516:19
stephenfinzzzeek: Oh, interesting. I'm seeing operations like rename_table, drop_table_comment and drop_table when running migrations against a MySQL backend. I'm using batch mode by default but I thought that only affected SQLite backends. Will investigate more16:21
*** dviroel is now known as dviroel|biab19:56
opendevreviewGage Hugo proposed openstack/keystone master: Emit world-readable warning once on fernet-setup  https://review.opendev.org/c/openstack/keystone/+/79910320:01
*** dviroel|biab is now known as dviroel20:31
*** dviroel is now known as dviroel|afk20:58
*** dasm is now known as dasm|off21:09

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