16:00:02 <lbragstad> #startmeeting keystone
16:00:03 <openstack> Meeting started Tue Apr 10 16:00:02 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:06 <openstack> The meeting name has been set to 'keystone'
16:00:07 <lbragstad> ping ayoung, breton, cmurphy, dstanek, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rderose, rodrigods, samueldmq, spilla, aselius, dpar, jdennis, ruan_he, wxy, sonuk
16:00:16 <gagehugo> o/
16:00:18 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
16:00:20 <lbragstad> o/
16:00:23 <lbragstad> agenda ^
16:00:24 <hrybacki> o/
16:00:25 <ayoung> Hey Ho.  Lets go.
16:00:28 <wxy|> o/
16:00:54 <lbragstad> give folks another minute or two to show up
16:00:58 <kmalloc> o/
16:01:01 <kmalloc> i'm here...
16:01:18 <sonuk> o/
16:01:29 <lbragstad> sonuk: welcome
16:01:39 <jgrassler> o/
16:01:44 <sonuk> lbragstad: thanks
16:01:57 <lbragstad> #topic specifications
16:02:35 <lbragstad> things are moving and we had some good iterations over the last week
16:02:58 <lbragstad> i'll likely keep specs as an item on the meeting agenda until we get things where we want them
16:03:10 <lbragstad> #info specification proposal freeze is going to be next week
16:03:26 <lbragstad> just a reminder in case there is anything we're missing for Rocky
16:03:32 <lbragstad> #topic Application Credentials
16:03:39 <lbragstad> #link https://review.openstack.org/#/c/396331/
16:04:06 <lbragstad> i've reviewed this a few times and my comments are getting really nit picky :)
16:04:15 <lbragstad> i think this is looking good
16:04:20 <jgrassler> I take that as a good sign :-)
16:04:25 <lbragstad> jgrassler: yep!
16:04:41 <lbragstad> i'd like to have a few other reviews give it a once over though
16:04:50 <lbragstad> just to make sure we're not missing anything before we merge it
16:05:41 <kmalloc> lbragstad: +2/+A'd that spec
16:05:49 <kmalloc> lbragstad: just reviewed it again
16:05:56 <kmalloc> if you want me to rescind my +A i will
16:05:57 <lbragstad> fastest review ever
16:05:59 <kmalloc> but it looks ready
16:06:10 <kmalloc> he had to change 1 thing from the last round for me to +2.
16:06:12 <kmalloc> it was ready.
16:06:16 <jgrassler> kmalloc: thanks :-)
16:06:24 <lbragstad> cool
16:06:26 <lbragstad> looks good to me
16:06:38 <lbragstad> if anyone sees anything in that spec, please say something
16:06:40 <lbragstad> or leave a comment
16:06:49 <kmalloc> or propose a followup
16:06:50 <lbragstad> we can address things in a follow up if needed
16:07:17 <ayoung> Yeah...App Creds looks good
16:07:44 <lbragstad> #topic default roles
16:07:48 <lbragstad> hrybacki: around?
16:07:51 <hrybacki> o/ Alright so, after discussions w/ Adam yesterday I'm in support of using implied roles for default roles. I had a basic misunderstanding how he envisioned them being used. Since all of the work will be on our end*, and it clears up the policy files I think it's the best move.
16:08:00 <ayoung> We really should get a lighter process, where we approve the spec in a general sense, and then start ones and twos on it.
16:08:24 <kmalloc> ayoung: that was at the PTG
16:08:26 <hrybacki> all-in-all I think the spec is shaping up nicely though. Lots of feedback coming in
16:08:40 <kmalloc> ayoung: "this is something we want, we like it, now iterate on it and get it ready to merge"
16:09:03 <ayoung> to be clear, I really only see three roles, with 2 an inference rules between them
16:09:20 <ayoung> admin -> member  and member -> reader
16:09:24 <lbragstad> admin -> member -> auditor right?
16:09:28 <hrybacki> ^^ +2
16:09:29 <ayoung> right
16:09:30 <ayoung> auditor
16:09:39 <ayoung> and then the policy files get simpler, you remove the ORs
16:09:48 <ayoung> it also gives you a tool to further refine things down the line:
16:09:49 <kmalloc> ah and fill in the policy behind the scenes
16:09:52 <hrybacki> a good point
16:09:55 <kmalloc> thats pretty solid
16:09:57 <hrybacki> kmalloc: aye.
16:10:05 <lbragstad> hrybacki: are you working that into the next revision?
16:10:19 <hrybacki> lbragstad: I am -- but wanted to discuss here before posting
16:10:24 <lbragstad> ack
16:10:26 <ayoung> want to break member up into smaller pieces? Start with a new role, then a new inference rule, and finally a new policy, and you've not broken anything
16:10:41 <hrybacki> +1
16:10:45 <kmalloc> ayoung: that is quite reasonable
16:10:45 <lbragstad> we're going to need to be ready to explain the concepts to other services
16:10:49 <ayoung> thanks
16:11:02 <kmalloc> lbragstad: i think this makes it easier
16:11:14 <lbragstad> right - but we're also a bunch of keystone developers :)
16:11:18 <hrybacki> and implied roles are the way we are asking deployments to handle edge cases
16:11:27 <ayoung> and the same mechanism that sets up the default roles sets up the rules.
16:12:17 <lbragstad> i can just see developers from other services having questions about what this exactly means for them
16:12:19 <ayoung> keystone-manage I assume
16:12:25 <lbragstad> and we'll need to be prepared to field those
16:12:36 <lbragstad> so that we can keep things moving
16:12:39 <ayoung> lbragstad, that is why we get it in the spec first:  the example policy should spell it out
16:13:33 <hrybacki> WRT domain scope -- I do not think we should integrate it into the spec. I understand that user/groups tie directly to the concept and are a sticky point but cmurphy made some very good points about it not being a 'real' scope and that we should err on the side of not misleading consumers
16:13:52 <ayoung> BTW, I see what y'all were saying about Domain level roles.  My last comment suggests dropping the user example, and just adding a note "leave these alone"
16:14:02 <lbragstad> yeah... i'm fine with that assessment
16:14:05 <ayoung> "they are Keystone only"
16:14:07 <hrybacki> ayoung: yeah, that's just a leftover I missed
16:14:12 <lbragstad> honestly, we have a good seam to work on that later
16:14:24 <ayoung> for a service level operation, suggest hypervisor management
16:14:45 <lbragstad> if we get the whole "project" scope and "system" scope work done, we can come through later and do all the domain stuff as it's own specification
16:14:52 <ayoung> https://developer.openstack.org/api-ref/compute/#hypervisors-os-hypervisors
16:15:20 <hrybacki> #link https://developer.openstack.org/api-ref/compute/#hypervisors-os-hypervisors
16:16:13 <lbragstad> we might need to clarify the intent that domain scope will be tackled later in the specification
16:16:23 <ayoung> #link http://git.openstack.org/cgit/openstack/nova/tree/nova/policies/hypervisors.py?h=stable/queens#n37
16:16:28 <hrybacki> lbragstad: I can add a 'future work' section
16:16:39 <ayoung> lbragstad, Domain scope would be in a Keystone specific spec, so we should be OK
16:16:49 <lbragstad> not necessarily
16:17:05 <lbragstad> i can see a case where using a domain-scoped token for other services would be useful
16:17:19 <ayoung> lbragstad, so can I, but they don't have the data stored to work on it
16:17:19 <lbragstad> e.g. using a domain scoped token to perform a GET /servers call
16:17:30 <hrybacki> yeah it's tricky. Users/groups should not necessarily be controlled by anyone with system scope (ideally)
16:17:51 <ayoung> yeah, but they don't have the tree today.  So, while it might be someday in the future, it would require a good be of reengineering to get there
16:18:19 <lbragstad> sure - that's a good candidate for future work
16:18:32 <lbragstad> but i wouldn't say domain-scope is "keystone" specific
16:18:40 <lbragstad> because then it seems like it's only something that we will use
16:19:50 <ayoung> Sounds good.  I think we see things from the same perspective
16:20:09 <hrybacki> ++
16:20:23 <lbragstad> i just don't want another service developer to automatically file "domain-scope" as something they don't have to ever think about
16:20:39 <lbragstad> but instead as something like "oh, yeah... we'll cross that bridge in the future"
16:21:39 <lbragstad> anything else we  want to talk about for default roles?
16:21:50 * hrybacki shakes his head
16:21:59 <hrybacki> thanks all for the great feedback (and persistence!)
16:22:10 <lbragstad> thanks for keeping things updated
16:22:13 <lbragstad> #topic jwt
16:22:19 <lbragstad> #link https://review.openstack.org/#/c/541903/
16:22:25 <lbragstad> this still needs feedback
16:22:29 <lbragstad> and reviews
16:23:04 <lbragstad> i'll be available during office hours if people want to ask specific questions about it
16:23:28 <lbragstad> #topic hierarchical limits
16:23:37 <lbragstad> #link https://review.openstack.org/#/c/540803/
16:23:44 <lbragstad> #link https://review.openstack.org/#/c/549766/
16:23:48 <lbragstad> ^ those are in the same boat
16:24:03 <lbragstad> we need reviews on them - especially from a usability perspective
16:24:20 <ayoung> looking at all three of thoes reviews
16:24:27 <lbragstad> thanks ayoung
16:24:34 <ayoung> lbragstad, on JWT
16:24:40 <ayoung> do we have a size limit>
16:25:01 <ayoung> that was what made PKI painful, and are we sure we will be OK with JWT sizes?
16:25:02 <lbragstad> we plan to
16:25:17 <lbragstad> it will be similar to fernet size-wise
16:25:20 <lbragstad> but not as compat
16:25:23 <lbragstad> compact*
16:25:28 <ayoung> I'm actually OK if we don't
16:25:48 <ayoung> really, the limit is 8k which should be attainable
16:26:05 <ayoung> that is the size of the header between Apache and mod_wsgi, and where things break down
16:26:17 <ayoung> other than that, and so long as it is optional, I like the alternative
16:26:23 <ayoung> would JWT allow for PKI signing?
16:26:24 <lbragstad> right - but i would be opposed to including unbound things in the token
16:26:41 <lbragstad> because it opens that door up
16:26:53 <lbragstad> JWT has two different paths we can exercise
16:27:09 <lbragstad> JWS and JWE, which is signing and encryption respectively
16:27:30 <lbragstad> JWE is very similar to our fernet implementation
16:27:40 <lbragstad> JWS is kinda similar to what we had with PKI
16:28:19 <ayoung> Sounds good.  This review is just "move the spec to the next release" right?
16:28:32 <lbragstad> yeah - but we need to figure out some details
16:28:49 <ayoung> Can we approve the move, and do the details in a follow on spec?
16:28:50 <lbragstad> and we have to update them before we can merge it... since we did some investigation and found a few things that need to be looked at
16:28:54 <ayoung> or, follow on review
16:28:58 <ayoung> makes it easier to track
16:29:06 <lbragstad> probably not, they are significant to the actual design
16:29:25 <lbragstad> we'll have to talk about them at some point
16:30:17 <lbragstad> i attempted to highlight the main things i found in the reproposed version
16:30:33 <ayoung> Agreed.  hrybacki our team supports JOSE, right?
16:30:52 <lbragstad> i think nkinder was saying something like that
16:31:03 <lbragstad> or saying there was a connection there?
16:31:07 <hrybacki> JOSE?
16:31:11 * gagehugo needs to step away but will be back in a bit
16:31:11 <lbragstad> py-jose
16:31:37 <hrybacki> that doesn't ring a bell with me (but that doesn't mean we don't support it)
16:31:53 <lbragstad> #link https://pypi.python.org/pypi/python-jose/2.0.2
16:32:14 <ayoung> So...summary: we have 3 libraries we can use that do JWT only.
16:32:19 <lbragstad> its one of the three libraries we would use to implement JWS
16:32:27 <ayoung> Pretty sure simo championed it a few years back
16:32:42 <hrybacki> now this rings a bell. Yes, someone at RH is supporting one of those libraries (but I can't recall which)
16:33:08 <lbragstad> we won't be able to use JWCrypto because of licensing
16:33:21 * hrybacki is asking internally
16:33:25 <lbragstad> and that's the only one that supports JWE
16:33:44 <lbragstad> PyJWT and python-jose support JWS to date
16:33:58 <ayoung> lbragstad, so...suggest we start by driving on with JWT only, and we can look into JWE second.  IIUC, it is really JWT that has taken off, and it gives us new functionality
16:34:13 <ayoung> JWE sounds like a longer term effort, but would be a good 1-to-1 replacement for Fernet
16:34:26 <ayoung> so...split the spec, and do JWT this round?
16:34:42 <lbragstad> well - JWE and JWS are subsets of the JWT specification if i understand it correctly
16:34:46 <ayoung> And see if we can get an intern to build JWE into JOSE?
16:35:51 <lbragstad> if we want to do JWS, we can rework the specification to include that
16:36:05 <lbragstad> and retarget JWE when we actually have an implememtation that supports it
16:36:14 <lbragstad> implementation*
16:36:49 <ayoung> I think JWT is built on JWS.  I suspect the issue is symmetric versus asym, with JWT being built on Asym
16:36:56 <ayoung> lbragstad, ++
16:37:01 <ayoung> anyone have a counterpoint?
16:37:09 <lbragstad> either way - reviews on the spec will be needed
16:37:39 <lbragstad> i linked to a few security concerns with JWT in the specification, too
16:39:01 <ayoung> OK, I have the context I need
16:39:04 <lbragstad> if anyone wants to talk jwt after the meeting, let me know
16:39:06 <lbragstad> i'll be in -keystone
16:39:26 <lbragstad> happy to answer questions and get into the details
16:39:42 <lbragstad> #topic unique domain ids for identity providers
16:39:54 <ayoung> lbragstad, so on https://review.openstack.org/#/c/549766/  that is tagged WIP.  How aggressive are we in pursuing that
16:40:05 <ayoung> heh...you move too fast
16:40:12 <lbragstad> #undo
16:40:13 <openstack> Removing item from minutes: #topic unique domain ids for identity providers
16:40:15 <ayoung> :)
16:40:19 <lbragstad> backing up
16:40:21 <lbragstad> sorry
16:40:25 <lbragstad> #topic hierarchical limits
16:40:32 <lbragstad> we need reviews on it, that's for sure
16:40:39 <lbragstad> wxy|: has a specification up to
16:40:40 <ayoung> is it "either or" between those specs?
16:40:51 <wxy|> I'd like to pick it up if John has no time.
16:41:02 <lbragstad> people from cern are interested in it
16:41:15 <ayoung> so...two level is interesting
16:41:19 <lbragstad> they're really the only people who have said "this is how we expect limits to work in a hierarchical settign"
16:41:37 <ayoung> and...I think I can say that it smells right
16:41:50 <wxy|> John's is focus on the first model we'll support. Mine is focus on the whole enforce flow.
16:42:09 <lbragstad> yeah ^ that's an important distinction
16:42:37 <lbragstad> because what wxy| has in his specification includes work that needs to be done regardless of the enforcement model
16:43:23 <ayoung> so...it feels like 2 specs
16:43:43 <ayoung> one which is ``include_all_children=True``  and one is the "2 level hierarchy"
16:44:30 <ayoung> but...they don't really say why a 2 levle limit is essential,  do they?
16:45:00 <lbragstad> because the problem gets substantially harder with more than two levels
16:45:27 <ayoung> I get that...from years of discussion
16:45:41 <ayoung> but on the Nova side. a project still doesn't know its parent
16:45:43 <lbragstad> and the problem we discovered during the PTG was that we lack opinions on how things should behave with more than 2 levels
16:45:49 <ayoung> all a project is is a uuid on a vm
16:45:56 <lbragstad> right
16:47:17 <ayoung> ok...so I think if we are going to enforce 2 level project hierarchies, it has to be inside the resource backend, not limits
16:47:27 <ayoung> otherwise,  what happens if you have:
16:47:35 <ayoung> A->B->C
16:47:52 <ayoung> they can still create C as a child of B, but the quota for it is not based on B
16:48:14 <ayoung> I can see saying "ok, all preexsing get grandfathered in"
16:48:26 <ayoung> but how do you keep people from making deep trees in the future?
16:48:43 <lbragstad> that's where enforcement models come it
16:48:51 <lbragstad> come in*
16:48:53 <ayoung> would it make sense to tag an "allowed depth" field on the project record in the backend?
16:49:41 <lbragstad> we already have a configuration options for that
16:49:44 <lbragstad> i think
16:49:58 <lbragstad> some sort of max project level
16:50:02 <ayoung> if we do, the spec should reference how to use them in conjunction
16:50:36 <ayoung> wxy|, can you look in to that?
16:50:43 <wxy|> sure
16:50:49 <ayoung> ++
16:50:52 <lbragstad> well - i think we need to review his spec too :)
16:50:54 <ayoung> I'm good.
16:51:00 <ayoung> lbragstad, of course
16:51:28 <lbragstad> sounds like we have some actions to chase there
16:51:35 <lbragstad> any other questions on limits?
16:52:28 <lbragstad> #topic domains and identity provider uniqueness
16:52:40 <lbragstad> a while back we made it so that identity providers needed to have a domain
16:52:59 <lbragstad> that was part of the shadow user work
16:53:02 <lbragstad> #link https://review.openstack.org/#/c/559676/1
16:53:14 <lbragstad> wxy|: has a patch up to clarify that relationship
16:53:37 <lbragstad> do we have an opinion on that?
16:53:46 <lbragstad> do we want to have a hard constraint there?
16:53:49 <ayoung> so we are saying that an IdP has exactly one domain?
16:54:00 <lbragstad> ayoung: i think that's the question we need to answer
16:54:06 <ayoung> I wanted that years ago
16:54:19 <ayoung> I lost
16:54:31 <ayoung> OK...what is this going to break:
16:54:31 <lbragstad> i rememebr someone at the boston forum asking for the ability to associate multiple domains to a single identity provider
16:54:49 <ayoung> right now, we use Keycloak as a way to add additional providers
16:55:03 <ayoung> kinda like how CERN used ADFS
16:55:39 <ayoung> instad of changing the config on the Keystone server, we add additional providers at the WebSSO level.
16:55:52 <ayoung> My gut says that this patch is right, just trying to rationalize it
16:56:16 <ayoung> so...we configure Apapche once, and say that /OS-FEDERATION  is protected by WebSSO...
16:56:29 <ayoung> gah, that means that you cannot have any other provider....grrr
16:56:36 <lbragstad> right
16:56:44 <lbragstad> a provider would have a single domain
16:56:45 <ayoung> its backwards...if you wanted to do SAML AND KERBEROS
16:57:10 <ayoung> now, for a single IdP, we would want to map multiple protocols to the same Domain.
16:57:34 <lbragstad> three minute warning
16:57:37 <ayoung> But...from an Apache perspective, we could not have multiple protocols, which would be suboptimal.
16:57:48 <ayoung> OK, I'll chime in on that patch.  I think it does not affect anything
16:57:55 <lbragstad> thanks ayoung
16:58:10 <lbragstad> i didn't want to cut you off but gagehugo has some exciting new
16:58:12 <lbragstad> news8
16:58:14 <lbragstad> bah
16:58:20 <lbragstad> n-e-w-s-*
16:58:23 <lbragstad> nailed it
16:58:33 <lbragstad> #topic keystonemiddleware is now under VMT
16:58:35 <lbragstad> gagehugo: o/
16:58:43 <ayoung> Vermont?
16:58:49 <gagehugo> o/ i forgot i had irc on my phone
16:59:02 <gagehugo> ayoung tes
16:59:08 <gagehugo> Yes
16:59:29 <lbragstad> this has been over a year in the makig
16:59:31 <lbragstad> making*
16:59:38 <lbragstad> thanks gagehugo for pushing on this
16:59:51 <gagehugo> Np, it was an interesting experience
17:00:00 <lbragstad> #link https://review.openstack.org/#/c/555934/
17:00:05 <lbragstad> and with that
17:00:07 <lbragstad> we're out of time
17:00:10 <lbragstad> thanks for coming folks!
17:00:12 <lbragstad> #endmeeting