| *** dviroel|biab is now known as dviroel | 11:29 | |
| *** dasm|off is now known as dasm | 13:15 | |
| *** Guest3528 is now known as h-asahina | 15:03 | |
| *** dviroel is now known as dviroel|lunch | 15:07 | |
| dmendiza[m] | Hey! | 15:10 |
|---|---|---|
| dmendiza[m] | Sorry y'all, in a video call for work and lost track of time | 15:11 |
| dmendiza[m] | #startmeeting keystone | 15:11 |
| opendevmeet | Meeting started Tue Jul 5 15:11:28 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:11 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:11 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:11 |
| dmendiza[m] | #topic Roll Call | 15:11 |
| 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:11 |
| knikolla | o/ | 15:12 |
| d34dh0r53 | o/ sorry for being late | 15:12 |
| dmendiza[m] | No worries, I was late too 😅 | 15:13 |
| dmendiza[m] | OK, let's get started | 15:13 |
| h-asahina | o/ | 15:13 |
| dmendiza[m] | #topic Review Past Meeting Action Items | 15:13 |
| dmendiza[m] | #link https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-06-28-15.00.html | 15:13 |
| dmendiza[m] | I did not do the thing | 15:13 |
| * dmendiza[m] kicks can down the road again | 15:13 | |
| dmendiza[m] | #action dmendiza[m] to try to run keystone from a fresh clone | 15:14 |
| dmendiza[m] | Moving on ... | 15:14 |
| dmendiza[m] | #topic Liaison Updates | 15:14 |
| dmendiza[m] | I don't have any updates | 15:15 |
| dmendiza[m] | #topic Oauth 2.0 | 15:15 |
| dmendiza[m] | h_asahina around? | 15:16 |
| h-asahina | yes | 15:16 |
| dmendiza[m] | Hi | 15:16 |
| dmendiza[m] | Do you want to talk about your agenda topic? | 15:16 |
| h-asahina | yes | 15:16 |
| dmendiza[m] | > The way of binding a client certificate to OAuth2.0 access token (h-asahina) | 15:16 |
| h-asahina | thanks that's my topic | 15:16 |
| h-asahina | I feel we have to confirm the way to bind a client certificate to an access token | 15:17 |
| h-asahina | I think we have two options | 15:17 |
| h-asahina | A) adding the information of cert (e.g., DN/thumbprint) to fernet/JWT token. | 15:18 |
| h-asahina | B) adding a new DB table consisting of the information of cert and corresponding token that is bound to the certificate | 15:18 |
| h-asahina | IMO, The straight forward way is A. | 15:19 |
| knikolla | does the oauth mtls rfc require a bearer token be bound to a certificate? | 15:19 |
| h-asahina | I think so. rfc8705 defines that case. | 15:20 |
| h-asahina | https://datatracker.ietf.org/doc/html/rfc8705 | 15:20 |
| knikolla | ah, it's in the rfc title. "certificate-bound access tokens" | 15:21 |
| h-asahina | yeah | 15:22 |
| h-asahina | that's why I consider this as a fundamental requiremnt. | 15:23 |
| knikolla | " | 15:23 |
| knikolla | Mutual-TLS certificate-bound access tokens and mutual-TLS client authentication are distinct mechanisms that are complementary but don't necessarily need to be deployed or used together." | 15:23 |
| knikolla | The rfc introduces both as separate mechanisms | 15:23 |
| h-asahina | that menas the client authentication and binding token to certificate are separated process. | 15:24 |
| h-asahina | in any case, to follow the rfc, token should be bound to the client certificate | 15:26 |
| knikolla | i understand | 15:26 |
| h-asahina | for instance, during the token introspection, thumbprint of the certificate is used to confirm the authenticity of the client. | 15:27 |
| knikolla | i'd definitely favor approach A | 15:27 |
| h-asahina | so do I | 15:27 |
| h-asahina | but to do so, we need to modify the token payload class | 15:27 |
| h-asahina | https://github.com/openstack/keystone/blob/master/keystone/token/token_formatters.py#L222-L225 | 15:28 |
| h-asahina | Specifically, args of the token payload | 15:28 |
| h-asahina | because it is designed to only accept some predefined parameters. | 15:28 |
| knikolla | yes | 15:29 |
| h-asahina | there many places calling this class, so we have to change many parts, is that okey? | 15:29 |
| d34dh0r53 | I'm not sure that it is required per "Other methods of associating a | 15:29 |
| d34dh0r53 | certificate with an access token are possible, per agreement by the | 15:30 |
| d34dh0r53 | authorization server and the protected resource, but are beyond the | 15:30 |
| d34dh0r53 | scope of this specification. | 15:30 |
| knikolla | d34dh0r53: yeah, you can only choose to support mtls for authentication, without bounding. But my understanding is that h-asahina requires the full implementation of the RFC for NFV certification? | 15:31 |
| knikolla | you can choose to only* | 15:31 |
| d34dh0r53 | ahh, good point | 15:31 |
| h-asahina | what knikolla: said is right. we need to implement it. | 15:32 |
| d34dh0r53 | ok | 15:33 |
| h-asahina | I think adding an additional parameters to token payload won't ruin the Keystone functionalities. | 15:33 |
| h-asahina | but if you can't accept it or if you have any alternative ideas, please let me know | 15:34 |
| knikolla | I think I'm okay with it. But I'm not a cryptography expert. | 15:34 |
| d34dh0r53 | no, I think I'm ok, I just got hung up on the word required | 15:34 |
| knikolla | d34dh0r53: based on my prior experience reading OAuth 2.0 specs, nothing is required, everything is optional, and hence everything is a confusing mess of who supports what. | 15:35 |
| d34dh0r53 | knikolla: lol, sounds about right | 15:36 |
| h-asahina | that's what's giving me a headache when writing specs. | 15:37 |
| h-asahina | netheir i'm expert for crypto | 15:37 |
| h-asahina | but, as you know, the fernet is encrypted by the secret key of Keystone, there's no impact on the security if we add fields to the payload | 15:38 |
| knikolla | yeah, just need to be careful with not putting too much stuff in there due to increasing size. | 15:39 |
| h-asahina | sure | 15:39 |
| knikolla | i guess it's not a concern here, since a thumbprint would be pretty small | 15:39 |
| h-asahina | yes. that's right. | 15:40 |
| h-asahina | okey. I'll go with the option A | 15:40 |
| dmendiza[m] | Sounds good | 15:41 |
| h-asahina | btw, the dead line of spec is 14 July, right? can we make it? | 15:41 |
| h-asahina | https://releases.openstack.org/zed/schedule.html#z-2 | 15:42 |
| dmendiza[m] | I hope so. 🤞 We'll review the spec again on Friday for the Reviewathon | 15:42 |
| knikolla | yeah, should be fine. worst case we may grant an exception/extensions. | 15:43 |
| h-asahina | great. thanks a lot. | 15:43 |
| dmendiza[m] | OK, moving on | 15:43 |
| dmendiza[m] | #topic Secure RBAC | 15:43 |
| dmendiza[m] | I still feel a bit out of the loop on the latest SRBAC happenings. I'll have to catch up with gmann soon. | 15:44 |
| dmendiza[m] | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline | 15:44 |
| dmendiza[m] | We're still on the hook for: | 15:45 |
| knikolla | my understanding is that we're keeping "project admin is global admin" and holding off on any system scope things. | 15:45 |
| dmendiza[m] | > Keystone starts implementing support for manager across project, domain, and system scopes. | 15:45 |
| knikolla | so we need to make sure our new policies work with project-admin for global admin operations | 15:45 |
| dmendiza[m] | gotcha | 15:45 |
| dmendiza[m] | I can work on that | 15:45 |
| knikolla | and for actual project level admin operations, support manager | 15:45 |
| dmendiza[m] | Yeah, I think the patch for the "manager" role was stalled on whether we're handling existing "manager" roles appropriately | 15:46 |
| dmendiza[m] | I'll add that to my TODO list | 15:46 |
| knikolla | I think a strongly worded release note and upgrade note should do the trick | 15:47 |
| dmendiza[m] | Hehe, yeah, that should be the minimum | 15:47 |
| dmendiza[m] | I was think maybe keystone-boostrap could throw an error if it finds an existing "manager" role? | 15:47 |
| knikolla | I'd look at what we did for the "reader" role | 15:48 |
| knikolla | when we introduced it | 15:48 |
| knikolla | and just repeat the same | 15:48 |
| knikolla | initially keystone didn't mandate any roles (except admin), and then we introduced member and reader | 15:48 |
| knikolla | so the process that we followed then, can be the same | 15:48 |
| dmendiza[m] | sounds good | 15:48 |
| knikolla | i think throwing an error on the existence of a manager role is going to be hard, given that bootstrap is supposed to be idempotent | 15:50 |
| knikolla | but also, i'm not sure that "bootstrap" is something that we tell people to run after their initial setup | 15:51 |
| dmendiza[m] | Looks like we tell folks to `keystone-manage bootstrap` in the installation guides: | 15:53 |
| dmendiza[m] | #link https://docs.openstack.org/keystone/latest/install/index.html | 15:53 |
| dmendiza[m] | In any case, I'll do the needful to make sure we're on track for Keystone's SRBAC | 15:54 |
| dmendiza[m] | Not sure we have enough time to talk about any other specs | 15:55 |
| dmendiza[m] | So let's call it a meeting. | 15:55 |
| dmendiza[m] | Thanks for joining, y'all. | 15:56 |
| dmendiza[m] | #endmeeting | 15:56 |
| opendevmeet | Meeting ended Tue Jul 5 15:56:10 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:56 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-07-05-15.11.html | 15:56 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-07-05-15.11.txt | 15:56 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-07-05-15.11.log.html | 15:56 |
| *** dviroel|lunch is now known as dviroel | 16:22 | |
| *** dviroel is now known as dviroel|afk | 21:59 | |
| *** dasm is now known as dasm|off | 22:02 | |
| *** dviroel|afk is now known as dviroel | 23:27 | |
| *** dviroel is now known as dviroel|out | 23:50 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!