15:02:15 <dmendiza[m]> #startmeeting keystone
15:02:15 <opendevmeet> Meeting started Tue Apr 26 15:02: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:02:15 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:15 <opendevmeet> The meeting name has been set to 'keystone'
15:02:29 <knikolla> o/
15:02:36 <admiyo> O/
15:02:46 <h-asahina> o/
15:02:46 <dmendiza[m]> #topic Roll Call
15:03:00 <dmendiza[m]> Hi everyone!
15:03:13 <knikolla> long time no see admiyo :)
15:03:13 <dmendiza[m]> Doing double duty right now, as I am listening in on the poicy popup meeting
15:03:33 <admiyo> poicy!
15:03:58 <admiyo> Heyo.  Just popped in to see whazzup
15:04:01 <knikolla> there's a policy popup meeting?
15:04:07 <dmendiza[m]> yeah
15:04:15 <dmendiza[m]> #link https://meetpad.opendev.org/secure-rbac
15:04:23 <dmendiza[m]> started at 1430 UTC
15:04:49 <dmendiza[m]> Courtesy ping for https://meetpad.opendev.org/secure-rbac
15:04:52 <dmendiza[m]> oops
15:05:03 <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
15:05:04 <admiyo> A topic near and dear to my heart
15:05:50 <admiyo> would be better if I could hear in the secure RBAC meeting...
15:07:55 <dmendiza[m]> We can listenin in and postpone this until the policy meeting wraps up.
15:09:05 <admiyo> I can't hear anything there.
15:09:42 <dmendiza[m]> admiyo: Firefox?
15:10:17 <knikolla> i don't think there has been one time using meetpad/jitsi that everyone could hear everyone
15:12:52 <dmendiza[m]> Yeah, I've had issues with Firefox and Jitsi quite a bit
15:15:41 <alistarle> Hi, is there any Keystone meeting currently in progress ?
15:15:51 <admiyo> derailed atm
15:16:56 <dmendiza[m]> yeah, we're listening in on the Policy meeting in Meetpad
15:17:02 <dmendiza[m]> We'll resume the keystone meeting shortly
15:21:01 <dmendiza[m]> OK, resuming
15:21:01 <admiyo> All done there
15:21:07 <dmendiza[m]> #topic Review Past Meeting Action Items
15:21:23 <dmendiza[m]> > dmendiza[m] to look into updating the keystone-stable-maint group
15:21:31 <dmendiza[m]> I did not do this yet, but I will do it this week for sure
15:21:48 <dmendiza[m]> I'll remove anyone who has not reviewed anything in the last 90 days.
15:21:53 <dmendiza[m]> Then notify the ML
15:22:13 <dmendiza[m]> oh oops
15:22:26 <dmendiza[m]> I meant that for this:
15:22:27 <dmendiza[m]> > dmendiza[m] to clean up core reviewers group, notify ML
15:22:29 <dmendiza[m]> but I also am not on the maintenance team yet
15:22:32 <dmendiza[m]> so I need to sort that hout
15:22:37 <dmendiza[m]> *that out
15:22:57 <dmendiza[m]> > dmendiza[m] to set up a doodle poll to review OAuth 2.0 patches
15:23:05 <dmendiza[m]> and lastly, h_asahina helped out with this
15:23:15 <admiyo> so...I have not, and it is because the only things I've been notified about are already broken.  Is there really so little activity these days?
15:23:31 <knikolla> pretty much
15:23:44 <dmendiza[m]> Yeah, pretty low activity so far
15:23:45 <admiyo> ok
15:23:54 <dmendiza[m]> We definitely need help with bugsquashing though
15:24:04 <admiyo> I mean, I'm not a core reviewer anymore, so no risk to me
15:25:02 <dmendiza[m]> We definitely want your input on reviews
15:25:08 <admiyo> would help if you could build keystone...but we'll get to that in the agenda
15:26:26 <dmendiza[m]> #link https://doodle.com/meeting/participate/id/b68Yl49e/vote
15:26:41 <dmendiza[m]> ^^^ this is the doodle that h_asahina set up for us
15:26:55 <dmendiza[m]> looking like Thursday might be the best day for me
15:27:18 <dmendiza[m]> knikolla you probably haven't had a chance to find it in your email
15:27:36 <dmendiza[m]> but it would be good if we could get together on Thursday... if not we may need to kick to next week
15:28:31 <h-asahina> Yes. If you all not are not avalable this week, I'll create the doodle pool again.
15:28:39 <knikolla> filled out the doodle, thanks!
15:28:52 <dmendiza[m]> admiyo: how's your OAuth chops?
15:28:56 <h-asahina> thanks! knikolla:
15:28:57 <admiyo> Not bad
15:29:16 <admiyo> Are we looking to replace Keystone tokens with OAuth2?
15:29:32 <knikolla> we sort of already have, keystone supports jwt tokens
15:29:41 <knikolla> but not the oauth 2.0 api to emit and validate them
15:29:44 <admiyo> So we can get reid of keystone altogether
15:30:09 <admiyo> :)
15:30:15 <dmendiza[m]> Doodle is for reviewing https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext
15:30:26 <knikolla> get rid of keystone???? i want it to be the center of the world and support all oauth 2.0 and openid connect clients, mwhahahaha
15:30:39 <admiyo> keystonemiddleware suports jwt?
15:31:23 <knikolla> https://specs.openstack.org/openstack/keystone-specs/specs/keystone/stein/json-web-tokens.html
15:33:16 <admiyo> If keystonemiddleware can handle JWT, can we have it talk to a source otherthan keystone?
15:33:49 <admiyo> I realize there is all the service catalog implied in the token validation call, ignore that for a moment
15:34:16 <admiyo> if a company already has oauth2.0 set up, could they use that to validate when talking to openstack services?
15:34:44 <knikolla> the latter, the nfv clients depend on oauth 2.0
15:35:01 <knikolla> so we're enabling that, and allowing oauth 2.0 clients to talk to openstack services.
15:36:10 <knikolla> getting openstack services to use a different authorization servers is a very far stretch goal that isn't an immediate priority.
15:37:10 <dmendiza[m]> OK, I've responded to the doodle as well
15:38:09 <dmendiza[m]> OK, let's keep it moving since we're on a crunch today
15:38:16 <h-asahina> thanks, dmendiza: looks Thu 9:00 am would be better.
15:38:16 <dmendiza[m]> #topic Security RBAC
15:38:24 <admiyo> I am trying to understand what the actual priority is here; I assume  keystonemiddleware based servers still need to call to Keystone for JWT validation
15:39:20 <h-asahina> BTW, we submitted BP for keystonemidleware to communicate with an external authorization server: https://blueprints.launchpad.net/keystone/+spec/enhance-oauth2-interoperability
15:39:24 <knikolla> admiyo: https://specs.openstack.org/openstack/keystone-specs/specs/keystone/yoga/oauth2-client-credentials-ext.html
15:39:43 <h-asahina> for admiyo:
15:39:47 <admiyo> Cool. I'll read up
15:40:14 <dmendiza[m]> Awesome ... hopefully you can join on Thursday admiyo
15:40:23 <dmendiza[m]> OK, moving on
15:40:38 <dmendiza[m]> For SRBAC we did just meet for the Policy Pop-up
15:40:44 <dmendiza[m]> looks like the next one will be next week
15:40:56 <dmendiza[m]> at 1400 UTC, so hopefully it won't bleed into our meeting again.
15:41:21 <dmendiza[m]> Hopefully we'll get to a decision re: Heat, but also about the "service" role
15:41:23 <admiyo> dmendiza[m], did my little speech there at the end make any sense?  I can try to summarize
15:41:38 <dmendiza[m]> Sure, go ahead
15:41:55 <admiyo> OK....lets assume for a second that we  have no clue about what goes on in our customer organizations
15:42:10 <dmendiza[m]> that's not hard
15:42:11 <admiyo> instead of trying to force roles on them, lets assume that, at a start, they already have something
15:42:24 <admiyo> what we need to do it to map workflows to roles
15:42:35 <admiyo> a workflow is a set of API calls
15:42:53 <admiyo> and, possible more granular than that, but lets not quibble just yet
15:43:08 <admiyo> so there is a 3 tier architecture:  role->workflow->resource
15:43:26 <admiyo> if you lock role->resource, you cannot let end users modify things properly
15:43:55 <admiyo> so, we take every API and give it its own role...(stick with me here)
15:43:57 <knikolla> https://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/capabilities-app-creds.html
15:44:26 <admiyo> and use the role assignement inference rules
15:44:33 <knikolla> we already support restricting access to a set of api calls for a client
15:44:45 <admiyo> yeah, but not of breaking the API apart
15:45:00 <admiyo> thats only for app creds, not for end users
15:46:01 <admiyo> can app creds be re-delegated?
15:46:09 <admiyo> and re-broken down into finer grained things?
15:46:13 <knikolla> no
15:46:26 <admiyo> ok, so that capaiblity should move up the stack
15:46:56 <admiyo> we had a spec long ago about unified delegation, uising the sdame mechnism for role assignm,ents, trusts, an app-creds
15:47:32 <admiyo> if each "access-rule" in app creds are treated like a role, we can build them up to workflows, etc
15:47:39 <admiyo> we have most of the pieces we need already
15:47:56 <admiyo> do app-creds have wildcards?
15:48:00 <admiyo> they do, right?
15:48:03 <knikolla> yeah
15:48:51 <admiyo> so an app cred is kinda the abstraction we need.  Trust do this, too, but app-creds gets down to the URL, which is really what we need
15:49:16 <admiyo> so...if we can unify the concept of access rule and role, we have a very flexible RBAC structure
15:49:55 <admiyo> so,  then we use inference rules (already implemented) to go admin->reader->{
15:49:55 <admiyo> "path": "/v2.0/metrics",
15:49:55 <admiyo> "method": "GET"
15:49:55 <admiyo> },
15:50:05 <admiyo> where -> means "implies"
15:50:34 <admiyo> the issue, of course, is that RBAC is enforced at the end service side.
15:51:14 <admiyo> So they check "role == admin"  as opposed to "token allows GET '/v2.0/metrics' "
15:51:50 <admiyo> knikolla, am I giving you PTSD flashbacks yet?  We presented on this together, right?
15:52:16 <admiyo> https://www.openstack.org/videos/summits/boston-2017/per-api-role-based-access-control
15:52:21 <dmendiza[m]> Running low on time, y'all (and I gotta run at the top of the hour)
15:52:32 <admiyo> OK, one last issue, not related
15:52:40 <admiyo> I tired to build and run Keystone last night
15:52:47 <admiyo> ERROR: could not install deps [.[bandit], -chttps://releases.openstack.org/constraints/upper/master, -r/opt/openstack/keystone/test-requirements.txt, .[ldap,memcache,mongodb]]; v = InvocationError("/opt/openstack/keystone/.tox/pep8/bin/python -m pip install '.[bandit]' -chttps://releases.openstack.org/constraints/upper/master -r/opt/openstack/keystone/test-requirements.txt '.[ldap,memcache,mongodb]'", 1)
15:53:02 <admiyo> brand new clone, Ubuntu 21 and Fedora 35.  Same issue
15:53:04 <dmendiza[m]> via tox or ?
15:53:15 <admiyo> that was tox pep8 run
15:53:32 <admiyo> same thing for tox -e py...
15:53:40 <knikolla> admiyo: yeah, i was looking for the spec
15:53:41 <dmendiza[m]> gotcha... I can look into it but probably not until Friday
15:54:00 <admiyo> I think it might be a upper constraint mechanism thing?
15:54:39 <admiyo> no bandit in https://releases.openstack.org/constraints/upper/master
15:55:17 <admiyo> Can anyone build/run?  This seems like breakage across the board
15:56:50 <dmendiza[m]> trying tox -e pep8
15:57:38 <dmendiza[m]> Well, deps installed for me, but I got an actual pep8 failure
15:58:02 <dmendiza[m]> looks like it might be a python 3.10 issue on my end
15:58:10 <dmendiza[m]> admiyo: maybe you're missing some bindeps?
15:59:48 <dmendiza[m]> All out of time for today....  I'll pin the rest of the topics for next week.
15:59:52 <dmendiza[m]> Thanks for joining, y'all.
15:59:55 <dmendiza[m]> #endmeeting