| opendevreview | OpenStack Proposal Bot proposed openstack/keystone master: Imported Translations from Zanata https://review.opendev.org/c/openstack/keystone/+/846851 | 03:08 |
|---|---|---|
| opendevreview | OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Imported Translations from Zanata https://review.opendev.org/c/openstack/keystonemiddleware/+/846852 | 03:11 |
| opendevreview | Stephen Finucane proposed openstack/keystone master: sql: Add support for auto-generation https://review.opendev.org/c/openstack/keystone/+/826147 | 10:13 |
| *** dviroel|out is now known as dviroel | 11:30 | |
| *** dasm|off is now known as dasm | 13:33 | |
| dmendiza[m] | #startmeeting keystone | 15:03 |
| opendevmeet | Meeting started Tue Jun 21 15:03:15 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:03 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:03 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:03 |
| dmendiza[m] | #topic Roll Call | 15:03 |
| knikolla | o/ | 15:05 |
| dmendiza[m] | Hi knikolla ! | 15:05 |
| h_asahina | o/ | 15:06 |
| dmendiza[m] | OK, let's get started | 15:08 |
| dmendiza[m] | #topic Review Past Meeting Action Items | 15:08 |
| dmendiza[m] | #link https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-06-14-15.04.html | 15:08 |
| dmendiza[m] | > dmendiza[m] to try to run keystone from a fresh clone | 15:09 |
| dmendiza[m] | I did not do this | 15:09 |
| * dmendiza[m] kicks can down the road | 15:09 | |
| dmendiza[m] | #action dmendiza[m] to try to run keystone from a fresh clone | 15:09 |
| dmendiza[m] | #topic Liaison Update | 15:15 |
| dmendiza[m] | I don't have any 😅 | 15:15 |
| dmendiza[m] | #topic OAuth 2.0 | 15:16 |
| dmendiza[m] | h_asahina: any updates for this week? | 15:16 |
| h_asahina | it's not update, but I'd like to discuss the contents of Spec. | 15:17 |
| dmendiza[m] | sure | 15:17 |
| h_asahina | thanks. | 15:17 |
| h_asahina | As I described in the spec, We're going to implement RFC8705 in Zed. | 15:18 |
| h_asahina | As you may know, RFC8705 is a kind of extension of OAuth2.0 which binds the client certificates to the OAuth2.0 access tokens to verify the identity of clients. | 15:19 |
| h_asahina | The problem is to use rfc8705, we need to store the client certificates to DB in some way. | 15:20 |
| h_asahina | Since we used the application credentials table for OAuth2.0 client management in Yoga, we can't change the DB schema easily. | 15:21 |
| h_asahina | So I suggested that to simply store a client certificate as a secret of the application credentials as a workaround. | 15:22 |
| h_asahina | Do you think it's possible? | 15:23 |
| h_asahina | or do you have any other good idea other than adding a new table for the OAuth2.0 client management | 15:23 |
| dmendiza[m] | Hmmm.... why are you trying to avoid schema changes? | 15:24 |
| h_asahina | because I thought changing the application credentials table for OAuth2.0 is not good idea. | 15:25 |
| h_asahina | it will be unrelated changes for the application credentials | 15:26 |
| dmendiza[m] | Right, but we could add a new table for OAuth2.0 | 15:27 |
| dmendiza[m] | I can think of a few ways to solve this: | 15:27 |
| dmendiza[m] | * save certs in the database by creating a new table | 15:27 |
| dmendiza[m] | * save certs locally in the file system (this is probably a bad idea if we run multiple api nodes) | 15:28 |
| dmendiza[m] | * save certs in etcd | 15:28 |
| dmendiza[m] | * save certs in barbican | 15:28 |
| h_asahina | `save certs in barbican`. This might be better. | 15:29 |
| knikolla | i don't think we should use application credentials for this in particular. | 15:29 |
| knikolla | as this is a different type of credential from a client/secret or username/password. | 15:30 |
| knikolla | so we need to change the API to allow to associate a user with a certificate | 15:31 |
| h_asahina | I understand that we shouldn't use application credentials for this, but if we add a new table, we need to add new OAuth2.0 API to manage the client. | 15:32 |
| h_asahina | We have to do that because we're using the applicaton credentials API for client management now. is that ok to add new APIs for this purpose? | 15:34 |
| knikolla | it's less about the database, and more about the API. I'm okay with associating some PKI with a user and then using that to authenticate. | 15:34 |
| knikolla | I don't want keystone to have APIs specific to client management, but credential management is okay I think. | 15:35 |
| knikolla | And requiring Barbican for this seems fair. | 15:36 |
| h_asahina | I agree about Barbican. | 15:36 |
| h_asahina | okey. I wrote the scenario for adding a new table in Alternatives block of Spec. Cloud you check that later? | 15:37 |
| knikolla | yes, thanks! | 15:38 |
| h_asahina | thanks. but, sorry, one more question. | 15:39 |
| knikolla | keystone does have an API for associating credentials with a user https://docs.openstack.org/api-ref/identity/v3/#credentials, but i'm not familiar with it and it perhaps might be something we can use here. | 15:39 |
| h_asahina | thanks | 15:40 |
| h_asahina | I think Keystone also has authentication using PKI: https://docs.openstack.org/keystone/pike/advanced-topics/configure_tokenless_x509.html | 15:41 |
| h_asahina | do you think we use it for this purpose. I don't understand the details of it. | 15:42 |
| h_asahina | /purpose./purpose?/ | 15:43 |
| knikolla | Correct. I'm not very familiar with it, however my understanding is that it can only work for certificates issued by trusted authorities, rather than allowing a user to upload their own self-signed certificate | 15:44 |
| knikolla | Depending on your use case, it may work. | 15:44 |
| h_asahina | > only work for certificates by trusted authorities. If so, it might be not suitable. | 15:46 |
| h_asahina | thanks. I felt the use case of tokenless_x509 is a little bit different, so I'd like to confirm. that's why I asked. | 15:47 |
| h_asahina | I'll check the Credentials API and update the Spec if necessary. | 15:47 |
| dmendiza[m] | Thanks, h_asahina | 15:48 |
| dmendiza[m] | #topic Gate inherited assignments from parent (bbobrov) | 15:48 |
| dmendiza[m] | bbobrov: around? | 15:48 |
| *** dviroel is now known as dviroel|lunch | 15:52 | |
| dmendiza[m] | I guess not | 15:54 |
| dmendiza[m] | and that's almost the end of the hour | 15:54 |
| dmendiza[m] | Thanks for joining, y'all | 15:55 |
| dmendiza[m] | #endmeeting | 15:55 |
| opendevmeet | Meeting ended Tue Jun 21 15:55:03 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:55 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-06-21-15.03.html | 15:55 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-06-21-15.03.txt | 15:55 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-06-21-15.03.log.html | 15:55 |
| *** dviroel|lunch is now known as dviroel | 16:38 | |
| opendevreview | Ade Lee proposed openstack/keystone master: Move fips job to centos-9 https://review.opendev.org/c/openstack/keystone/+/847079 | 18:23 |
| *** dviroel is now known as dviroel|afk | 20:06 | |
| *** dasm is now known as dasm|off | 21:38 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!