16:00:07 <lbragstad> #startmeeting policy
16:00:08 <openstack> Meeting started Wed Dec 14 16:00:07 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:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:12 <openstack> The meeting name has been set to 'policy'
16:00:23 <ayoung> Oyez oyez
16:00:29 <lbragstad> ping raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ayoung, ruan_05
16:00:58 <rderose> o/
16:02:13 <lbragstad> we'll give it a minute or two
16:02:16 <ayoung> Agenda link?
16:02:23 <edmondsw> gonna try to be in 2 meetings at once, so we'll see how that goes
16:02:29 <lbragstad> #link https://etherpad.openstack.org/p/keystone-policy-meeting
16:02:46 <ruan_05> you have a question for me during the last meeting?
16:03:03 <ruan_05> External PDP and PEP hooks in oslo.policy [ruan]
16:03:07 <lbragstad> ruan_05 you had a topic on the agenda last meeting
16:03:37 <lbragstad> ruan_05 do you want to go through that today?
16:03:43 <ruan_05> yes
16:03:51 <lbragstad> ruan_05 alright - i'll add it
16:04:09 <ayoung> So...how would we write the following as a use case?
16:04:30 <lbragstad> let's wait for dstanek to show up
16:04:44 <lbragstad> he's been trying to collect a bunch of them
16:04:44 <ayoung> Two users need to collaborate.  They need a shared Network for their servers to talk on, but they each want to maintain controll of their own resources
16:05:04 <ayoung> And, related
16:05:25 <ayoung> Two users want to collaborate.  One owns the quota for the servers, the other the storage
16:05:59 <ayoung> are those embedded in the existing use cases, or are they new ones?
16:06:31 <lbragstad> #topic Review policy use cases
16:06:38 <lbragstad> #link https://etherpad.openstack.org/p/keystone-policy-usecases
16:06:58 <lbragstad> ayoung those sound like new usecases
16:07:11 <rderose> lbragstad:++
16:08:12 <lbragstad> ayoung so - as a user I want to be able to share resources with other users within my domain/project?
16:08:20 <ayoung> the second one is actually the MOC  Hardware federation one, but scaled back a bit
16:08:48 <ayoung> lbragstad, I was trying to avoid talking about projects in the definition
16:09:24 <lbragstad> ayoung are we talking about collaboration across all users regardless of the domain they are in?
16:09:33 <lbragstad> domain/project/whatever?
16:09:37 <ayoung> I had been thinking about these in terms of HMT, but yes,  the idea is that, the way that Nova is defineid, all of the resources in play need to be in the same project , at least for the second use case
16:10:02 <ayoung> for the first one, it might be possible to link two servers together in different projects, making all the trickiness happen at the Neutron level
16:10:43 <lbragstad> ayoung what exactly do you mean by owning the quota and owning the storage?
16:10:43 <edmondsw> ayoung I just assumed that first usecase would have the network shared across 2 projects... which you can already do
16:11:09 <ayoung> edmondsw, yes, but don't you need an admin to set up that network for you now?
16:11:22 <ayoung> as a non-admin user, there is no way to share a resource across projects
16:11:52 <lbragstad> but don't users really only care about things *in* their project?
16:11:54 <edmondsw> ayoung oh, you want the non-admin to actually be the one to initiate sharing? I didn't get that from the first read
16:12:19 <edmondsw> ayoung I don't know if you could do that today or not
16:12:47 <ayoung> edmondsw, lbragstad so, lets think alongthe lines of "how can we push capabilities down to the lowest level without breaking security"
16:13:26 <ayoung> right now, everything is in a project, and a user has the same power on all resources of the same class
16:13:45 <edmondsw> https://github.com/openstack/neutron/blob/master/etc/policy.json#L50 looks like allowing non-admin would require a policy change
16:13:58 <ayoung> if we want people to have different levels of access in a single compute setup, how do we enforce that?
16:14:35 <ayoung> Is i a question of mixing things from two different projects, or do we need to provide some gradiation of capability for the same type of resource withing a single project?
16:15:11 <ayoung> edmondsw, is a shared network a global resource, or is it explicitly shared between two projects?
16:15:39 <lbragstad> it sounds like the gradient comes from service attributes about the resource
16:15:51 <edmondsw> ayoung a shared network belongs to one project, but can also be seen/used in others
16:16:09 <ayoung> edmondsw, see, that is the abstraction I would like to see across the board
16:16:24 <ayoung> inode vs dentry in Filesystem speak
16:16:34 <edmondsw> neutron has done some good things with policy as far as allowing flexibility
16:16:49 <edmondsw> I assume the solution to your second usecase about quotas would follow some examples from neutron, actually
16:17:06 <lbragstad> i agree that it should be possible to do that - but I'd still like to maintain the ability to keep my project a black box, too
16:17:41 <ayoung> edmondsw, yeah, the volume created in cinder is kindof like the shared network
16:17:52 <edmondsw> neutron doesn't just have a check for create_network... they also have multiple other checks that they'll test if you try to create networks with certain parameters.
16:17:59 <ayoung> I want it owned by Proj1, but used in Proj2
16:18:03 <edmondsw> you could do the same kind of thing for different types of quotas
16:18:24 <edmondsw> have one check to determine whether you're allowed to change quotas at all, and another to determine if you're allowed to change a specific quota
16:19:46 <ayoung> edmondsw, I think of quoats in terms of HMT. They are resources managed by the containing project
16:19:48 <lbragstad> ayoung I added your first use case to the etherpad
16:19:52 <ayoung> lbragstad, Thanks
16:20:08 <ayoung> lbragstad, that is one of the questions that lead to this group being forms
16:20:10 <ayoung> fomred
16:20:11 <edmondsw> ayoung I don't think I said anything conflicting with that
16:20:12 <ayoung> formed
16:20:29 <ayoung> edmondsw, right, I think that they go hand in hand
16:20:36 <edmondsw> ayoung maybe I didn't understand your use case
16:20:54 <lbragstad> ayoung edmondsw are we talking about the second one from above or a different one?
16:21:04 <ayoung> If I have a "quota" role on the parent, I can adjust the quota levels on the child projects
16:21:08 <edmondsw> ayoung I thought you wanted project-level quota A to be changeable by user A and another project-level quota B (for the same project) changeable by another user
16:21:21 <ayoung> but I don't know if that is relvant here
16:21:40 <ayoung> I think quota even in my use cases would be applied only on the project where the resource is created
16:22:29 <ayoung> edmondsw, Ah, no.  I didn't specify that.
16:23:04 <ayoung> It kind of implies a level between user and project, though
16:23:20 <ayoung> which is one way we coud go:  resource groups inside a project.
16:23:46 <edmondsw> I'm confused :)
16:23:47 <ayoung> It would be a more granular label than just the project ID, but more course grained than userid
16:23:59 <ayoung> edmondsw, all of this resolves to scope check
16:24:02 <lbragstad> I am, too... I'm not sure what use case we're talking abou t
16:24:12 <ayoung> right now, the only scope check we have is the project one
16:24:28 <ayoung> and openstack (with small exceptions) assumes all resources for something are in the same project
16:24:41 <ayoung> and all resources of the same type have the same access control
16:25:04 <ayoung> we've had several requests for "you can't power off my VMs" type access control
16:25:18 <lbragstad> an example being all instances created within a project
16:25:24 <ayoung> lbragstad, right
16:25:40 <ayoung> lbragstad, say we havea project which is the development area for a project team
16:25:52 <lbragstad> so - as a user, you want to tie operations to specific resources in a project
16:26:13 <ayoung> lbragstad, that is one way to define it
16:26:26 <ayoung> I'm trying to make the use case more general
16:26:46 <ayoung> such that we don't necessariuly need to redefinie the project scoping everywhere
16:27:21 <lbragstad> it sounds like project scoping would be the loosened version of this type of checking
16:27:24 <ayoung> but we don't currentl have any operationes which check your roles on two different projects
16:27:45 <ayoung> one possibility is that you use two tokens, one for each project in an operation
16:28:16 <ayoung> say we have a "mount" operation that exposes a volume created in one project to be mountable in a second project
16:28:44 <ayoung> would that be better or worse than trying to change the scope/permissions inside a single project?
16:28:54 <lbragstad> from a usability perspective - that only really makes sense for operations across projects, which i think is a different use case from being able to tighten operations other people can do on resources I've created
16:28:55 <ayoung> Would it be more useful, more powerful?
16:29:23 <ayoung> lbragstad, ah, but with HMT, we can solve the "what can yo udo on my resources"
16:29:37 <ayoung> create a parent project for dev, give each developer their own sub projects
16:30:52 <ayoung> So if You do this, and the developers themselves want to be able to set up networking accross their individual projects to collaborate, we should be able to do that without making any of them admin
16:30:59 <lbragstad> well - that kind of solves the problem because you're creating more isolation which leads to using role assignments for access across the projects
16:31:01 <ayoung> or if they want to share volumes, etc
16:31:18 <ayoung> lbragstad, right, that is how I've been thinking of the problem thus far
16:31:19 <lbragstad> but what happens if I don't have HMT
16:31:36 <lbragstad> and I want to be able to give my users the same type of flexibility
16:31:38 <ayoung> lbragstad, why would you not have HMT?
16:31:41 <ayoung> It is par of Keystone
16:31:48 <lbragstad> sure - just thinking about cases
16:31:57 <ayoung> you mean, what if you don't want to use it in a specific case?
16:32:04 <lbragstad> sure
16:32:16 <ayoung> right, so that is why I was trying to phrase the use case moregenerally
16:32:26 <ayoung> I think you all get the point I was trying to make.
16:32:29 <lbragstad> let's say I have a set of users and they all live within the same project, is it useful to have the same flexibility
16:32:35 <lbragstad> right
16:33:06 <lbragstad> so the use case sounds like 'as a user, i want to be able to restrict or open up specific operations on resources I create'
16:33:11 <lbragstad> s/create/own/
16:33:13 <ayoung> So, if they are in the same project, we need a way to distinguish access rights on two different resources of the same type
16:33:24 <ayoung> lbragstad, but what if *you* leave the project
16:33:24 <lbragstad> which could span the same project or multiple
16:33:46 <ayoung> I need to be able to transition your resources to, say ruan_05
16:33:53 <lbragstad> right
16:33:58 <ayoung> without tearing them down?
16:33:59 <lbragstad> or delete them, or whatever
16:34:29 <lbragstad> that would seem to fall on the admin's shoulders either way
16:34:30 <ruan_05> fine granularity of access control inside a project
16:34:30 <lbragstad> right?
16:34:38 <ayoung> admin scoped to the project should probably be OK with tearing them down, but that implies that we solve 968696
16:35:02 <ayoung> 4we need the power of something like admin scoped to a project without that admin being able to go all over the cloud and break things
16:35:22 <ayoung> So RBAC can handle that piece
16:35:39 <lbragstad> say i rage quit the project and my manager has to come in an dedicate my resources to ruan_05, or delete them, or both
16:35:57 <ayoung> lbragstad, purely theoretical
16:36:00 <ayoung> :)
16:36:02 <lbragstad> right
16:36:07 <lbragstad> ;)
16:36:12 <ayoung> so manager delete can be done with RBAC
16:36:25 <ayoung> transition...I guess is just a new API on the resource
16:36:33 <lbragstad> but they would have to transition something
16:36:35 <ayoung> a PATCH with user_id....
16:36:50 <ayoung> IFF we do user level ownership
16:37:00 <lbragstad> that way ruan_05 would get all the abilities i had when i was on the project
16:37:06 <ayoung> and, how do we distinguish that a resource should have user level policy versus project level
16:37:13 <ayoung> mix and match that in the same cloud?
16:37:51 <lbragstad> well - i can only think of cases where user level is more strict that project level
16:37:58 <ruan_05> why can't we have both?
16:38:08 <lbragstad> which sounds like keeping project level the default and opting into user level
16:38:29 <lbragstad> ruan_05 that's a good point, too
16:38:50 <lbragstad> say I don't care about exposing my instances to the rest of the people in my project, but I *do* care about my cinder volumes because that's where my data is
16:38:54 <ayoung> so, this gets into what ruan_05 did with Moon. They extracted that information, what policy, who owns etc, into an external database
16:39:31 <ayoung> The unix model is 3 tiered:  user, group, world
16:39:36 <ruan_05> our approach is one access control policy per project
16:40:24 <ayoung> ruan_05, so how many distinct projects are we talking about?
16:40:39 <ayoung> and...is that for all apis, or just a subset?
16:40:40 <ruan_05> as many as you want
16:40:55 <thinrichs> ruan_05: and can you share resources between projects?
16:41:13 <thinrichs> (which policy would govern shared resources?)
16:41:51 <ayoung> ruan_05, its not what *I* want, it is what is the intention of the deployment.  If there are millions of projects, its going to be essnetially a new policy for each operations,
16:41:52 <ruan_05> currently, we cannot share them between projects due to the openstack project isolation, theorically that's possible
16:42:26 <thinrichs> ayoung: people have *millions* of projects?
16:42:41 <thinrichs> even thousands?
16:42:43 <ayoung> thinrichs, is that really inconceivable?
16:42:44 <ruan_05> ayoung: i consider this mechanism as an option, they can deactivate it
16:42:49 <ayoung> thinrichs, thousands certainly
16:42:56 <lbragstad> yeah
16:43:13 <ayoung> ruan_05, so...lets back off the solutions for a bit...I was trying to use them to illuminate the use cases
16:43:14 <ruan_05> if user doesn't want finer control, they use default policy
16:43:24 <thinrichs> How do they get to thousands of projects?  One per user?
16:43:30 <lbragstad> i attempted to add the user cases to the etherpad
16:43:37 <ayoung> thinrichs, multiple per user
16:43:39 <lbragstad> thinrichs that's a possibility, too
16:43:42 <ayoung> one per user per task
16:44:10 <lbragstad> thinrichs as a sign up service, i could create a new project for every customer that signs up for my service
16:44:11 <thinrichs> Then sharing resources across projects seems like a clear use case.
16:44:15 <ruan_05> ayoung: if you only have one user in a project, you don't need access control
16:44:36 <ayoung> ruan_05, only one user creating the project, but then they provide access to other users
16:44:41 <ayoung> like directories
16:44:57 <ayoung> I'm admin on my projects, you get _memer_
16:44:58 <thinrichs> lbragstad, ayoung: thanks for the background!
16:44:59 <ayoung> member
16:45:19 <ruan_05> in this case, the owner decides who can access which resource
16:45:38 <lbragstad> but we're implying owner because there is only one admin per project
16:45:42 <ayoung> right, but who decides what policy approach they can take?
16:45:45 <ruan_05> if the owner doesn't want to do that, he uses default policy
16:45:52 <lbragstad> owner isn't being implied by the actual resource itself
16:46:00 <ayoung> Is the default policy always the baseline, and then they can "tighten it up" from there?
16:46:26 <ruan_05> ayoung: you can leave this choice to users
16:46:30 <lbragstad> 14 minute mark
16:46:45 <lbragstad> we've got some additional use cases and i'll continue to clarify them with dstanek (and anyone else who is interested)
16:46:50 <ayoung> ruan_05, no you can't, because if a user can change policy on any API, it is an elevation of privs attack
16:47:29 <ayoung> one other possiblity is to do something like "project specific roles"
16:47:38 <ruan_05> when a user creates a project, he can decide whether to use default policy or create his own
16:47:44 <ayoung> ie...a set of roles, or groups, that only apply within a specific project
16:48:03 <ayoung> and you could label resources, and have matching rules between roles and labels
16:48:10 <ayoung> more complex than I really want to get in to
16:48:38 <ruan_05> ayoung: there jobs should be done by project owner
16:49:17 <ayoung> Do we need to run through any of the other use cases explicitly?
16:49:26 <lbragstad> i think that's it
16:49:47 <lbragstad> i encourage everyone to keep thinking about them though
16:49:53 <lbragstad> and revisiting the ones we came up with last wekk
16:49:54 <lbragstad> week*
16:50:29 <lbragstad> sound good?
16:50:58 <lbragstad> i want to give ruan_05 some time to go through the topic he had last week
16:51:18 <lbragstad> i'll push the capabilities topic to next week
16:51:22 <lbragstad> #topic External PDP and PEP hooks in oslo.policy
16:51:24 <lbragstad> ruan_05
16:51:28 <lbragstad> you're up
16:52:04 <ruan_05> we've tried to modify oslo.policy to redirect requests to an external PDP
16:52:22 <ruan_05> it seems work well
16:52:32 <lbragstad> ruan_05 did you base that work on what ktychkova was doing?
16:52:46 <lbragstad> ruan_05 or was this a separate effort?
16:53:07 <ruan_05> yes, the AP review
16:53:37 <lbragstad> so #link https://review.openstack.org/#/c/237521/ specifically
16:53:59 <lbragstad> ruan_05 did you end up getting around the global role problem?
16:54:06 <ruan_05> i think we can provide a general policy "hook" to support external PDP
16:54:51 <ruan_05> in our test, we bypasse the global role
16:55:01 <lbragstad> how so?
16:55:22 <lbragstad> apache fortress treats roles globally across the deployment, right?
16:55:45 <ruan_05> we don't use AF, but another PDP
16:55:50 <lbragstad> oh
16:55:57 <lbragstad> what did you use?
16:56:01 <ruan_05> Moon
16:56:21 <ruan_05> Moon is an attribute-based access control policy engine
16:56:41 <lbragstad> ruan_05 right - did you have to make any additional modifications to the oslo.policy review?
16:56:54 <ruan_05> some slight one
16:57:01 <lbragstad> ruan_05 are they documented anywhere?
16:57:06 <lbragstad> or is there a review?
16:57:44 <ruan_05> no, not yet, we just want to test if https://review.openstack.org/#/c/237521/  can support other PDP
16:58:03 <ruan_05> and we are convinced that https://review.openstack.org/#/c/237521/  is a good approch
16:58:21 <ruan_05> for you information, before, we added the policy hook in Keystonemiddleware
16:58:32 <lbragstad> ruan_05 i'd be curious to see what the changes were and how it worked
16:59:05 <ruan_05> I can send you some code, but not the final version
16:59:25 <lbragstad> ruan_05 posting a review publicly would be nice, that way others can see it and try it out, too
16:59:25 <thinrichs> I'd be interested too
16:59:57 <ruan_05> ok, I'll do it
17:00:07 <lbragstad> ruan_05 cool - i'll document that in the agenda
17:00:29 <lbragstad> that about wraps up our meeting
17:00:30 <lbragstad> thanks for coming!
17:00:33 <lbragstad> if there are additional things to discuss - head over to #openstack-keystone
17:00:36 <lbragstad> #endmeeting