15:01:07 <dmendiza[m]> #startmeeting keystone
15:01:07 <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:07 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:07 <opendevmeet> The meeting name has been set to 'keystone'
15:01:17 <dmendiza[m]> #topic Roll Call
15:01:26 <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:55 <knikolla> o/
15:02:02 <xek> o/
15:02:05 <d34dh0r53> o/ meeting conflict so lurking
15:02:12 <h-asahina> o/
15:02:28 <dmendiza[m]> Hi everyone!
15:02:33 <dmendiza[m]> Let's get started
15:02:48 <dmendiza[m]> As usual the agenda is over here:
15:02:51 <dmendiza[m]> #link https://etherpad.opendev.org/p/keystone-weekly-meeting
15:03:06 <dmendiza[m]> #topic Review Past Meeting Action Items
15:03:14 <dmendiza[m]> #link https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-08-16-15.01.html
15:03:18 <dmendiza[m]> We didn't have any
15:03:38 <dmendiza[m]> Moving on ...
15:03:49 <dmendiza[m]> #topic Liaison Updates
15:04:39 <dmendiza[m]> Zed-3 milestone is next week:
15:04:41 <dmendiza[m]> #link https://releases.openstack.org/zed/schedule.html#z-3
15:05:04 <dmendiza[m]> We should definitely try to land all we can before then.
15:05:09 <dmendiza[m]> Which is a nice segue into
15:05:18 <dmendiza[m]> #topic OAuth 2.0
15:05:44 <dmendiza[m]> We should try to land the outstanding patches that have been in review for a while
15:05:50 <dmendiza[m]> before Z-3
15:06:02 <dmendiza[m]> hopefully knikolla will be around for the reviewathon
15:06:13 <dmendiza[m]> the last one was not very productive without him 😅
15:06:37 <dmendiza[m]> h-asahina: any updates this week?
15:07:15 <h-asahina> as dmendiza say, please kindly review the remaining patches :)
15:07:26 <knikolla> i will be around for the reviewathon
15:07:41 <knikolla> and will try to catch up on everything i missed before then
15:07:46 <dmendiza[m]> knikolla: awesome!
15:07:52 <dmendiza[m]> I'll try to do some pre-reviewing before then
15:07:59 <h-asahina> thanks. I'd really appreciate that.
15:08:33 <h-asahina> knikolla: if you have time today, i'd like to discuss my comments on the spec
15:08:38 <h-asahina> https://review.opendev.org/c/openstack/keystone-specs/+/843765
15:09:13 <h-asahina> https://review.opendev.org/c/openstack/keystone-specs/+/843765/comments/80f8ff28_abd70078
15:09:33 <h-asahina> might be better to paste the link of the comment.
15:11:32 <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:46 <knikolla> for 1, we only have 2 mechanisms for only providing a subset of access.
15:11:52 <knikolla> application credentials and trusts
15:12:24 <knikolla> this is not something that the credential api is able to provide and would need to be changed to offer that
15:13:36 <knikolla> for 2, yes. that matches my thoughts. you'd register a federation mapping with your mapping rule and use it when authenticating.
15:14:21 <h-asahina> for 2, I think we also have an option that writing mapping to keystone.conf
15:14:33 <h-asahina> like:  [oauth2]
15:14:35 <h-asahina> dn_mapping_user_id=UID
15:14:37 <h-asahina> dn_mapping_user_name=CN
15:14:39 <h-asahina> dn_mapping_user_email=emailAddress
15:14:41 <h-asahina> dn_mapping_user_domain_id=DC
15:14:43 <h-asahina> dn_mapping_user_domain_name=O
15:15:10 <h-asahina> this must work
15:15:41 <knikolla> yes, however that type of configuration locks you into only being able to support one CA
15:16:26 <h-asahina> if we assume the different CA have different mapping rules, yes.
15:17:13 <h-asahina> if we use mapping API, we have to specify mapping_id to use in any case.
15:18:53 <h-asahina> so we have to specify a specific mapping_id in somewhere
15:19:25 <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:45 <knikolla> this is what connects it together
15:20:22 <h-asahina> I see
15:20:47 <h-asahina> it more flexible than directly writing the mappings in the .conf, like you said.
15:21:01 <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:42 <h-asahina> but I'm also concerned that user shouldn't have to have a permission to change this rule.
15:22:28 <knikolla> this can only be changed from the administrator/operator
15:22:46 <knikolla> changing rules requires admin
15:23:23 <h-asahina> if we use .conf, only the cloud admin who can ssh into host machine can change the config
15:23:29 <knikolla> i'm fairly sure you can currently authenticate using OAuth mTLS using federation, today.
15:23:34 <knikolla> without any changes to keystone.
15:24:34 <h-asahina> you meant, with mapping API?
15:24:57 <knikolla> yes.
15:25:21 <h-asahina> I agree with that we can realize OAuth mtls by such way.
15:25:23 <h-asahina> but
15:25:42 <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:49 <knikolla> the only mechanism that is missing is tying a token to a cert.
15:26:13 <h-asahina> like I said if we want to make this more secure, writing mapping to .conf can be an option
15:26:29 <knikolla> only a person with the global admin can change mapping rules
15:26:36 <knikolla> this won't make it any more secure than that
15:27:14 <h-asahina> normally, the cloud admin and the admin user of keystone are different.
15:27:50 <h-asahina> the clould admin who build the openstack environment have stronger permission than the any users created by openstack.
15:28:22 <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:29:32 <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:30:57 <h-asahina> indeed. I'm convinced.
15:31:45 <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:49 <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:32:04 <knikolla> and you can tell me if that works for you or goes against your use case
15:32:42 <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:33:10 <h-asahina> awesome. thank you.
15:33:35 <h-asahina> yeah, I also think it shouldn't be hard.
15:34:00 <dmendiza[m]> 👍️
15:34:43 <h-asahina> I'll recheck the spec and update if it's necessary
15:34:56 <h-asahina> ah, sorry, for 1
15:35:18 <h-asahina> if we want to delegate user's permission is there any option to realize that?
15:35:33 <knikolla> yes, i think you should look into trusts
15:35:40 <knikolla> i think they give you what you're looking for
15:36:28 <h-asahina> okey. I briefly checked it. certainly, it looks the solution.
15:36:29 <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:38:02 <knikolla> trusts even have an "impersonation" flag that makes it look like all operations from that user were done but the trustor
15:40:05 <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:53 <h-asahina> but looks the "trust" realize that in more natural way.
15:41:28 <knikolla> yeah, clients are just a slightly different type of user semantically
15:41:58 <knikolla> unfortunately in keystone we can only deal with users at the moment, and not have special types :)
15:42:16 <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:50 <knikolla> yeah, i think it should work
15:43:25 <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:44:28 <h-asahina> I eager that
15:44:48 <knikolla> but then the rest of openstack would kill us, and still use v3 until the end of times
15:44:51 <knikolla> haha
15:45:07 <h-asahina> yeah, I know the current keystone isn't, and hard to change it.
15:45:40 <h-asahina> alright. my question was resolved. thank you very much knikolla :)
15:46:46 <knikolla> thank you :)
15:47:12 <dmendiza[m]> awesome, sounds like we've got a good path forward
15:47:21 <dmendiza[m]> Anything else before we move on?
15:48:06 <h-asahina> from me, no. it's okey.
15:49:04 <dmendiza[m]> OK, lets see if I can cover some Secure RBAC in the rest of the time
15:49:06 <dmendiza[m]> #topic Secure RBAC
15:49:19 <dmendiza[m]> I was reviewing the latest changes to the community goal:
15:49:27 <dmendiza[m]> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html
15:49:35 <dmendiza[m]> Looks like Phase 1 changed for us to:
15:49:47 <dmendiza[m]> > 1. Remove the scope string (system:all) from the policy rule check_str.
15:49:56 <dmendiza[m]> > 2. Add the project in scope_type in every policy rule.
15:50:29 <dmendiza[m]> For 1, I don't quite understand what "system:all" does in the policy rules?
15:51:33 <knikolla> gmann: ^^
15:51:46 <dmendiza[m]> There's a note about it in the base policy:
15:51:50 <dmendiza[m]> #link https://opendev.org/openstack/keystone/src/commit/1dd6993d7b9b647810e6f495b62c37627c6e8658/keystone/common/policies/base.py#L35-L46
15:52:10 <dmendiza[m]> seems it's there to prevent situations where the new rules are more premissive
15:52:24 <gmann> dmendiza[m]: knikolla: that was added to protect the project reader to behave as system reader when scope is disabled
15:52:52 <gmann> that was needed until enforce_scope become true by default
15:53:40 <dmendiza[m]> Wouldn't that still be an issue if we remove it?
15:54:11 <dmendiza[m]> Or should we default enforce_scope=True to avoid that issue?
15:55:36 <dmendiza[m]> gmann: ^^
15:55:49 <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:56:27 <gmann> new direction is, project and system reader both should have access. those are not system only things anymore
15:57:29 <knikolla> Ah right :)
15:57:32 <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:58:09 <gmann> we want everything as project scoped in other services like nova etc but in keystone letting both token work
15:58:20 <knikolla> And for admin, the project level thing is manager. So scope is not an issue here either eventually.
15:58:28 <gmann> yeah
15:58:43 <knikolla> Thanks gmann
15:58:43 <dmendiza[m]> I see ...
15:59:04 <gmann> next week or sometime I should be able to push the change and you can verify how it looks like
15:59:15 <dmendiza[m]> gmann: sounds good.
16:00:13 <dmendiza[m]> Alrighty, y'all.  That's all the time we have scheduled for the meeting
16:00:16 <dmendiza[m]> thanks for joining!
16:00:19 <dmendiza[m]> #endmeering
16:00:23 <dmendiza[m]> #endmeeting