| *** osmanlicilegi is now known as Guest0 | 01:48 | |
| opendevreview | chenwei proposed openstack/keystone master: Remove unicode literal from code https://review.opendev.org/c/openstack/keystone/+/852516 | 06:37 |
|---|---|---|
| opendevreview | Grzegorz Grasza proposed openstack/keystone master: Add an option to randomize LDAP urls list https://review.opendev.org/c/openstack/keystone/+/821086 | 07:42 |
| opendevreview | chenwei proposed openstack/keystone master: Remove unicode literal from code https://review.opendev.org/c/openstack/keystone/+/852540 | 10:38 |
| opendevreview | chenwei proposed openstack/keystone master: Remove unicode literal from code https://review.opendev.org/c/openstack/keystone/+/852541 | 10:40 |
| opendevreview | chenwei proposed openstack/keystone master: Remove unicode literal from code https://review.opendev.org/c/openstack/keystone/+/852541 | 10:43 |
| *** dviroel|out is now known as dviroel | 11:32 | |
| *** dasm|off is now known as dasm | 13:30 | |
| ozzzo_work | We're running kolla Train with IPA auth, and we noticed today that accounts whose passwords are expired in IPA can auth into Swift. Has anyone else encountered this? | 14:01 |
| ozzzo_work | turns out it's not only Swift; it looks like all Keystone auth is working for accounts with expired passwords | 14:11 |
| ozzzo_work | I see the issue discussed here: https://serverfault.com/questions/716556/freeipa-ldap-refuse-auth-for-users-with-expired-password | 14:29 |
| opendevreview | Ayumu Ueha proposed openstack/keystonemiddleware master: Fix logging notifier unit test https://review.opendev.org/c/openstack/keystonemiddleware/+/852590 | 14:38 |
| ozzzo_work | how are other operators fixing this? Is there something we can do in our <domain>.conf? | 14:44 |
| dmendiza[m] | #startmeeting keystone | 15:02 |
| opendevmeet | Meeting started Tue Aug 9 15:02:06 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:02 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:02 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:02 |
| dmendiza[m] | #topic Roll Call | 15:02 |
| xek | o/ | 15:02 |
| 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:02 |
| dmendiza[m] | Hi Grzegorz Grasza ! | 15:02 |
| knikolla | o/ | 15:02 |
| d34dh0r53 | o/ | 15:03 |
| h_asahina | o/ | 15:03 |
| dmendiza[m] | HI everyone! | 15:04 |
| 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-08-02-15.00.html | 15:04 |
| dmendiza[m] | We didn't havea ny | 15:04 |
| dmendiza[m] | *have any | 15:04 |
| dmendiza[m] | Moving on ... | 15:05 |
| dmendiza[m] | #topic Liaison Updates | 15:05 |
| dmendiza[m] | No updates I can think of right now ... 🤔 | 15:05 |
| dmendiza[m] | #topic OAuth 2.0 | 15:05 |
| dmendiza[m] | HI h_asahina ! | 15:05 |
| h_asahina | hi | 15:06 |
| dmendiza[m] | Any updates for this week? | 15:06 |
| h_asahina | i'd like to discuss about mapping between DN and Keystone user's attributes | 15:06 |
| h_asahina | https://review.opendev.org/c/openstack/keystone-specs/+/843765 | 15:06 |
| h_asahina | I replied your comment | 15:07 |
| h_asahina | you suggested mapping UID and DC to Keystone username and domain_name | 15:08 |
| h_asahina | and enforce that rule to CA | 15:08 |
| h_asahina | but I think we can't always enfoce that rule to CA | 15:09 |
| h_asahina | maybe CA want to use these fields for another purpose | 15:09 |
| h_asahina | the border of tenant might be not domain_name, but project_id | 15:10 |
| h_asahina | so, if we try to map DN fields to Keystone users' attributes, we have to add configuration for such mapping | 15:11 |
| dmendiza[m] | Yeah, User IDs are unique | 15:11 |
| dmendiza[m] | I suppose we could make that configurable ... | 15:13 |
| h_asahina | but adding such configuration makes it a little bit complicated | 15:14 |
| knikolla | We could tie this up to federation mappings, I guess. | 15:15 |
| knikolla | This way the operator decides which attributes to use for what. | 15:15 |
| knikolla | x509 seems to do the same https://docs.openstack.org/keystone/latest/admin/configure_tokenless_x509.html#create-a-map | 15:16 |
| h_asahina | that makes sense, but to be honest I feel storing entire DN to credentials API is much simpler. | 15:16 |
| *** sfinucan is now known as stephenfin | 15:16 | |
| h_asahina | do you think it's possible to use https://docs.openstack.org/keystone/latest/admin/configure_tokenless_x509.html#create-a-map directly for this purpose? knikolla: | 15:20 |
| knikolla | Simpler, but you have to add each users DN to credentials API, which seems like an unnecessary step. | 15:20 |
| knikolla | I think it shouldn't be hard to extend the same code used for that to look more like OAuth | 15:20 |
| h_asahina | if we don't use credentials API, we still have to add a user. | 15:21 |
| knikolla | Yes | 15:22 |
| knikolla | But with that you can also support the use case where presenting the certificate to keystone is what registers the user | 15:23 |
| knikolla | like with federation. though i don't think that's a requirement or desirable for you. | 15:23 |
| h_asahina | I mean from the user's view, making a user and making a credential is not different. | 15:25 |
| h_asahina | maybe I don't understand motivation behind using User API | 15:27 |
| knikolla | the user can't make the credential, he has to request one from the CA | 15:28 |
| h_asahina | could please elaborate on that? | 15:30 |
| h_asahina | I understand it's like federation | 15:31 |
| h_asahina | so if we say `credential` that should be managed by CA | 15:31 |
| h_asahina | but what user have to do actually is to register its DN (or part of DN) to Keystone | 15:31 |
| knikolla | For a user to authenticate to keystone using mtls (using the proposed credentials api) these are the required steps. 1) operator registers user 2) user gets a certificate from CA that operator sets up (PKI) 3) user uploads credential received from CA 4) user authenticates | 15:32 |
| knikolla | step 3 runs into a chicken and egg issue with the user not having registered a trusted cert yet, therefore being unable to authenticate (especially if the entire of keystone is protected from mTLS) | 15:32 |
| knikolla | so it makes sense to not require step 3, since the certificate is already coming from a trusted CA | 15:33 |
| knikolla | does this make sense so far? | 15:34 |
| h_asahina | I see. user who register credential itself has to be authenticated by CA, but if we use credentials api it's not possible. | 15:35 |
| h_asahina | or I should say it's contradicted | 15:35 |
| h_asahina | if we use User API, that means all user will be authenticated by CA, so such contradiction won't occur. | 15:36 |
| h_asahina | am I correct? | 15:37 |
| knikolla | yes, there are multiple way to not require uploading a credential for each user | 15:38 |
| *** dviroel is now known as dviroel|lunch | 15:39 | |
| knikolla | they involve some mechanism to map a cert's attributes to a user | 15:39 |
| knikolla | This is already done for all federation mechanisms via federation mappings | 15:39 |
| knikolla | It might also be of interest to see how LDAP maps into a user | 15:41 |
| knikolla | (which is a different method from federation) | 15:41 |
| h_asahina | let me confirm. I think we can authenticate users with their id/password even if we use mutual TLS. | 15:41 |
| h_asahina | I mean user can authenticate without registering their cert in advance. | 15:42 |
| h_asahina | and then register the cert corresponding to the OAuth2.0 client to credentials API | 15:42 |
| knikolla | What would happen if another user registers the same thumbprint? | 15:43 |
| h_asahina | I think it's possible to ignore a chiken and egg issue you mentioned by the above step. but meaningless | 15:43 |
| h_asahina | right? | 15:43 |
| knikolla | You'd need to provide a mechanism for verifying that the user is in possession of the private part to prevent DN squatting | 15:45 |
| knikolla | So it's not exactly as easy as just registering the public part | 15:46 |
| h_asahina | yes. in the above step untrusted user can register thumbprint | 15:47 |
| h_asahina | that makes checking DN itself meaningless | 15:47 |
| knikolla | from my point of view, the mapping mechanism with federation mappings makes for sense and is already used by other cert/assertion/saml authentication methods | 15:49 |
| h_asahina | okey. we'll try to transplant the mapping of federation to our case. | 15:50 |
| knikolla | we also have an API now for pre-creating federated users https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ussuri/support-federated-attr.html | 15:50 |
| h_asahina | is this something like feature that we can reuse existing users for federation? | 15:51 |
| knikolla | yes | 15:52 |
| knikolla | you can patch an already existing user to be a federated user | 15:52 |
| h_asahina | I see. i'm not sure it suitable for our use case now, but will check it. thanks. | 15:53 |
| *** dasm is now known as dasm|off | 15:54 | |
| dmendiza[m] | Getting close to time, y'all. | 15:54 |
| h_asahina | okey. I'll update spec based on today's discussion. thanks. | 15:55 |
| dmendiza[m] | Thank you h_asahina | 15:55 |
| dmendiza[m] | #topic Open Discussion | 15:55 |
| dmendiza[m] | any < 5 min topic y'all would like to talk about? | 15:55 |
| h_asahina | if there's no topic, i'd like to remind keystonemiddleware Zuul error I reported before. there're some patches this erros appear. | 15:57 |
| h_asahina | https://review.opendev.org/c/openstack/keystonemiddleware/+/851319 | 15:57 |
| h_asahina | https://review.opendev.org/c/openstack/keystonemiddleware/+/830737 | 15:58 |
| h_asahina | the erros: | 15:58 |
| h_asahina | File "/home/zuul/src/opendev.org/openstack/keystonemiddleware/keystonemiddleware/tests/unit/audit/test_logging_notifier.py", line 36, in test_api_request_no_messaging | 15:58 |
| h_asahina | call_args = log.call_args_list[0][0] | 15:58 |
| h_asahina | IndexError: list index out of range | 15:58 |
| knikolla | yep, will quickly +2 once I see CI happy. | 15:58 |
| knikolla | Thanks! | 15:58 |
| h_asahina | got it. thanks | 15:58 |
| dmendiza[m] | I'll keep an eye out for those too. | 16:00 |
| dmendiza[m] | And that's all the time we have for the meeting. | 16:00 |
| dmendiza[m] | Thanks for joining, y'all | 16:00 |
| dmendiza[m] | #endmeeting | 16:00 |
| opendevmeet | Meeting ended Tue Aug 9 16:00:51 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-08-09-15.02.html | 16:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-08-09-15.02.txt | 16:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-08-09-15.02.log.html | 16:00 |
| *** dviroel|lunch is now known as dviroel | 16:51 | |
| *** dasm|off is now known as dasm | 18:23 | |
| *** lifeless_ is now known as lifeless | 18:24 | |
| *** dviroel is now known as dviroel|biab | 19:34 | |
| *** dviroel|biab is now known as dviroel | 20:13 | |
| *** dasm is now known as dasm|off | 20:43 | |
| *** dviroel is now known as dviroel|out | 21:17 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!