| opendevreview | Yusuke Niimi proposed openstack/keystonemiddleware master: OAuth2.0 Client Credentials Grant Flow Support https://review.opendev.org/c/openstack/keystonemiddleware/+/830737 | 00:38 |
|---|---|---|
| *** tkajinam|off is now known as tkajinam | 05:48 | |
| opendevreview | Yusuke Niimi proposed openstack/keystonemiddleware master: OAuth2.0 Client Credentials Grant Flow Support https://review.opendev.org/c/openstack/keystonemiddleware/+/830737 | 09:42 |
| *** dviroel is now known as dviroel}rover | 11:26 | |
| *** dviroel}rover is now known as dviroel|rover | 11:26 | |
| *** dasm|off is now known as dasm | 13:28 | |
| *** dviroel|rover is now known as dviroel|rover|lunch | 14:59 | |
| dmendiza[m] | #startmeeting keystone | 15:01 |
| opendevmeet | Meeting started Tue Aug 23 15:01:07 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:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:01 |
| 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 |
| knikolla | o/ | 15:01 |
| xek | o/ | 15:02 |
| d34dh0r53 | o/ meeting conflict so lurking | 15:02 |
| h-asahina | o/ | 15:02 |
| dmendiza[m] | Hi everyone! | 15:02 |
| dmendiza[m] | Let's get started | 15:02 |
| dmendiza[m] | As usual the agenda is over here: | 15:02 |
| dmendiza[m] | #link https://etherpad.opendev.org/p/keystone-weekly-meeting | 15:02 |
| dmendiza[m] | #topic Review Past Meeting Action Items | 15:03 |
| dmendiza[m] | #link https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-08-16-15.01.html | 15:03 |
| dmendiza[m] | We didn't have any | 15:03 |
| dmendiza[m] | Moving on ... | 15:03 |
| dmendiza[m] | #topic Liaison Updates | 15:03 |
| dmendiza[m] | Zed-3 milestone is next week: | 15:04 |
| dmendiza[m] | #link https://releases.openstack.org/zed/schedule.html#z-3 | 15:04 |
| dmendiza[m] | We should definitely try to land all we can before then. | 15:05 |
| dmendiza[m] | Which is a nice segue into | 15:05 |
| dmendiza[m] | #topic OAuth 2.0 | 15:05 |
| dmendiza[m] | We should try to land the outstanding patches that have been in review for a while | 15:05 |
| dmendiza[m] | before Z-3 | 15:05 |
| dmendiza[m] | hopefully knikolla will be around for the reviewathon | 15:06 |
| dmendiza[m] | the last one was not very productive without him 😅 | 15:06 |
| dmendiza[m] | h-asahina: any updates this week? | 15:06 |
| h-asahina | as dmendiza say, please kindly review the remaining patches :) | 15:07 |
| knikolla | i will be around for the reviewathon | 15:07 |
| knikolla | and will try to catch up on everything i missed before then | 15:07 |
| dmendiza[m] | knikolla: awesome! | 15:07 |
| dmendiza[m] | I'll try to do some pre-reviewing before then | 15:07 |
| h-asahina | thanks. I'd really appreciate that. | 15:07 |
| h-asahina | knikolla: if you have time today, i'd like to discuss my comments on the spec | 15:08 |
| h-asahina | https://review.opendev.org/c/openstack/keystone-specs/+/843765 | 15:08 |
| h-asahina | https://review.opendev.org/c/openstack/keystone-specs/+/843765/comments/80f8ff28_abd70078 | 15:09 |
| h-asahina | might be better to paste the link of the comment. | 15:09 |
| h-asahina | i have two questionts as I wrote in the above comment: i) delegation of user's permission to OAuth2.0 client; ii) usage of the existing federation mapping API. | 15:11 |
| knikolla | for 1, we only have 2 mechanisms for only providing a subset of access. | 15:11 |
| knikolla | application credentials and trusts | 15:11 |
| knikolla | this is not something that the credential api is able to provide and would need to be changed to offer that | 15:12 |
| knikolla | for 2, yes. that matches my thoughts. you'd register a federation mapping with your mapping rule and use it when authenticating. | 15:13 |
| h-asahina | for 2, I think we also have an option that writing mapping to keystone.conf | 15:14 |
| h-asahina | like: [oauth2] | 15:14 |
| h-asahina | dn_mapping_user_id=UID | 15:14 |
| h-asahina | dn_mapping_user_name=CN | 15:14 |
| h-asahina | dn_mapping_user_email=emailAddress | 15:14 |
| h-asahina | dn_mapping_user_domain_id=DC | 15:14 |
| h-asahina | dn_mapping_user_domain_name=O | 15:14 |
| h-asahina | this must work | 15:15 |
| knikolla | yes, however that type of configuration locks you into only being able to support one CA | 15:15 |
| h-asahina | if we assume the different CA have different mapping rules, yes. | 15:16 |
| h-asahina | if we use mapping API, we have to specify mapping_id to use in any case. | 15:17 |
| h-asahina | so we have to specify a specific mapping_id in somewhere | 15:18 |
| knikolla | with mappings you'd have: one mapping rule, one identity provider (with the issuer url), and one federation mapping, mapping a rule with an idp | 15:19 |
| knikolla | this is what connects it together | 15:19 |
| h-asahina | I see | 15:20 |
| h-asahina | it more flexible than directly writing the mappings in the .conf, like you said. | 15:20 |
| knikolla | we're already integrating keystone with openid connect, oauth2.0 and saml identity providers. I don't see why this should be different, except for providing the same mechanisms but protected from a cert via mTLS. | 15:21 |
| h-asahina | but I'm also concerned that user shouldn't have to have a permission to change this rule. | 15:21 |
| knikolla | this can only be changed from the administrator/operator | 15:22 |
| knikolla | changing rules requires admin | 15:22 |
| h-asahina | if we use .conf, only the cloud admin who can ssh into host machine can change the config | 15:23 |
| knikolla | i'm fairly sure you can currently authenticate using OAuth mTLS using federation, today. | 15:23 |
| knikolla | without any changes to keystone. | 15:23 |
| h-asahina | you meant, with mapping API? | 15:24 |
| knikolla | yes. | 15:24 |
| h-asahina | I agree with that we can realize OAuth mtls by such way. | 15:25 |
| h-asahina | but | 15:25 |
| knikolla | we already support authenticating via apache, apache supports authenticating via mTLS, we can give you a token based on the attributes that apache gives passing them through a mapping | 15:25 |
| knikolla | the only mechanism that is missing is tying a token to a cert. | 15:25 |
| h-asahina | like I said if we want to make this more secure, writing mapping to .conf can be an option | 15:26 |
| knikolla | only a person with the global admin can change mapping rules | 15:26 |
| knikolla | this won't make it any more secure than that | 15:26 |
| h-asahina | normally, the cloud admin and the admin user of keystone are different. | 15:27 |
| h-asahina | the clould admin who build the openstack environment have stronger permission than the any users created by openstack. | 15:27 |
| knikolla | but anyone who has admin access to keystone can create all the users they want, so i don't see the added level of protection you're getting here | 15:28 |
| h-asahina | okey. that's true. permission for changing mapping rules and that for creating users is the same things in terms of security level. | 15:29 |
| h-asahina | indeed. I'm convinced. | 15:30 |
| h-asahina | thanks. I need to clarify that our choice would be a better option than the others. that's why I asked. | 15:31 |
| knikolla | I can try to build out a demo this week and see how far I can get with the current mapping mechanisms trying to authenticate with mTLS using OAuth in Keystone | 15:31 |
| knikolla | and you can tell me if that works for you or goes against your use case | 15:32 |
| knikolla | from that, it shouldn't be hard to just add the thumbprint to tokens received via that type of authentication and add that extra check on the thumbprint | 15:32 |
| h-asahina | awesome. thank you. | 15:33 |
| h-asahina | yeah, I also think it shouldn't be hard. | 15:33 |
| dmendiza[m] | 👍️ | 15:34 |
| h-asahina | I'll recheck the spec and update if it's necessary | 15:34 |
| h-asahina | ah, sorry, for 1 | 15:34 |
| h-asahina | if we want to delegate user's permission is there any option to realize that? | 15:35 |
| knikolla | yes, i think you should look into trusts | 15:35 |
| knikolla | i think they give you what you're looking for | 15:35 |
| h-asahina | okey. I briefly checked it. certainly, it looks the solution. | 15:36 |
| knikolla | when a user requests a cert to your CA, you can create a new user for the cert, delegate the roles on that project from the requesting user to the new user, and create a Cert for that user instead | 15:36 |
| knikolla | trusts even have an "impersonation" flag that makes it look like all operations from that user were done but the trustor | 15:38 |
| h-asahina | I see. it looks enough. we originaly thought use the user's (truster) credentials when issuing the token for the client created by user. | 15:40 |
| h-asahina | but looks the "trust" realize that in more natural way. | 15:40 |
| knikolla | yeah, clients are just a slightly different type of user semantically | 15:41 |
| knikolla | unfortunately in keystone we can only deal with users at the moment, and not have special types :) | 15:41 |
| h-asahina | got it. whether using this feature as a fundamental requirement to use OAuth2.0 or not is another discussing point, but I think it's enough that we can realize delegation, for now. | 15:42 |
| knikolla | yeah, i think it should work | 15:42 |
| knikolla | if there was more of us, i'd be more than happy to try to rethink new concepts and build clients/users/service account/vm account/etc into the APIs that keystone provides. | 15:43 |
| h-asahina | I eager that | 15:44 |
| knikolla | but then the rest of openstack would kill us, and still use v3 until the end of times | 15:44 |
| knikolla | haha | 15:44 |
| h-asahina | yeah, I know the current keystone isn't, and hard to change it. | 15:45 |
| h-asahina | alright. my question was resolved. thank you very much knikolla :) | 15:45 |
| knikolla | thank you :) | 15:46 |
| dmendiza[m] | awesome, sounds like we've got a good path forward | 15:47 |
| dmendiza[m] | Anything else before we move on? | 15:47 |
| h-asahina | from me, no. it's okey. | 15:48 |
| dmendiza[m] | OK, lets see if I can cover some Secure RBAC in the rest of the time | 15:49 |
| dmendiza[m] | #topic Secure RBAC | 15:49 |
| dmendiza[m] | I was reviewing the latest changes to the community goal: | 15:49 |
| dmendiza[m] | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html | 15:49 |
| dmendiza[m] | Looks like Phase 1 changed for us to: | 15:49 |
| dmendiza[m] | > 1. Remove the scope string (system:all) from the policy rule check_str. | 15:49 |
| dmendiza[m] | > 2. Add the project in scope_type in every policy rule. | 15:49 |
| dmendiza[m] | For 1, I don't quite understand what "system:all" does in the policy rules? | 15:50 |
| knikolla | gmann: ^^ | 15:51 |
| dmendiza[m] | There's a note about it in the base policy: | 15:51 |
| dmendiza[m] | #link https://opendev.org/openstack/keystone/src/commit/1dd6993d7b9b647810e6f495b62c37627c6e8658/keystone/common/policies/base.py#L35-L46 | 15:51 |
| dmendiza[m] | seems it's there to prevent situations where the new rules are more premissive | 15:52 |
| gmann | dmendiza[m]: knikolla: that was added to protect the project reader to behave as system reader when scope is disabled | 15:52 |
| gmann | that was needed until enforce_scope become true by default | 15:52 |
| dmendiza[m] | Wouldn't that still be an issue if we remove it? | 15:53 |
| dmendiza[m] | Or should we default enforce_scope=True to avoid that issue? | 15:54 |
| dmendiza[m] | gmann: ^^ | 15:55 |
| gmann | actually we are opening the policy for project scope too so it is not issue any more because with enforce_scope true or false, project reader should be able to access those | 15:55 |
| gmann | new direction is, project and system reader both should have access. those are not system only things anymore | 15:56 |
| knikolla | Ah right :) | 15:57 |
| gmann | means if anyone already or will try to access system reader API they should continue able to do that. and our legacy way with project token can also continue the access | 15:57 |
| gmann | we want everything as project scoped in other services like nova etc but in keystone letting both token work | 15:58 |
| knikolla | And for admin, the project level thing is manager. So scope is not an issue here either eventually. | 15:58 |
| gmann | yeah | 15:58 |
| knikolla | Thanks gmann | 15:58 |
| dmendiza[m] | I see ... | 15:58 |
| gmann | next week or sometime I should be able to push the change and you can verify how it looks like | 15:59 |
| dmendiza[m] | gmann: sounds good. | 15:59 |
| dmendiza[m] | Alrighty, y'all. That's all the time we have scheduled for the meeting | 16:00 |
| dmendiza[m] | thanks for joining! | 16:00 |
| dmendiza[m] | #endmeering | 16:00 |
| dmendiza[m] | #endmeeting | 16:00 |
| opendevmeet | Meeting ended Tue Aug 23 16:00:23 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-23-15.01.html | 16:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-08-23-15.01.txt | 16:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-08-23-15.01.log.html | 16:00 |
| knikolla | Thanks dmendiza[m] | 16:00 |
| *** dviroel|rover|lunch is now known as dviroel|rover | 16:27 | |
| *** dasm is now known as dasm|off | 22:29 | |
| *** dviroel|rover is now known as dviroel|out | 22:31 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!