| stephenfin | #success Keystone has finally joined the Alembic club, like neutron, nova, cinder and glance before it 🎉 | 11:01 |
|---|---|---|
| opendevstatus | stephenfin: Added success to Success page (https://wiki.openstack.org/wiki/Successes) | 11:01 |
| stephenfin | zzzeek: ^ | 11:02 |
| *** dasm|off is now known as dasm | 11:06 | |
| *** dviroel|out is now known as dviroel | 11:25 | |
| opendevreview | Stephen Finucane proposed openstack/keystone master: sql: Add support for auto-generation https://review.opendev.org/c/openstack/keystone/+/826147 | 11:37 |
| opendevreview | Stephen Finucane proposed openstack/keystone master: sql: Fix incorrect constraints https://review.opendev.org/c/openstack/keystone/+/851845 | 11:37 |
| opendevreview | Stephen Finucane proposed openstack/keystone master: sql: Fix incorrect constraints https://review.opendev.org/c/openstack/keystone/+/851845 | 11:49 |
| *** priteau_ is now known as priteau | 12:38 | |
| *** dansmith_ is now known as dansmith | 13:46 | |
| dmendiza[m] | Thansk for all the work to get Alembic working stephenfin | 14:59 |
| dmendiza[m] | #startmeeting keystone | 15:00 |
| opendevmeet | Meeting 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:00 |
| dmendiza[m] | #topic Roll Call | 15: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, xek | 15:01 |
| dmendiza[m] | as usual the agenda is over here: | 15:01 |
| dmendiza[m] | #link https://etherpad.opendev.org/p/keystone-weekly-meeting | 15:01 |
| h_asahina | o/ | 15:03 |
| xek | o/ | 15:03 |
| dmendiza[m] | OK, let's get started | 15:04 |
| dmendiza[m] | #topic Review Past Meeting Action Items | 15:04 |
| dmendiza[m] | #link https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-07-26-15.00.html | 15:04 |
| dmendiza[m] | We didn't have any... | 15:04 |
| dmendiza[m] | #topic Liaison Updates | 15:04 |
| dmendiza[m] | I don't have any updates this week... | 15:04 |
| dmendiza[m] | #topic Secure RBAC | 15: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.0 | 15:06 |
| dmendiza[m] | h_asahina: any updates this week? | 15:06 |
| h_asahina | I've updated spec. | 15:06 |
| h_asahina | https://review.opendev.org/c/openstack/keystone-specs/+/843765 | 15:07 |
| h_asahina | please kindly review it again. | 15:07 |
| h_asahina | ah, xek has already replied. | 15:08 |
| h_asahina | thanks | 15:08 |
| h_asahina | Also, I'd like to ask that can Yoga OAuth2.0 patch be mereged in Zed? | 15:08 |
| knikolla | o/ | 15:09 |
| 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 server | 15:10 |
| dmendiza[m] | Keystone is typically deployed behind Apache | 15:10 |
| dmendiza[m] | so the mTLS heavy-lifting could be done by Apache | 15:10 |
| h_asahina | In my understanding, verification of trust chain is done by apache. | 15:11 |
| dmendiza[m] | Apache can be configured to provide the cert in a header | 15:11 |
| h_asahina | what 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 then | 15:12 |
| h_asahina | that'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 server | 15:13 |
| h_asahina | that makes sense. I'll do that. | 15:13 |
| *** dviroel is now known as dviroel|lunch | 15: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_asahina | https://review.opendev.org/c/openstack/keystoneauth/+/830734 | 15:15 |
| h_asahina | https://review.opendev.org/c/openstack/keystonemiddleware/+/830737 | 15:15 |
| h_asahina | https://review.opendev.org/c/openstack/keystone/+/830739 | 15:15 |
| h_asahina | The last one already has +1. | 15:16 |
| knikolla | sorry, didn't have time to leave the feedback that we discussed on Friday | 15:16 |
| knikolla | it 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 |
| knikolla | We can get this to work similarly to how federation works | 15:16 |
| knikolla | If apache lets the user in to a specific endpoint, then the user is issued a token | 15:17 |
| knikolla | All we have to do is make that endpoint look and work like OAuth | 15:17 |
| knikolla | The token that that endpoint issues can be bound to the thumbprint of the cert used to issue it | 15:18 |
| h_asahina | but apache can't confirm that the cert has DN that registered to Keystone in advance. | 15:18 |
| knikolla | if you control the CA you control what certs it issues. | 15:18 |
| knikolla | You can have apache limit it to a specific group of DNs, I think. | 15:19 |
| h_asahina | I see. we can limit who can get certs via CA and also apache is capable to limit it with DN. | 15:20 |
| h_asahina | that you meant? | 15:20 |
| knikolla | yes | 15:20 |
| h_asahina | to be honest, we don't know that apache's feature. but if it's possible that's much easier to implement. | 15:21 |
| knikolla | This makes it significantly easier to implement, yes | 15:21 |
| h_asahina | we'll check apache's option | 15:21 |
| h_asahina | and if we can confirm it works, i'll revise the spec. | 15:21 |
| knikolla | Take a look at how federation works | 15:21 |
| h_asahina | okey. thank you. | 15:22 |
| h_asahina | thanks for the info. | 15:22 |
| knikolla | The 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 |
| knikolla | And issues a token. | 15:22 |
| h_asahina | the endpoin you mentioned is token issuing endpoin? | 15:23 |
| xek | doesn't the RFE have a requirement to register the DN or other identifier first? | 15:23 |
| xek | I don't have it on hand | 15:23 |
| knikolla | no, it's the federation endpoint | 15:23 |
| knikolla | under OS-FEDERATION | 15:23 |
| knikolla | https://docs.openstack.org/keystone/latest/admin/federation/introduction.html | 15:24 |
| knikolla | xek: good question. | 15:25 |
| knikolla | but I don't think the API specifices the mechanism to register the DNs | 15:25 |
| xek | https://www.rfc-editor.org/rfc/rfc8705.html#section-2.1.2 | 15:25 |
| xek | it references the OAuth 2.0 Dynamic Client Registration Protocol which I'm not familiar with | 15:26 |
| h_asahina | in section 2.1 | 15:28 |
| xek | maybe it's only for the self-signed certs | 15:28 |
| h_asahina | The PKI (public key infrastructure) method of mutual-TLS OAuth client | 15:28 |
| h_asahina | authentication adheres to the way in which X.509 certificates are | 15:28 |
| h_asahina | traditionally used for authentication. It relies on a validated | 15:28 |
| h_asahina | certificate chain [RFC5280] and a single subject distinguished name | 15:28 |
| h_asahina | (DN) or a single subject alternative name (SAN) to authenticate the | 15:28 |
| h_asahina | client.Y | 15:28 |
| knikolla | h_asahina: is conformance to the dynamic client registration RFC a requirement for ETSI NFV? | 15:28 |
| h_asahina | no | 15:29 |
| h_asahina | but the above is rfc8705 | 15:29 |
| xek | ok, so as I understand it, the registration would be only required for self signed certs | 15:30 |
| knikolla | I think the spec requires that the DN of the cert be "expected" and match to only 1 client. | 15:31 |
| knikolla | We can make those guarantees. | 15:31 |
| h_asahina | by 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 |
| knikolla | I think it means that one client can only have one subject name and no others | 15:33 |
| dmendiza[m] | Would it make sense to require the DN or SAN to match the username in Keystone? 🤔 | 15:33 |
| knikolla | I think that's how we make that guarantee, yes. | 15:34 |
| knikolla | The presence of the user signifies "registration" | 15:34 |
| h_asahina | in that case, an OAuth2.0 client means a openstack user, right? | 15:35 |
| knikolla | yes | 15:36 |
| h_asahina | need to confirm that maches to our usecase | 15:36 |
| h_asahina | maybe we need to separate users and `OAuth clients` | 15:36 |
| knikolla | I'm really hesitant to do that | 15:37 |
| knikolla | Nothing else in OpenStack will ever use OAuth clients | 15:37 |
| knikolla | and we will be introducing an entire API just for this use case | 15:37 |
| h_asahina | yeah, I remember what you said before | 15:37 |
| h_asahina | OpenStack doesn't have features to manage clients, but uses. | 15:38 |
| h_asahina | /uses/users/ | 15:38 |
| knikolla | yeah | 15:38 |
| h_asahina | I'll see what we can do. | 15:39 |
| h_asahina | I feel your suggestion will work for our usecase. | 15:39 |
| h_asahina | intuitively | 15:39 |
| knikolla | Great, let me know. | 15:40 |
| h_asahina | got it. I'll reply on spec or next meeting. | 15:40 |
| knikolla | I'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 |
| knikolla | In a lot of cases, we already have similar mechanisms that can be adapted, like here. | 15:41 |
| knikolla | When that is no longer the case, we can start considering bigger changes | 15:41 |
| h_asahina | I see. thank you for you suggestion. | 15:41 |
| h_asahina | okey. I'd like to confirm Yoga patches. | 15:42 |
| h_asahina | can I do that? | 15:42 |
| h_asahina | I 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 Friday | 15:43 |
| dmendiza[m] | for the Reviewathon | 15:43 |
| dmendiza[m] | when they merge they will merge to "master" branch, which is currently Zed | 15:44 |
| h_asahina | you're right. sorry. | 15:44 |
| h_asahina | thank you for considering add them to reviewathon | 15:45 |
| h_asahina | at least, we want to merge them within Zed cycle | 15:46 |
| h_asahina | even if merging mTLS OAuth2.0 is not possible. | 15:46 |
| h_asahina | sorry for taking a lot of time, but I'd like to confirm one more thing quickly. | 15:47 |
| h_asahina | regarding 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_asahina | In other words, it will have Cross repository dependencies | 15:47 |
| h_asahina | and we're planing to use `Depends-On:` to handle it | 15:48 |
| h_asahina | Do you have any other options? | 15:48 |
| knikolla | Depends-On seems fine in this case | 15:49 |
| h_asahina | that what you want to hear. thanks. | 15:49 |
| h_asahina | that'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 left | 15:51 |
| dmendiza[m] | #topic Open Discussion | 15:51 |
| dmendiza[m] | Anything else y'all want to talk about? | 15:51 |
| noonedeadpunk | I 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 it | 15:54 |
| noonedeadpunk | jsut fix is super trivial from the first sight | 15:55 |
| noonedeadpunk | but 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 one | 15:55 |
| noonedeadpunk | ok, gotcha then will push it soon | 15:56 |
| dmendiza[m] | Thanks, noonedeadpunk | 15:57 |
| dmendiza[m] | Cool, that's about all the time we have for today | 15:57 |
| dmendiza[m] | thanks for joining, eveyrone! | 15:57 |
| dmendiza[m] | #endmeeting | 15:57 |
| opendevmeet | Meeting ended Tue Aug 2 15:57:52 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:57 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-08-02-15.00.html | 15:57 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-08-02-15.00.txt | 15:57 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-08-02-15.00.log.html | 15:57 |
| *** dviroel|lunch is now known as dviroel| | 16:15 | |
| *** dviroel| is now known as dviroel | 16:15 | |
| opendevreview | Stephen Finucane proposed openstack/keystone master: requirements: Bump linter requirements https://review.opendev.org/c/openstack/keystone/+/851908 | 16:19 |
| opendevreview | Stephen Finucane proposed openstack/keystone master: sql: Add support for auto-generation https://review.opendev.org/c/openstack/keystone/+/826147 | 16:19 |
| opendevreview | Stephen Finucane proposed openstack/keystone master: sql: Fix incorrect constraints https://review.opendev.org/c/openstack/keystone/+/851845 | 16:19 |
| stephenfin | zzzeek: 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 more | 16:21 |
| *** dviroel is now known as dviroel|biab | 19:56 | |
| opendevreview | Gage Hugo proposed openstack/keystone master: Emit world-readable warning once on fernet-setup https://review.opendev.org/c/openstack/keystone/+/799103 | 20:01 |
| *** dviroel|biab is now known as dviroel | 20:31 | |
| *** dviroel is now known as dviroel|afk | 20:58 | |
| *** dasm is now known as dasm|off | 21:09 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!