16:00:47 <lbragstad> #startmeeting policy
16:00:47 <openstack> Meeting started Wed Dec  7 16:00:47 2016 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:53 <openstack> The meeting name has been set to 'policy'
16:00:58 <dstanek> o/
16:00:59 <rderose> o/
16:01:03 <lbragstad> o/
16:01:03 <edmondsw> o/
16:01:06 <ayoung> Yehaw
16:01:24 <lamt> o/
16:01:26 <dolphm> \o
16:01:33 <ayoung> Agenda is here https://etherpad.openstack.org/p/keystone-policy-meeting
16:02:29 <mars> Is cinder team meeting has began?
16:02:38 <ayoung> mars, wrong room, this is policy
16:02:53 <lbragstad> mars looks like it has in #openstack-meeting
16:03:00 <mars> thx
16:03:10 <lbragstad> mars you're more than welcome to stay and help with policy though ;)
16:03:47 <lbragstad> alright - #link https://etherpad.openstack.org/p/keystone-policy-meeting
16:03:56 <lbragstad> even though ayoung dropped it earlier
16:04:16 <lbragstad> #topic action items from last week
16:04:26 <ayoung> do we have any Other proposals for policy at this point?
16:04:28 <mars> thx,but now i must to join in the cinder and ask some questions to my ptl
16:04:47 <lbragstad> we all had action items to review ayoung policy spec
16:05:05 <ayoung> Got that on the Agenda for this week lbragstad but put it at the end
16:05:32 <lbragstad> ayoung yep - i see that
16:05:46 <edmondsw> I like the "Role Check Check" title ;)
16:06:11 <lbragstad> #topic other proposals for policy
16:06:20 <ayoung> edmondsw, I felt that "Role Check Check Check" had better rhythm, but was just too much
16:06:41 <edmondsw> lol
16:06:47 <lbragstad> i wish ruan was here
16:06:59 <ayoung> I can start to address his question, though, on what it would take
16:07:22 <lbragstad> ayoung  are you referencing the external PEP and PDP bits?
16:07:26 <ayoung> yep
16:07:44 <lbragstad> sure - go for it. we can get his opinion if he joins
16:08:12 <ayoung> OK, so, lets start with the current state of how services call Oslo-policy
16:08:30 <ayoung> there is a project called oslo-context that essentially is the contract for the set of parameters that a service should use to call policy
16:08:46 <ayoung> in order to call a remote PDP, we need a contract like that
16:09:12 <ayoung> and the tricky part is "what attributes are we going to use to enforce policy"
16:09:38 <ayoung> The current approach mixes the oslo-context set (most Keystone token validation data in dictionary form) with some of the values from the service
16:09:51 <ayoung> looking at the policy rules that Neutron does can show you some of the complexity
16:10:10 <dstanek> do we have a single point of truth for the usecases we are tackling and the endstate we desire? stevemar asked for this in one of the email threads
16:10:25 <ayoung> I'd group it into 2 things, though, that the service needs to pass
16:10:31 <ayoung> dstanek, can you hold that question for a moment?
16:10:47 <lbragstad> dstanek i think that's a good starting point
16:10:55 <ayoung> 1.  is the scope of the resource: what project owns it, what user, and so forth
16:11:03 <ayoung> 2. is sharing criteria
16:11:24 <ayoung> and if you look at neutron, it is 'is this a public network'  which is also mirrored in glance
16:11:36 <ayoung> so, those are the use cases solved by policy today
16:12:07 <ayoung> I don;t think we have a usecase document yet for the External PDP.  If there is, I have not seen it
16:12:45 <ayoung> However, Access Control is not a new concept
16:12:47 <lbragstad> ayoung let's just talk usecases in general
16:12:48 <lbragstad> ayoung you example highlights at least one
16:13:03 <ayoung> and we should not need to invent them all from scratch.
16:13:25 <ayoung> So...let me define the central use case:
16:13:52 <lbragstad> #topic use cases for policy
16:14:01 <ayoung> "allow a set of users access to some operation on a resource based on the roles they are assigned for a project"
16:14:29 <ayoung> that is the use case that policy today almost supports
16:14:48 <ayoung> the neutron glance use case is more like:
16:15:22 <ayoung> "allow a set of users access to some operation on a resource based on attributes of the resource"
16:15:29 <lbragstad> true
16:15:31 <ayoung> which builds on top of the core use case
16:15:46 <ayoung> I would actually say the core use case as implemented by oslo policuy today is
16:16:15 <ayoung> "allow a set of users access to some operation on a resource based on whether they are assigned any role for a project"
16:16:26 <edmondsw> breaking that down into subcases, you have 1) simple cases where the decision is based purely on role and resource type, 2) cases where user attributes come into play, 3) cases where resource attributes come into play
16:16:30 <ayoung> and then the admin use case IS (but not what it should be)
16:16:39 <ayoung> "allow a set of users access to some operation on a resource based on whether they are assigned the admin role on any project"
16:16:46 <ayoung> and we are trying to change that to
16:16:55 <ayoung> "allow a set of users access to some operation on a resource based on whether they are assigned the admin role on the admin project project"
16:17:18 <ayoung> edmondsw, 1) also includes the resource scope
16:17:28 <ayoung> well...
16:17:43 <ayoung> OK  lets define the admin use case this way
16:17:54 <lbragstad> let's consider admin is just a role
16:18:00 <ayoung> "allow a set of users access to some operation on a resource based on whether they are considered a cloud administrator"
16:18:14 <lbragstad> to me - that should fall into the first use case
16:18:23 <edmondsw> the admin vs. everyone else distinction we have today is a factor of not having any default roles other than admin today... default policy can't refer to roles that don't exist
16:18:42 <ayoung> edmondsw, so...that gets into the second to last item I have on the agenda
16:18:46 <lbragstad> admin shouldn't be anything special - it's just a role that maps to a set of operations
16:19:01 <ayoung> https://bugs.launchpad.net/keystone/+bug/968696
16:19:01 <openstack> Launchpad bug 968696 in OpenStack Identity (keystone) ""admin"-ness not properly scoped" [High,In progress] - Assigned to Adam Young (ayoung)
16:19:11 <ayoung> lbragstad, not quite.  there are 2 types of admin-ness
16:19:21 <ayoung> 1 is do I have admin on this specific project
16:19:36 <ayoung> but the 0 level rule is
16:19:44 <edmondsw> lbragstad, I wish admin wasn't special. I would like to get there someday. We are a long way from that
16:20:00 <ayoung> this Operation is special.  I need admin on a special project (or projects..future work)
16:20:03 <lbragstad> edmondsw agreed
16:20:19 <ayoung> and, if I have admin on the special project, I can use that as an override for project scoped operations
16:20:20 <lbragstad> edmondsw but ideally admin should just be a role that maps to a set of operations - right?
16:20:33 <ayoung> lbragstad, it is also and override
16:20:52 <dstanek> for my own sanity i'm starting to record this here: https://etherpad.openstack.org/p/keystone-policy-usecases
16:20:57 <ayoung> admin role on the admin project is a global admin, capable of fixing things for many other users
16:21:02 <ayoung> dstanek, thanks
16:21:13 <lbragstad> dstanek i started writing some down in the meeting but i'll port them to your etherpad
16:21:53 <edmondsw> lbragstad I think so... the issue may be with code needing to treat admins as special in ways that you don't want to be controllable via policy, leading to the continuation of the context_is_admin rules
16:21:57 * dstanek really just wants to have as many of the usecase as possible first and then have a summary of end states for each solution second before he can accurately judge review proposals
16:22:10 <ayoung> I want to use the term Member as opposed to user, if that is OK
16:22:23 <lbragstad> dstanek ++
16:22:29 <edmondsw> dstanek ++
16:22:45 <ayoung> We did have jamielennox and dolphm 's attempt to set a basic set of roels that does address this
16:22:51 <ayoung> let me find it
16:23:01 <lbragstad> edmondsw right - i assume there are going to be usecases that don't quite match with the way things are currently - but that's fine, i'd like us to start from a ideal point
16:23:15 <edmondsw> lbragstad ++
16:23:36 <lbragstad> if we were to start *all* over, how would this look?
16:24:08 <thinrichs> If it helps, Congress has a list of policy use cases.  Not all of them would necessarily be enforced at the API, but some of them are pretty concrete...
16:24:09 <thinrichs> https://docs.google.com/document/d/1ExDmT06vDZjzOPePYBqojMRfXodvsk0R8nRkX-zrkSw/edit#heading=h.wvybnha031eu
16:24:15 <lbragstad> which i think we'll have to take with a grain of salt when we compare those things to reality, but that's only going to further prove the areas we need to work on
16:24:21 <edmondsw> we would have a global scope concept... i.e. you could assign a role to a user for a domain or a project OR globally
16:24:54 <ayoung> dolphm, do you remember what it was called and who owned it?
16:25:31 <ayoung> edmondsw, so that is what "admin_project" can now support
16:25:59 <edmondsw> admin_project is a hack... lbragstad asked what we would do if we could do it all over again
16:26:06 <ayoung> you can write policy that says 'you have to have the admin role on the admin project" to be a global admin.  We could write more specified policy than that, too
16:26:21 <dolphm> ayoung: no?
16:26:24 <thinrichs> More use cases…(the ones implemented): https://docs.google.com/document/d/1w55wDighZvI9zKAtnO4jOfDMScmN7Qf5NHFtFdk8Sas/edit#heading=h.v7jiiyumrken
16:26:47 <ayoung> edmondsw, it is not a hack.  It was the assumption upon which policy was written way back in the termie days,
16:27:03 <edmondsw> ayoung I totally disagree
16:27:31 <ayoung> edmondsw, yeah, well you are not the one that tried to change it and then got slammed by the operators...
16:27:33 <ayoung> heh
16:27:45 <dstanek> lbragstad: ++ having a vision without worrying about what we have is important. the reviews would be the baby steps to get us there
16:27:48 <ayoung> but, we need some way of saying "here is the global scope"
16:28:26 <ayoung> I was originally hoping to implement it based on hierarchies but we ran into the HMT role inheritance, and, well, its hard
16:28:43 <dstanek> ayoung: root domain?
16:28:48 <ayoung> dstanek, yes
16:29:28 <ayoung> dstanek, and any role assigned on a level of the hierarchy would be valid all the way down.  However, I like the idea of "rescoping" and the operations absolutely did not want that
16:29:33 <ayoung> they are probably wrong
16:29:40 <dstanek> cloud admin has admin role on root domain, domain admin has admin on any other domain and a project admin has admin on a project (i realize that domain/project admins are essentially the same)
16:29:56 <edmondsw> ayoung I think you were looking for this a minute ago: https://review.openstack.org/#/c/274157/
16:29:59 <ayoung> from a security standpoint, it is a frightening approach
16:30:04 <dstanek> ayoung: they didn't want rescoping?
16:30:21 <dstanek> ayoung: what is frightening?
16:30:26 <ayoung> edmondsw, that was a subset, yes, but there was a more complete one.  It was jamielennox's I thouight
16:30:40 <edmondsw> ayoung, right, that was just the first I found
16:30:43 <ayoung> edmondsw, this was a cross-project spec
16:31:09 <ayoung> but I don't even know how to find those
16:31:38 <edmondsw> ayoung https://review.openstack.org/#/c/245629/
16:31:48 <ayoung> edmondsw, BINGO!
16:31:57 <ayoung> #link https://review.openstack.org/#/c/245629/
16:32:03 <lbragstad> https://specs.openstack.org/openstack/openstack-specs/
16:32:22 <lbragstad> (published ones) ^
16:32:28 <ayoung> So the goal of that spec was to provide a set of roles that allowed for the above use case plus a few more
16:32:38 <ayoung> Observer, as edmondsw just linked to is a big one
16:32:48 <edmondsw> that's why I found it first :)
16:32:49 <ayoung> that is another one that people want with out scoping, and again, it scares me
16:33:01 <ayoung> the other is per-service admin
16:33:18 <ayoung> so nova-admin can't mess up neutron and glance-admin can't touch keystone, etc
16:33:59 <ayoung> so...lets skip the RBAC based use cases for the moment, as I will talk about them at the end
16:34:03 <ayoung> the other use case is this:
16:34:35 <ayoung> "allow different levels of user access for a resources in a project"
16:35:04 <ayoung> that means that, in a single project, I might have vms that edmondsw can only view, and he might have ones that he can admin, but I can only view, etc
16:35:29 <ayoung> the typical way this use case is framed is based on VM ownership, at the user level, but that is not the only way it can be
16:36:17 <ayoung> its a general concept, though, that the openstack model does not easily support
16:36:31 <ayoung> right now, the level of abstraction is "project is the label used for access control"
16:36:40 <ayoung> and in doing that, it mixes two things:
16:36:58 <ayoung> 1.  how do I list/create a set of objects
16:37:10 <ayoung> 2. how do I have access to these objects
16:37:40 <ayoung> if you compare it with a unix file system, its like we force a one-to-one relationship between dentries and inodes
16:38:02 <ayoung> IE.  we have not way of talking about the objects *outside* for the hierarchy used to organize them
16:38:29 <ayoung> I don;t think this is something that we can easily fix, but it is one of the driving reasons people keep coming up with more complex policy schemes
16:38:50 <ayoung> OK...enough lecturing from me.  Does all this (or any of it) make sense?
16:39:13 <dstanek> ayoung: i've long wanted to have access for a resource like 'identity:user_list' or a specific resource entity like 'identity:user_get:id=12345', which it sounds like this is allowing
16:39:45 <ayoung> dstanek, well, yes, it does, but you need to store that info somewhere, and that is the problem
16:40:00 <ayoung> it means that, for every resource, you need to have a shadow record in the remote PDP
16:40:12 <ayoung> so, say you had an idea like, subnetwork-groups
16:40:25 <ayoung> any you want to say that a subnet can be in one or more subnet groups
16:40:48 <ayoung> and that access is going to be based on what subnet groups a user is enrolled in
16:41:02 <ayoung> all that info has to be either in keystone, in neutron, or in the remote PDP
16:41:07 <edmondsw> dstanek coding the id like that probably wouldn't be practical... you need some some way of doing things more dynamically
16:41:18 <ayoung> for every user, for every subnet group, and for every subnet.
16:41:44 <edmondsw> dstanek e.g. owner_id=me where owner_id is an attribute of the resource stored by the relevant service
16:42:14 <dstanek> ayoung: edmondsw: i'm trying to tease out the usecase we care about. so specific entity isn't one of them?
16:42:36 <edmondsw> dstanek btw we don't have anything like owner_id today... some resources remember who created it, but that may or may not who you want to be responsible for it now, or you might want to share responsibility across a group of owners, etc.
16:42:49 <edmondsw> dstanek I don't think so
16:43:23 <thinrichs> dstanek: I'd imagine we'd want specific entities but referenced by groups that are dynamically constructed
16:43:32 <dstanek> edmondsw: can you add that to the etherpad? and anything else you are about being able to assign based on
16:43:47 <edmondsw> dstanek sure
16:43:52 <ayoung> dstanek, I would argue that there are other was to implement what people want.  I think the use case, though, is that, for a complex setup, allow different access to resources of the same type based on *SOME* critera
16:44:13 <dstanek> "this is my thing and i want to give Frank access to it" - is that a specific usecase?
16:44:34 <ayoung> I would prefer to allow "mounting" an object from one project into a separate project, and have different access control rules based on which project the resource was accessed through
16:46:00 <thinrichs> dstanek: I'd say so
16:46:42 <edmondsw> dstanek what I put in the pad make sense?
16:46:54 <lbragstad> i thinks o
16:47:35 <edmondsw> dstanek "I want to grant Frank access"... wouldn't that get into trusts?
16:48:29 <edmondsw> ayoung go on... I have a workitem to look at how you'd move a resource from one project to another, and some kind of mounting will probably be necessary as an interim step
16:48:32 <dstanek> edmondsw: makes sense
16:49:00 <dstanek> edmondsw: not sure because you could say that about most of what we are doing
16:49:26 <dstanek> cloud admin (admin on root project) delegates admin on a project to Joe (a domain admin)....
16:50:05 <dstanek> ayoung: what an example of mounting?
16:50:24 <lbragstad> like checking the attributes of a server using Neutron?
16:50:38 <edmondsw> time check: 10 minutes left
16:50:44 <lbragstad> edmondsw thanks
16:51:12 <lbragstad> or are we talking about mounting as in take this VM and mount it on this other project?
16:51:55 <edmondsw> dstanek mounting example: I have a VM in project A, and I want to make that visible in project B as well
16:52:16 <ayoung> ok...let me cover my last two items, please?
16:52:42 <ayoung> Bug 968696 Work
16:52:42 <openstack> bug 968696 in OpenStack Identity (keystone) ""admin"-ness not properly scoped" [High,In progress] https://launchpad.net/bugs/968696 - Assigned to Adam Young (ayoung)
16:52:50 <ayoung> I need some help here.  Made some progress but...
16:53:01 <lbragstad> #topic the infamous bug 968696
16:53:03 <ayoung> A little background:
16:53:17 <ayoung> this is the admin_project stuff edmondsw and I were discussing earlier
16:53:32 <ayoung> we need to add a rule to each of the policy files to check that field for admin-over ride
16:53:39 <ayoung> and glance and cinder now pass
16:53:43 <edmondsw> ayoung where do we stand on the nova patch we'd put up?
16:53:46 <ayoung> but..nova does not, and Keystone is a mess
16:53:56 <ayoung> edmondsw, so I got the roll back on the devstack change that was getting in the way
16:54:09 <ayoung> but nova has a different gate job that seems to it via some other mechanism.
16:54:09 <edmondsw> :)
16:54:12 <ayoung> LInk in a sec...
16:54:36 <ayoung> https://review.openstack.org/#/c/384642/  is a successful one for comparison
16:54:51 <edmondsw> I am happy to try to help there when I can spare cycles
16:54:51 <ayoung> https://review.openstack.org/#/c/384148/  is the nova one
16:55:07 <ayoung> so that has fewer failing jobs, but I think they are for the same reason"
16:55:13 <ayoung> something is setting is_admin_project
16:55:30 <ayoung> there are also a handful of changes that keystone needs as prereq, but I can handle those
16:55:41 <ayoung> edmondsw, if you could see the nova one on through, that would be the most help
16:55:46 <edmondsw> can you point me to the devstack roll back for comparison?
16:56:10 <ayoung> edmondsw, it was just a removal of setting is_admin_project by default...let me see...
16:56:21 <ayoung> I'll do that later...one other thing first
16:56:25 <edmondsw> later's fine
16:56:45 <ayoung> I'll keep working on Keystone, but there are some refactorings that need to happen frist...
16:57:03 <ayoung> https://review.openstack.org/#/c/387161/  and
16:57:07 <ayoung> https://review.openstack.org/#/c/387710/
16:57:12 <ayoung> please review and move those along
16:57:18 <ayoung> those are prereqs for
16:57:39 <ayoung> https://review.openstack.org/#/c/257636/
16:57:58 <ayoung> which I will rename to be consistent with the nova and glance reviews
16:58:02 <ayoung> ok last thing, rushed
16:58:07 <ayoung> RBAC in m,iddleware
16:58:08 <lbragstad> #topic rbac in middleware status
16:58:23 <ayoung> review has 2 +2s, and some comments from lbragstad to address
16:58:40 <ayoung> I think it is going to make it in to the "approved for Ocata" pile
16:58:52 <lbragstad> #link https://review.openstack.org/#/c/391624/
16:59:11 <lbragstad> ayoung dstanek had a bunch of comments on patch set 11 that i attempted to port
16:59:14 <ayoung> this is a layer on top of policy, and should only be hardening, will not open new ways around
16:59:19 <ayoung> lbragstad, ++ and I will address
16:59:32 <ayoung> is everyone comfortable with the approach?
16:59:46 <lbragstad> i have a couple big concerns
16:59:50 <lbragstad> i reviewed it last night
16:59:58 <ayoung> perf, security, or other?
17:00:14 <lbragstad> the splitting of rbac into it's own check
17:00:18 <lbragstad> we're out of time
17:00:26 <lbragstad> we can continue in -keystone
17:00:28 <lbragstad> #endmeeting