15:00:59 #startmeeting keystone 15:00:59 Meeting started Tue Jun 28 15:00:59 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:59 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:59 The meeting name has been set to 'keystone' 15:01:13 #topic Roll Call 15:01:24 o/ 15:02:01 o/ 15:02:21 o/ 15:02:31 Hi y'all! 15:02:39 as usual the agenda is over here: 15:02:46 #link https://etherpad.opendev.org/p/keystone-weekly-meeting 15:03:00 #topic Review Past Meeting Action Items 15:03:31 #link https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-06-21-15.03.html 15:03:56 > dmendiza[m] to try to run keystone from a fresh clone 15:04:02 * dmendiza[m] kicks the can down the road again 15:04:06 #action dmendiza[m] to try to run keystone from a fresh clone 15:04:21 #topic Liaison Updates 15:05:24 I don't have any updates 15:05:42 #topic OAuth 2.0 15:05:48 h_asahina: any updates this week? 15:06:10 yes. I have two questions 15:06:48 I've confirmed the feasibility of credentials API 15:07:25 I'd like to confirm whether my understanding is correct or not. 15:08:09 sure 15:08:19 thanks, I think this API basically creates the credential for a user. 15:09:06 which is a user can register its own certificate to DB with this API. Am I correct? 15:10:11 In my understanding, it works like the AWS secret manager. 15:11:05 though the difference from the barbican is not clear for me. 15:11:44 knikolla: ^^ 🤔 15:11:58 In a world before barbican, and in which nova also supported an EC2-compatible API, keystone needed (and still needs for Swift's S3 API) a way to support authenticating like in AWS 15:12:20 So I think the Credential API was created to allow a way to create EC2 credentials for a user 15:12:41 I don't think we're using it for anything else, but the way the API was written, is a bit more general purpose. 15:13:16 that's why it also support certificates? 15:15:12 Perhaps? 15:15:38 I would have to look at the code and try to figure out what it does with the payload 15:15:52 I'm not familiar with that part of Keystone 15:16:15 I should probably take a look and we can check back next week 15:16:24 * dmendiza[m] is also not familiar 15:16:41 alright. that's not important for us. it's okey. 15:17:24 things important for us is how to manage OAuth2.0 client with this API. 15:17:44 In OAuth2.0, the credentials are created for a client but not for a user. 15:18:26 In this sense, we have to use ``id`` of credentials created by credentials API as ``client id``. does that make sense? 15:18:59 yes, in your case "a client" would be "a credential" 15:19:42 thanks. that what I want to confirm. 15:20:17 Cool. 15:20:17 naturally the second question is gone, but let me confirm just in case. 15:20:35 OK, anything else on this topic? 15:20:48 unfortunately, everything in openstack is a user, and introducing the concept of a client that is separate from the user would have unintended consequences. 15:20:48 sorry I have one more question 15:21:00 go ahead 15:21:20 what is the reason of encrypting certificates? 15:22:08 you mean certificates uploaded through the credential api? 15:22:16 yes 15:22:29 I think the certificate itself can be public 15:22:45 i think it's because it doesn't make any assumptions about the credential being uploaded 15:22:56 it can be a plain-text password, it can be a symmetric key, it can be PKI 15:23:10 so it just encrypts everything anyway 15:24:12 I see. so even if it might not be needed the certificates are also encrypted. 15:24:51 yeah, because credentials are just stored as a json blob if I remember correctly 15:26:29 yes it can also be a plane text. so there's a risk that user put sensitive information to there. 15:27:00 ok, thank you very much. everything become clear. I think I can update spec this week. 15:27:35 glad i could help :) 15:27:57 Awesome 15:28:00 OK, moving on 15:28:14 #topic Keystone identity mapping to support project definition as a JSON 15:28:31 Hi :) 15:28:32 I'm not sure who added this to the agenda? 🤔 15:29:03 It's me, we talked about it with d34dh0r53, but he doesn't seems to be here 15:29:25 he asked us to bring back this spec before our patches get merged 15:30:00 Gotcha 15:30:02 sorry, tied up in an escalation 15:30:09 OK, we'll review the spec for the next reviewathon 15:30:16 dmendiza[m]: I forwarded you the email about this 15:32:02 d34dh0r53: ack, I'll read up on it 15:32:33 when is the next reviewathon then ? 15:32:57 Indeed it would be good to have your opinion about this spec :) 15:36:14 alistarle: reviewathons are on Fridays ... not sure about the exact UTC time 15:36:23 d34dh0r53: what was the UTC time for the reviewathons? 15:37:12 dmendiza[m]: 15:00 15:37:18 alistarle: ^ 15:37:31 oh nice 15:38:57 looks good to us to discuss about that friday yes 15:39:03 cool 15:39:18 we usually post the link here to the Google Meet video chat 15:40:33 OK, moving on ... 15:40:53 #link Gate inherited assignments from parent (bbobrov) 15:40:54 Any updates on this? 15:42:57 Sounds like no updates 15:43:00 next 15:43:04 #topic Secure RBAC 15:43:11 we still have some work to do for the Zed cycle 15:43:31 I haven't seen any updates on the pop-up meetings so far 15:47:02 #topic Open Discussion 15:47:19 Anything else y'all want to talk about before we look at bugs? 15:50:52 #topic Bug Review 15:55:23 #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 15:55:50 Hot off the bug press 15:55:52 #link https://bugs.launchpad.net/keystone/+bug/1980058 15:56:11 > Openstack keystone LDAP integration | openstack user list --domain domain.com | Internal server error (HTTP 500) 15:58:12 > ldap.FILTER_ERROR: {'result': -7, 'desc': 'Bad search filter', 'ctrls': []} 15:58:31 that might be a misconfiguration of some kind 15:58:37 it's an AD server 15:59:30 so it might be hard to replicate 16:01:13 I'll post a comment in the bug 16:02:12 Thanks, xek 16:02:13 And that's time 16:02:14 thanks for joining, everyone! 16:02:14 #endmeeting