19:05:36 <lbragstad> #startmeeting keystone-office-hours
19:05:37 <openstack> Meeting started Tue Mar  6 19:05:36 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:05:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:05:40 <openstack> The meeting name has been set to 'keystone_office_hours'
19:07:20 <kmalloc> sorry for being a bit late for office hours/missing meeting
19:07:42 <hamzy> I took a stab http://paste.openstack.org/show/693357/ but seem to be missing something. How do you get it to actually try and load a driver and throw an exception if not found?
19:09:45 <lbragstad> kmalloc: no worries
19:09:51 <lbragstad> hamzy: i can take a look today
19:10:36 <hamzy> sure, I know you are busy... I was also trying to get other input as well
19:12:10 <hamzy> I know pretend running things in mock is challenging
19:16:27 <kmalloc> lbragstad: i was cleaning up tempered glass :( it's been hours of finding yet again more glass on the floor
19:16:44 <lbragstad> that doesn't sound fun
19:18:30 <kmalloc> nope, it has not been fun
20:09:32 <cmurphy> o/
20:10:20 <cmurphy> we're not going over roadmap stuff in this office hours?
20:27:33 <ayoung> cmurphy, https://review.openstack.org/#/c/396331/7/specs/keystone/rocky/trust-scope-extensions.rst  is almost exactly my RBAC in middleware spec
20:28:20 <knikolla> ayoung: yep, more or less.
20:28:31 <knikolla> but only for application credentials.
20:28:31 <cmurphy> ayoung: it has a lot of the same elements
20:28:58 <ayoung> I was trying to avoid "get a whitelist during token validation" but beyond that...it just adds the ability to lock it down to a specific instance of a templatized URL, which I totally dig
20:29:09 <cmurphy> awesome
20:29:35 <ayoung> cmurphy, so I think we can automate some of the "map from URL to policy" that was a sticking point
20:29:46 <ayoung> https://adam.younglogic.com/2018/03/inspecting-keystone-routes/
20:29:56 <ayoung> that means we can get a list of the URL routes:
20:30:08 <ayoung> a little more probing and I think I can generate a list like this:
20:30:42 <ayoung> GET /users/{user_id}  keystone.identity.controllers.Controller#get_user
20:31:17 <ayoung> to be able to figure out what function is called.  Then...maybe I can use some of the same techniques as the callgraph package to figure out what policy gets called
20:31:36 <knikolla> ayoung: would that work for services outside of keystone?
20:31:38 <ayoung> I tried pycallgraph but it got too much in it
20:31:43 <ayoung> knikolla, I think so?
20:32:05 <ayoung> knikolla, it would have to be adapted to each, of course, but once we get the mechanism down, I don't think it would be too bad
20:32:51 <cmurphy> ayoung: why is that mapping a requirement?
20:33:05 <cmurphy> this spec proposes a layer before even hitting policy
20:33:30 <ayoung> cmurphy, so was mine, and there was the argument that it was not sufficient
20:33:37 <ayoung> sometimes the policy is deep in the code.
20:33:59 <ayoung> for example,  we might want to have different policy for someone creating a project under a domain/top level than nested under another project
20:34:30 <knikolla> ayoung: the rbac-in-middleware proposed restricting an entire users access. this is just about whitelisting **just** an app cred to a specific operation. scope is broadly different.
20:34:45 <ayoung> so, yeah, I wanted to enforce RBAC in middleware, just like he is proposing
20:34:58 <ayoung> knikolla, heh...his is the degenerate case.
20:35:10 <ayoung> knikolla, and I don't want to do it just for app creds
20:35:25 <ayoung> get it down to 1 role per operation
20:35:44 <ayoung> make a Fernet token format that can have exactly one role specified in it
20:35:57 <ayoung> and make it possible to request tokens with a subset of a users roles
20:36:15 <ayoung> so, yeah, we can build a whole new mechanism, or we can build on top of what we have
20:36:25 <lbragstad> cmurphy:  i think hrybacki was planning on doing that next week during office hours
20:36:52 <ayoung> knikolla, you aslo need to know "what role do I need to perform this operation" in the first place
20:37:07 <ayoung> otherwise, the app-cred thing is going to break if the roles are ever updated
20:37:27 <cmurphy> ayoung: we don't want to deal with roles at all here
20:37:27 <ayoung> we would have built a parallel strucutre and locked us in to the current role scheme
20:37:38 <cmurphy> we don't want to solve the "what role do i need" question yet
20:37:52 <cmurphy> it's just a simple front end layer in front of the current rbac implementation
20:37:56 <ayoung> cmurphy, Heh
20:37:58 <ayoung> just?
20:38:09 <cmurphy> heh
20:38:53 <ayoung> So, yeah, we are going to screw with RBAC no matter what, either implicitly or explicitly
20:39:09 <ayoung> I'd rather have a single access control mechanism than two
20:39:32 <cmurphy> I disagree in the short term
20:39:44 <ayoung> cmurphy, there is no short term in keystone
20:39:58 <ayoung> I worked on this longer than my wife was in Grad school
20:41:21 <ayoung> cmurphy, OK,  here's an example where things will break
20:42:32 <ayoung> say I want to delegate to another user the ability to create a server, but, unknown to me, nova makes a Cinder call to mount the volume.  If I only delegate Nova /server/create  it will fail, and I won't know when it fails.
20:43:00 <ayoung> how do we determine: this is what you need to have in order to perform this operation
20:43:19 <ayoung> people will not be able to build fine grained delegations like these without a catalog of that
20:43:39 <ayoung> so, the thing that I am doing to pull out the policy?  It should also be able to pull out calls to other services
20:44:01 <ayoung> lets generate that graph, and work from that information
20:45:02 <ayoung> Please don't disregard all of the effort, time, and discussion that went in to the previous design because this one looks simpler at the surface.  There are rocks under the waves.
20:45:45 <ayoung> We are also leaving security holes open if we do not address the RBAC approach properly.
20:46:16 <cmurphy> ayoung: what if we could build on the service token support to delegate those implicit calls like mount volume?
20:46:43 <ayoung> cmurphy, that is still based on the original user having that permission
20:46:57 <cmurphy> ayoung: they do have that permission because they have a role that allows it
20:47:01 <ayoung> the ervice token just adds to it the constraint that it can only be done in conjunction with the service token
20:47:16 <ayoung> so either it is "all users can do this"  or "none"
20:48:21 <ayoung> somestimes you have to create the volume explicitly first, and do that by downloading an image from Glance.  Lots of use cases.  We don't want to hard code the access for them
20:48:54 <cmurphy> if the specific use case is an application that must create volumes and download glance images explicitly then the user would build that into their whitelist
20:49:38 <knikolla> i think using service tokens takes us to dangerous territory. what if we don't want that app cred to create volumes, but they can do so by creating a server and then shutting it down?
20:49:44 <cmurphy> if it's relying on nova implicitly doing things for them then i think we could finagle the service token to proxy the request for them when they already have a traditional role that allows them to do that
20:49:49 <ayoung> So...if we are willing to entertain the extensions he's proposing, we should be wiling to entertain the RBAC in middleware.  It is the more general solution, and can be extended to cover his use cases by providing "fill in the template with these values"
20:50:15 <ayoung> and it allows a user with Admin to not provide full admin when making an interactive call to a third party service
20:50:22 <ayoung> and supports trusts and oauth
20:51:21 <ayoung> and allows an admin to set up the delegations, not just the end user
20:51:34 <ayoung> win -win all around
20:54:51 <cmurphy> what i like about this approach is 1) it's not an overhaul of how things already work, we can work on converging them incrementally 2) the policy mapping isn't stored in keystone, it's all contained in the application credential (or trust)
20:55:33 <ayoung> the application credential is stored in keystone
20:55:47 <ayoung> you still need that knowledge somehow
20:56:16 <cmurphy> when you get a token with the application_credential method it could contain the whitelist
21:02:44 <cmurphy> ayoung: we also don't have a way right now for users to create their own roles, so we would need every possible role created out of the box in order for this to be self-service, and we don't even have a read-only role out of the box
21:04:13 <ayoung> cmurphy, which is a far more pressing request
21:04:20 <ayoung> we've had a request for a read only role for years
21:04:55 <cmurphy> ayoung: it's on the roadmap for this cycle too https://etherpad.openstack.org/p/rocky-PTG-keystone-policy-roadmap
21:05:18 <ayoung> essentially, you are saying that the existing stuff is so broken that you don't want to fix it, and instead bolt something on over the top.  I don't fault you for that attitude, as it is a painful path to fix.
21:05:41 <cmurphy> ayoung: i'm not saying i don't want to fix it, i'm saying we can take incremental realistic steps toward fixing it
21:05:56 <cmurphy> we can't overhaul it
21:06:13 <ayoung> cmurphy, and I am saying that if you pursue this approach without fixing the underlying RBAC you will paint yourself into a corner
21:06:37 <ayoung> yes, you can do it, but then you won;t be able to change roles, because this mechanism will assume the current role structure
21:06:48 <ayoung> lets focus on fixing RBAC, and then do this on top of that,
21:11:57 <cmurphy> "this mechanism will assume the current role structure" all of openstack assumes the current role structure, the only way we can change it is by doing it incrementally
21:13:14 <ayoung> cmurphy, and that is what I have spent years laying out
21:13:33 <ayoung> yeaahs as they say here in Boston
21:13:47 <ayoung> lets fix policy.
21:13:51 <ayoung> lets fix RBAC
21:14:06 <ayoung> no new mechanisms that work around the brokenness
21:14:58 <ayoung> GAh...callgraph needs full code...
21:18:32 <ayoung> cmurphy, so I origianlly had RBAC in middleware fetching the URLs during token validation phase.
21:19:01 <ayoung> either the data was too big
21:20:09 <ayoung> you coulod easily do a hash value in to token that, if it does not exist, fetch the data you need from Keystone.  It would be the equivalent to what he's doing there.
21:20:23 <ayoung> and store the rbac rules by the hash
21:20:31 <ayoung> in Memcache
21:21:14 <ayoung> so, reconcile the two and you'll have my full support.  Ignore me and work around me and I'll just be sad and grumpy
21:23:34 <cmurphy> ayoung: i think the data won't be too big because we're not fetching the whole mapping for all the policies, we're just fetching a short whitelist and we could even limit the list size
21:23:57 <ayoung> cmurphy and then your are limiting it to your use cases
21:28:36 <cmurphy> ayoung: i can't argue that, but i believe we can build something that solves the end-user case and works now and work in parallel on fixing rbac, i'm not convinced they're in conflict
21:44:06 <lbragstad> hamzy: i think you're missing a callable in http://paste.openstack.org/show/693357/
21:47:03 <lbragstad> hamzy: http://paste.openstack.org/show/693465/ works for me but it could be generalized instead of being a token test
21:47:12 <lbragstad> (since it doesn't really have anything to do with tokens anymore)
22:00:14 <lbragstad> #endmeeting