16:01:20 <lbragstad> #startmeeting policy
16:01:20 <openstack> Meeting started Wed Nov 30 16:01:20 2016 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:24 <openstack> The meeting name has been set to 'policy'
16:01:36 <lbragstad> raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan_09
16:01:40 <topol> THANks everyoen
16:01:43 <dolphm> \o/
16:01:44 <rderose> o/
16:01:47 <dstanek> o/
16:01:49 <lamt> o/
16:01:56 <ruan_09> o/
16:03:05 <ktychkova> o/
16:03:53 <gagehugo> o/
16:03:56 <samueldmq> hi all
16:04:18 <lbragstad> hello, good morning, good afternoon
16:04:20 <lbragstad> #topic action items from last week
16:04:31 <lbragstad> #link https://etherpad.openstack.org/p/keystone-policy-meeting
16:04:41 <lbragstad> agenda in case anyone doesn't have the link ^
16:05:19 <lbragstad> for those who missed it - we spent last week discussing ayoung's proposal and going through ktychkova's Apache Fortress example
16:05:51 <lbragstad> #link https://review.openstack.org/#/c/391624/ to ayoung's RBAC spec
16:06:33 <lbragstad> I, personally, have a bunch of questions left on that spec, but ayoung isn't here so we can circle back if he shows up
16:07:06 <lbragstad> did anyone have a chance to look at #link https://review.openstack.org/#/c/237521/ ?
16:07:28 <ruan_09> yes, I've studied it
16:07:32 <lbragstad> ^ which was ktychkova's PoC on apache fortress
16:07:49 <lbragstad> i think the big hurdle we uncovered with that last week was the AF doesn't really allow scope - right?
16:07:54 <lbragstad> all role assignments are global
16:08:25 <dstanek> i thought it was interesting, but should be more configurable
16:08:31 <ruan_09> we should distingush 2 things: the approach to externalize PDP and AF's capacity to modelize policies
16:08:37 <dstanek> i started reviewing but never finished
16:08:46 <ktychkova> yes, it's right
16:08:46 <ktychkova> But I think, it is AF problem anf AF's users :)
16:08:51 <lbragstad> (and I think one of the workarounds was to duplicate role assignments)
16:08:54 <edmondsw> I didn't get a chance to dive into it, but just going off the commit message it doesn't seem to address checks that have more than 2 levels
16:09:33 <ruan_09> whether scoped or not scopted, it's up to each PDP
16:09:36 <samueldmq> edmondsw: what's 2+ level checks ?
16:09:43 <edmondsw> looking for an example...
16:10:25 <edmondsw> e.g. from neutron: create_network:provider:network_type
16:10:45 <samueldmq> edmondsw: ok so those are checks on resources that come from database
16:10:56 <samueldmq> afaik AF only takes care of RBAC
16:11:03 <edmondsw> well, from code... may or may not be db code
16:11:11 <edmondsw> this is RBAC
16:11:19 <samueldmq> no this is not
16:11:22 <edmondsw> ?
16:11:27 <samueldmq> RBAC is purely authz based on roles
16:11:37 <edmondsw> and this isn't why?
16:11:38 <samueldmq> this is something more than RBAC, because this is not a role
16:11:49 <edmondsw> it is a role check
16:11:54 <ruan_09> we've sightly modified the 237521, and it works for another external PDP
16:12:10 <samueldmq> edmondsw: ok. neutron: create_network:provider:network_type is a role check
16:12:28 <lbragstad> ruan_09 which one?
16:12:31 <samueldmq> I thought it was not. anyways this is not the point here, sorry (don't want to discuss naming)
16:13:03 <edmondsw> samueldmq, let's say you want to allow someone to create some kinds of networks but not others, based on their role... you define multiple policy checks, so you can check different roles depending on what the request is asking to create
16:13:07 <ruan_09> the one we used in OPNFV: https://wiki.opnfv.org/display/moon/Moon
16:15:24 <ruan_09> I sugget to make the 237521 as a generic hook to external PDP
16:15:29 <thinrichs> Can we finish the example?  create_network:provider:network_type is a role check on the user asking to create a network?  Or it's a role check on the network they're trying to create?
16:16:54 <edmondsw> thinrichs a check of the user's role to make sure they are allowed to create the type of network they're trying to create
16:17:14 <lbragstad> https://github.com/openstack/neutron/blob/master/etc/policy.json#L50-L56
16:17:38 <edmondsw> so I think only the service (in this case neutron) can do that, because only it is parsing the request and will know which of these kinds of checks it needs to test and which it does not
16:18:57 <ktychkova> I'm not ready to show how (if) AF can work in such example. I'm sure I can answer next week. I need to run some tests
16:19:11 <lbragstad> edmondsw means it's up to the service to check ownership
16:19:14 <lbragstad> meaning*
16:19:47 <edmondsw> lbragstad, yeah, I don't know much about AF but I can't see how something else would easily do that
16:20:09 <edmondsw> lbragstad, though I'm not sure ownership is the right word
16:20:18 <lbragstad> edmondsw right - not AF specific, but just the way policy currently is in openstack
16:21:08 <lbragstad> samueldmq does that answer your question?
16:21:50 <samueldmq> lbragstad: edmondsw yes if the only check behind it is a role check that's pure rbac
16:22:27 <edmondsw> samueldmq of course policy.json today would let you check other things besides the roles, but usually it's just checking role, as the default does in that example
16:23:18 <ruan_09> if you want to know more about RBAC and its future, I suggest you to read http://www.profsandhu.com/miscppt/kth_abac_141029.pdf
16:23:32 <ruan_09> the father of RBAC's recent presentation
16:23:39 <samueldmq> edmondsw: yes, you're right ++
16:24:08 <ruan_09> rbac can't solve all the problem
16:25:54 <dstanek> ruan_09: thx for the link
16:26:13 <dstanek> more background is always helpful to folks for these types of asks
16:26:47 <lbragstad> dstanek ruan_09 ++
16:27:16 <lbragstad> so we had another action item to document what we expect from policy at this level
16:28:17 <ruan_09> maybe we can firstly enable external PDP, than take a look at implementations to decide which one to use?
16:28:19 <lbragstad> do we expect it to be flexible enough for applications running on openstack?
16:28:32 <lbragstad> do we expect it to only work across services?
16:28:54 <thinrichs> I would think apps are out of scope and we should focus on ops.
16:29:10 <lbragstad> thinrichs i think i would agree with that
16:29:36 <thinrichs> What do you mean "work across services"?  Do you mean decisions can be based on data/conditions from multiple services?
16:30:18 <lbragstad> thinrichs kind of like what it does today where you have policy that protects operations across openstack services
16:30:22 <thinrichs> Or do you mean you want access control to apply to *sequences* of API calls that span services?
16:31:11 <thinrichs> lbragstad: got it.  Do we want a logically centralized way of expressing policy that applies to all services?
16:31:31 <lbragstad> thinrichs centralized in what sense?
16:31:48 <lbragstad> as in owned by a single service?
16:32:10 <ruan_09> defined policy in one place and enforced by all services?
16:32:40 <thinrichs> Not sure what ownership means here.  I'd say users want a single place to go see/write policy...
16:32:54 <thinrichs> and that implementationally we'd want each service to enforce that policy independently.
16:33:17 <dstanek> does any of this account for having policy created by someone other than cloud admins? domain admins for example?
16:33:36 <ayoung> Sorry I'm late.
16:33:52 <thinrichs> dstanek: I'd think the multiple-author issue is one of how do we express policy--how do we make it easy for multiple people to collaboratively define policy?
16:34:01 <lbragstad> thinrichs does having it in a single place imply being easy to manage?
16:34:41 <thinrichs> I've definitely heard from folks saying that having N places to edit/maintain policy makes it hard to manage.  Not saying 1 place necessarily makes it easy, but certainly easier.
16:34:49 <lbragstad> thinrichs or is the easy of management mean more than it being centralized or not?
16:34:52 <ayoung> So, we have 3 levels of policy mechanisms that we have discussed.
16:35:02 <ayoung> Aside from the existing "edit it everywhere"
16:35:15 <thinrichs> Definitely want more than just centralization to make it easy to manage.
16:35:23 <lbragstad> thinrichs i would agree with that
16:35:24 <ayoung> 1. Is external, like the Fortress case, where we make the policy decisions on a remote system
16:35:40 <ayoung> 2. is the dynamic policy pproach we pursued until last year
16:35:54 <ayoung> 3. is leavethe existing policy alone and add an additional layer oin top
16:36:10 <thinrichs> What's the difference between (1) and (2)?
16:36:31 <ayoung> 3 Only works if we are OK with the existing checks, but want to perform more filtering, which is the only thing I think will actually make it through
16:36:48 <ayoung> thinrichs: in 2 the policy decision is still made inside the service;
16:37:02 <ayoung> we just fetch the remote policy rules from a central repo...Keystone policy
16:37:10 <ayoung> it had some real shortcomings
16:37:33 <thinrichs> I'd want to separate out PAP (administering/authoring policy) from PEP (enforcing).
16:37:33 <ayoung> the first was that the nodes did not know their own identity to fetch the proper policy file
16:37:42 <thinrichs> 1. is then PAP and PEP are the same (external)
16:37:53 <lbragstad> does anyone here talk to their operators, or know what kind of changes are made to policy in the real world? When folks change it, are they changing the whole thing or just making small tweaks? (edmondsw)
16:37:55 <thinrichs> 2. is then PAP is external and PEP is local
16:37:56 <ayoung> to, in that approach, the PAP was Keystone, the PEP/PDP was oslo-policy call inside the service
16:38:11 <ayoung> thinrichs: yep
16:38:20 <ruan_09> thinrichs: no, PAP/PDP is external, PEP is inside each service
16:38:40 <ayoung> So, we do have a way we can continue on there.
16:38:43 <lbragstad> currently the PAP is whatever configuration management system you use for your deployment
16:38:53 <thinrichs> 3. Not sure what this one is...probably PEP is local and PAP is external
16:39:00 <ayoung> The issue was that we were trying to name the policy files by Endpoint.  There was a proces problem there:
16:39:04 <edmondsw> lbragstad, I think the feedback at the summits has been that folks are increasingly changing more in policyin Tokyo was the folks were and Austin (I missed Barca) was that
16:39:13 <edmondsw> ignore the end of that...
16:39:14 <thinrichs> lbragstad: that's interesting--using CAPS as your PAP
16:39:45 <edmondsw> as for me, I'm overriding lots of policy.json defaults
16:39:55 <edmondsw> maybe 90%
16:40:03 <lbragstad> O.O
16:40:11 <ayoung> endpoints are essentially only named by their URLs in theservice catalog.  The install tools balked at the idea that you would: register the endpoint, get an endpoint ID from Keystone, add that to the config mgmt, update the config and then use that ID to fetch policy
16:40:25 <ayoung> but...it turns out we really don't need to do that.
16:40:45 <ayoung> we just need a name to fetch policy by.  Does not need to be anything other than human readable, and pre-calculatable
16:40:58 <ayoung> and that is the approach I am using in the RBAC-Middleware approach
16:40:59 <lbragstad> thinrichs well - partially, because you typically have a CMS to lay down config, and policy.json is currently considered configuration... but the other part would be the keystone role API.
16:41:06 <ayoung> we could do the same for Dynamic policy
16:41:39 <ayoung> lbragstad: and that was a huge driving factor;  people were more comfortable with policy in CMS than in a dynamic store like Keystone.
16:41:59 <ayoung> Which is another reason I pursued the RBAC in Middleware approach instead
16:42:10 <ayoung> RBAC is "on top" of existing policy
16:42:27 <ayoung> as none of the existing policy files check roles on most calls
16:42:58 <edmondsw> ayoung ?
16:43:06 <lbragstad> they check *a* role
16:43:09 <ayoung> the shortcoming, of course, is that it does only RBAC, not the full ABAC, but then again, oslo-policy can only do ABAC if the services provide the attributes
16:43:21 <lbragstad> right
16:43:30 <ayoung> and we don't know what attributes they are going to provide...it is all over the place, as jamielennox found
16:43:30 <lbragstad> which i don't necessarily consider a bad thing
16:43:45 <ayoung> lbragstad: not even A role...just that the token has a project
16:43:52 <edmondsw> default policy.json can't check roles, plural, today because there is only one default role :)
16:44:06 <ayoung> it implies a role, but a wierd token with 0 roles but a project ID would pass the policy check.
16:45:15 <edmondsw> ayoung, a large number of the default checks look for the admin role
16:45:20 <lbragstad> edmondsw from your perspective, what would assist you in making less policy overrides?
16:45:33 <ayoung> So...those are some of the driving reasons I posted this https://review.openstack.org/#/c/391624/
16:45:50 <ayoung> edmondsw: yep, and we still need to complete the 968696 work around that
16:45:55 <edmondsw> lbragstad, fixing each service individually... this is a nova problem, a neutron problem, a glance problem, etc... not a keystone problem
16:46:01 <ayoung> an admin api is an admin API.
16:46:11 <ayoung> Opening it up will still required a policy.json change
16:46:30 <edmondsw> making each service (nova, etc.) consistent with the others would be a big help
16:46:51 <lbragstad> edmondsw would you say nova's approach to putting policy in code (oslo) moves in the right direction?
16:46:56 <edmondsw> I think what nova did, and cinder is now doing, to move policy defaults into code instead of policy.json is a good step as well... makes the files much more readable
16:46:58 <lbragstad> edmondsw or is the moot to you?
16:47:00 <edmondsw> and the yaml support
16:47:01 <ayoung> The other thing that is lacking is the ability to map from the policy rules to the APIs
16:47:25 <edmondsw> ayound the admin_api rule you're referring to checks for the admin role...
16:47:50 <ayoung> with the RBAC in MIddlewaree, we enforce policy on the URL pattern, instead of some cutpoint inside the code
16:47:56 <ayoung> and I have an analogy.
16:48:14 <ayoung> RBAC is like file permisions, oslo-policy is like SE Linux
16:48:18 <lbragstad> ayoung have you seen dstanek's example on your review?
16:48:19 <lbragstad> regarding the URL pattern?
16:48:42 <edmondsw> ayoung, you can enforce a certain level of RBAC on the URL pattern, but there are RBAC cases that won't have the information you need in the URL
16:48:48 <edmondsw> we were discussing one before you joined
16:49:25 <ayoung> edmondsw: yep...anything on the payload or even query parameters are not covered yet
16:49:37 <ayoung> and anything on the object fetched from the database is out, too
16:49:47 <edmondsw> e.g. you ask to create a network, and neutron checks not only that you can create a network (one policy check) but also that you can specify what you did in the request body (potentially multiple additional policy checks)
16:50:23 <edmondsw> good, we're on the same page :)
16:50:38 <ayoung> edmondsw: so nothing prevents that from happening now, but my understanding is that the code that performs things like that are very much hard coded, and should be left to the neutron team to affect.
16:50:56 <edmondsw> agreed
16:51:03 <ayoung> if there are cases where they need aspecific role to perform something, that is going to be new effort as well
16:51:57 <ayoung> There is nothing keeping the Neutron team from using the RBAC mechanism later on if they want to, just that I am not driving the implementation off those use cases
16:52:07 <dstanek> ayoung: i'd love to get all of the usecase documented so that we can apply the solutions to them and see how they compare
16:52:18 <lbragstad> dstanek ++
16:52:24 <thinrichs> +1
16:52:29 <ayoung> It is a free form pattern.  They could bastarize it to do anything they wanted, so long as they can map a patter to a role
16:52:48 <ayoung> neutron policy is not something that the end deployer should be breaking....
16:52:57 <edmondsw> breaking?
16:53:17 <ayoung> editing the policy.json file and changing in such a way it triggers a 500 error
16:53:19 <lbragstad> 8 minute warning
16:53:53 <edmondsw> if you add roles, then you have no choice but to edit policy
16:54:10 <ayoung> edmondsw: hence my spec and approach using RBAC in middleware
16:54:30 <dstanek> ayoung: i still think there are cases where the role must exist in the policy file
16:54:30 <ayoung> that is what https://review.openstack.org/#/c/391624/  is proposing
16:54:57 <edmondsw> ayoung sorry, I haven't read the latest version yet... I had I think 50+ comments on the version I did read, but I think you were going to rewrite after that
16:54:58 <ayoung> dstanek: heh...probably, but we can defer that until we can do roles in general
16:55:13 <edmondsw> dstanek definitely
16:55:15 <ayoung> I would suggest we resurrect dynamic policy once we get that one in
16:55:41 <ayoung> the idea of fetching policy by 'tag' as opposed to service name to do endpoint specific policy will work
16:55:52 <edmondsw> we're not suggesting that the ability for neutron, etc. to make checks against the role would be removed, are we? Because that is a non-starter
16:55:52 <dstanek> ayoung: my problem with what we have been talking about so far is that i don't see the vision. so i don't know if the steps get us there
16:55:56 <ayoung> the default is that nova would fetch the "compute" policy
16:56:27 <ayoung> dstanek: I would say that the vision is 3 things:
16:56:48 <ayoung> 1.  perform the RBAC check based on the URL, not a rnadom string, so that people can fugyure out what they need to delegate
16:56:55 <lbragstad> edmondsw the spec pulls the role check into keystonemiddleware
16:56:58 <edmondsw> s/the/an/
16:57:11 <ayoung> 2.  make it possible for people to create more fine grained roles for a set of a tasks so they can delegate a subset of them
16:57:47 <ayoung> 3. make it possible for people to change the RBAC for operations without breaking the parts of policy that require engineering knowledge of the remote systems
16:58:00 <edmondsw> you can pull A role check into keystonemiddleware, but you can't prevent the service from doing additional checks also based on role
16:58:30 <lbragstad> edmondsw that's kinda what dstanek left as a comment
16:58:43 <ayoung> I did my best to make it as clear as possible in that spec.
16:59:05 <lbragstad> alright - two minutes left, but it sounds like we still have a lot to discuss on the sepc
16:59:25 <lbragstad> I'd like to have folks bring some more ideas to the meeting next week
16:59:32 <ayoung> can we agree to all read and comment on the spec for next week?  And maybe have a vote on it to pursue or not?
16:59:37 <lbragstad> so if you have any - please add them as agenda items
16:59:38 <thinrichs> ayoung: I'm still missing the big picture.  Are you aiming for a single PAP for all services?  Are you envisioning the possibility of an external PDP? Are you committed to local PEPs?
16:59:39 <lbragstad> ayoung i have been
17:00:01 <ayoung> thinrichs: single PAP.  local PEPs
17:00:11 <ayoung> thinrichs: Only RBAC
17:00:16 <edmondsw> I think #3 touches on another pain point I have changing policy... that lots of times one check leads to another down the line in unexpected ways... e.g. creating a new server/vm is going to end up causing checks in neutron, cinder, glance, etc.
17:00:18 <lbragstad> ruan_09 your proposal for external PDP would be good for that
17:00:29 <ruan_09> ok,
17:00:44 <lbragstad> alright - let's continue in #openstack-keystone if needed
17:00:48 <lbragstad> #endmeeting