19:05:36 #startmeeting keystone-office-hours 19:05:37 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:05:40 The meeting name has been set to 'keystone_office_hours' 19:07:20 sorry for being a bit late for office hours/missing meeting 19:07:42 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 kmalloc: no worries 19:09:51 hamzy: i can take a look today 19:10:36 sure, I know you are busy... I was also trying to get other input as well 19:12:10 I know pretend running things in mock is challenging 19:16:27 lbragstad: i was cleaning up tempered glass :( it's been hours of finding yet again more glass on the floor 19:16:44 that doesn't sound fun 19:18:30 nope, it has not been fun 20:09:32 o/ 20:10:20 we're not going over roadmap stuff in this office hours? 20:27:33 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 ayoung: yep, more or less. 20:28:31 but only for application credentials. 20:28:31 ayoung: it has a lot of the same elements 20:28:58 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 awesome 20:29:35 cmurphy, so I think we can automate some of the "map from URL to policy" that was a sticking point 20:29:46 https://adam.younglogic.com/2018/03/inspecting-keystone-routes/ 20:29:56 that means we can get a list of the URL routes: 20:30:08 a little more probing and I think I can generate a list like this: 20:30:42 GET /users/{user_id} keystone.identity.controllers.Controller#get_user 20:31:17 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 ayoung: would that work for services outside of keystone? 20:31:38 I tried pycallgraph but it got too much in it 20:31:43 knikolla, I think so? 20:32:05 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 ayoung: why is that mapping a requirement? 20:33:05 this spec proposes a layer before even hitting policy 20:33:30 cmurphy, so was mine, and there was the argument that it was not sufficient 20:33:37 sometimes the policy is deep in the code. 20:33:59 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 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 so, yeah, I wanted to enforce RBAC in middleware, just like he is proposing 20:34:58 knikolla, heh...his is the degenerate case. 20:35:10 knikolla, and I don't want to do it just for app creds 20:35:25 get it down to 1 role per operation 20:35:44 make a Fernet token format that can have exactly one role specified in it 20:35:57 and make it possible to request tokens with a subset of a users roles 20:36:15 so, yeah, we can build a whole new mechanism, or we can build on top of what we have 20:36:25 cmurphy: i think hrybacki was planning on doing that next week during office hours 20:36:52 knikolla, you aslo need to know "what role do I need to perform this operation" in the first place 20:37:07 otherwise, the app-cred thing is going to break if the roles are ever updated 20:37:27 ayoung: we don't want to deal with roles at all here 20:37:27 we would have built a parallel strucutre and locked us in to the current role scheme 20:37:38 we don't want to solve the "what role do i need" question yet 20:37:52 it's just a simple front end layer in front of the current rbac implementation 20:37:56 cmurphy, Heh 20:37:58 just? 20:38:09 heh 20:38:53 So, yeah, we are going to screw with RBAC no matter what, either implicitly or explicitly 20:39:09 I'd rather have a single access control mechanism than two 20:39:32 I disagree in the short term 20:39:44 cmurphy, there is no short term in keystone 20:39:58 I worked on this longer than my wife was in Grad school 20:41:21 cmurphy, OK, here's an example where things will break 20:42:32 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 how do we determine: this is what you need to have in order to perform this operation 20:43:19 people will not be able to build fine grained delegations like these without a catalog of that 20:43:39 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 lets generate that graph, and work from that information 20:45:02 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 We are also leaving security holes open if we do not address the RBAC approach properly. 20:46:16 ayoung: what if we could build on the service token support to delegate those implicit calls like mount volume? 20:46:43 cmurphy, that is still based on the original user having that permission 20:46:57 ayoung: they do have that permission because they have a role that allows it 20:47:01 the ervice token just adds to it the constraint that it can only be done in conjunction with the service token 20:47:16 so either it is "all users can do this" or "none" 20:48:21 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 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 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 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 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 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 and supports trusts and oauth 20:51:21 and allows an admin to set up the delegations, not just the end user 20:51:34 win -win all around 20:54:51 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 the application credential is stored in keystone 20:55:47 you still need that knowledge somehow 20:56:16 when you get a token with the application_credential method it could contain the whitelist 21:02:44 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 cmurphy, which is a far more pressing request 21:04:20 we've had a request for a read only role for years 21:04:55 ayoung: it's on the roadmap for this cycle too https://etherpad.openstack.org/p/rocky-PTG-keystone-policy-roadmap 21:05:18 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 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 we can't overhaul it 21:06:13 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 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 lets focus on fixing RBAC, and then do this on top of that, 21:11:57 "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 cmurphy, and that is what I have spent years laying out 21:13:33 yeaahs as they say here in Boston 21:13:47 lets fix policy. 21:13:51 lets fix RBAC 21:14:06 no new mechanisms that work around the brokenness 21:14:58 GAh...callgraph needs full code... 21:18:32 cmurphy, so I origianlly had RBAC in middleware fetching the URLs during token validation phase. 21:19:01 either the data was too big 21:20:09 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 and store the rbac rules by the hash 21:20:31 in Memcache 21:21:14 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 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 cmurphy and then your are limiting it to your use cases 21:28:36 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 hamzy: i think you're missing a callable in http://paste.openstack.org/show/693357/ 21:47:03 hamzy: http://paste.openstack.org/show/693465/ works for me but it could be generalized instead of being a token test 21:47:12 (since it doesn't really have anything to do with tokens anymore) 22:00:14 #endmeeting