16:00:13 <lbragstad> #startmeeting policy
16:00:14 <openstack> Meeting started Wed Apr 12 16:00:13 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:17 <openstack> The meeting name has been set to 'policy'
16:00:24 <lbragstad> ping  antwash, raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung, ravelar, morgan, raj_singh, johnthetubaguy, knikolla
16:00:26 <knikolla> o/
16:00:35 * johnthetubaguy lurks
16:00:43 <lbragstad> #link https://etherpad.openstack.org/p/keystone-policy-meeting
16:00:45 <lbragstad> agenda ^
16:00:59 <gagehugo> o/
16:01:13 <morgan> sorry, missing this one.
16:01:21 <lbragstad> morgan no worries - thanks for head sup
16:01:27 <lbragstad> heads up, rather
16:02:55 <lbragstad> #topic spec reviews
16:03:04 <lbragstad> #link https://review.openstack.org/#/c/427872/ additional default policy roles spec
16:03:09 <lbragstad> #link https://review.openstack.org/#/c/433037/ policy remove scope checks spec
16:03:18 <lbragstad> #link https://review.openstack.org/#/c/452198/ RBAC in middleware spec
16:03:34 <lbragstad> we cancelled last weeks meeting due to several scheduling issues
16:04:00 <lbragstad> the idea was to review ^ those over the week and talk about them here
16:04:47 <lbragstad> looks like there is still a bit of discussion going on the rbac in middleware approach
16:05:46 <lbragstad> johnthetubaguy ayoung is the main issue with https://review.openstack.org/#/c/427872/ the delegation use case?
16:06:12 <johnthetubaguy> I am not sure its that simple
16:06:15 <lbragstad> which I assume is "As an end user, i want the ability to discover which role is needed for a particular operation I want to delegate"
16:06:29 <johnthetubaguy> see line 346
16:06:41 <johnthetubaguy> in https://review.openstack.org/#/c/427872
16:06:45 <johnthetubaguy> oops
16:06:55 <johnthetubaguy> https://review.openstack.org/#/c/427872/19/specs/pike/approved/additional-default-policy-roles.rst
16:07:17 <johnthetubaguy> I am working under the assumption policy is a per service concern
16:07:34 <lbragstad> johnthetubaguy aha - sure
16:07:34 <johnthetubaguy> the current defaults mean thats no true
16:07:39 <lbragstad> right
16:08:04 <johnthetubaguy> that where this idea came from: https://review.openstack.org/453739
16:08:15 <johnthetubaguy> but none of that gets us closer to delegation
16:08:45 <lbragstad> yeah
16:09:10 <lbragstad> the actual act of delegating isn't too bad since that can be done with oauth or trusts
16:09:27 <lbragstad> the hard part is the inspection piece, finding out which role is needed to do a specific thing
16:09:37 <lbragstad> which according to the NIST RBAC model is level 4 RBAC
16:09:49 <johnthetubaguy> so, API keys are probably more important than delegation
16:09:57 <johnthetubaguy> do we have that work progress at all?
16:10:11 <lbragstad> johnthetubaguy there is a spec in review - but it hasn't been merged yet
16:10:21 <lbragstad> johnthetubaguy and as far as i know, there is no implementation up for review
16:10:26 <johnthetubaguy> OK, wasn't sure on the status
16:10:33 <lbragstad> #link https://review.openstack.org/#/c/450415/
16:10:44 <johnthetubaguy> I think for me, this is all a question of priorities
16:10:50 <lbragstad> sure
16:10:53 <johnthetubaguy> and how we get people productive quickly
16:11:14 <johnthetubaguy> (and how we keep things simple)
16:11:35 <lbragstad> i find that to be paramount
16:11:43 <lbragstad> because this is going to be a long running effort
16:11:56 <johnthetubaguy> my current thinking is an API key to a project that might be a sub project, is maybe good enough for Trove "delegation" and "protection"
16:12:08 <johnthetubaguy> if we get hierarchical quota sorted
16:12:59 <lbragstad> johnthetubaguy you mean by scoping the api key to a specific role?
16:13:22 <johnthetubaguy> not really, specific to a project, on behalf of a user and all their roles
16:13:49 <johnthetubaguy> I am still thinking things through really
16:14:06 <johnthetubaguy> the main thing is trying to get the problem statement straight
16:14:11 <johnthetubaguy> not sure I have got there yet either
16:14:27 <johnthetubaguy> attempted it in here: https://review.openstack.org/#/c/455629
16:14:33 <johnthetubaguy> so going back to my spec
16:14:41 <johnthetubaguy> this one: https://review.openstack.org/#/c/427872
16:14:57 <johnthetubaguy> the main issue I find with alternatives is a lack of smooth transition of the operators
16:15:07 <johnthetubaguy> this seems a nice step wise evolution
16:15:31 <johnthetubaguy> it doesn't fix all the problems folks have, but it does seem to make quite a few operators lives easier
16:15:38 <lbragstad> fwiw - i attempted to graph that approach
16:15:40 <lbragstad> #link https://github.com/lbragstad/orbac
16:15:44 <johnthetubaguy> hopefully we can find a way to get feedback on the relative approach to these things
16:15:52 <johnthetubaguy> I mean priority, not approach
16:16:08 <johnthetubaguy> I remember taking a look at that
16:16:15 <lbragstad> well - introducing more roles is something we can do today
16:16:16 <johnthetubaguy> I wasn't really sure about the contstraints
16:16:48 <johnthetubaguy> lbragstad: I am being told we can't add new roles, even though thats what all the operators are doing today
16:17:04 <johnthetubaguy> at least, it feels like thats what is being said
16:17:07 <lbragstad> the ability to figure out which role is needed for a particular action doesn't exist at all - we'd need to build something to do that
16:17:24 <lbragstad> johnthetubaguy i'm unsure why we can't do that
16:17:33 <johnthetubaguy> well, we have docs for some of that now
16:17:40 <johnthetubaguy> lbragstad: i think its the security concern I linked to
16:17:49 <johnthetubaguy> other than that, I am lost
16:18:05 <lbragstad> oh - where any role on a project allows a person to do things outside that role ?
16:18:25 <lbragstad> i.e. i have the observer role on a project but that doesn't stop me from creating instances
16:18:52 <johnthetubaguy> yeah
16:18:55 <johnthetubaguy> basically
16:18:57 <lbragstad> got it
16:19:06 <lbragstad> so - correct me if I'm wrong
16:19:13 <johnthetubaguy> hence my suggestion of https://review.openstack.org/453739
16:19:15 <lbragstad> but doesn't the service have all theinformation to enforce that today?
16:19:37 <johnthetubaguy> Its not really that
16:19:52 <johnthetubaguy> today if you are in a project, you get access to everything by default
16:20:04 <johnthetubaguy> if every service did some sort of role check, we would be fine
16:20:15 <johnthetubaguy> it has access to all that info, we just have a very unhelpful default
16:20:30 <johnthetubaguy> ... so lets take a step down what I proposed in my spec
16:20:58 <johnthetubaguy> basically have a transitional release, where you log warnings if people don't have the required role, but still give people access by default
16:21:22 <johnthetubaguy> operator can override their policy rule to opt into the new behaviour sooner, if they want that
16:21:32 <johnthetubaguy> not sure if that makes any sense out of context
16:21:39 <lbragstad> this would assume they have other roles in place besides 'admin'
16:22:05 <johnthetubaguy> its all about giving the operator help and time to apply the extra roles that are needed
16:22:30 <johnthetubaguy> if the just use "Member" role for everyone already, it might just be add some implied roles
16:22:46 <lbragstad> something about this feels like a circular dependency
16:23:04 <johnthetubaguy> circular?
16:23:28 <johnthetubaguy> its more there is a transition phase for a cycle where there is pain but little gain
16:23:31 <lbragstad> like - we can't add new roles without changing each project to be deny-all by default, but we can't be deny-all by default without giving operators more roles to use instead of just 'admin'
16:23:38 <johnthetubaguy> release N, everyone has access by default
16:23:54 <dstanek> whoa...not many in here today
16:24:19 <johnthetubaguy> release N+1, people with new role get access, but everyone also gets access but trigger a log message
16:24:32 <johnthetubaguy> release N+2, only people with new role get access
16:24:43 <johnthetubaguy> I think thats my rough proposal
16:25:16 <lbragstad> johnthetubaguy doesn't the require https://review.openstack.org/#/c/427872/ to land before N+1?
16:25:22 <lbragstad> that's what it sounds like to me
16:25:32 <lbragstad> s/the/that/
16:25:34 <johnthetubaguy> not really
16:25:53 <lbragstad> or is it suppose to happen during N+1's cycle?
16:26:03 <johnthetubaguy> right, that is about N+1
16:26:23 <lbragstad> we just have to be able to provide better roles by N+2 is what i'm hearing then
16:26:27 <johnthetubaguy> ideally you would also do https://review.openstack.org/453739 at the same time
16:26:39 <johnthetubaguy> right, you have a transition
16:26:54 <johnthetubaguy> you have a release of nothing is better, to help people transition
16:27:31 <dstanek> johnthetubaguy: how granular do you think roles will go?
16:27:36 <lbragstad> so - by the time N+2 rolls around, operators should have a bunch of new roles that they can assign to people that correct part of the issue because each service should now be deny-all by default
16:27:53 <johnthetubaguy> dstanek: initially, I am just talking about getting to no access by default
16:28:32 <johnthetubaguy> dstanek: read, read/write, admin seems a sensible split to add in any first pass
16:28:41 <johnthetubaguy> lbragstad: they can assign them during N+1
16:29:05 <lbragstad> johnthetubaguy so when they upgrade to N+2 users shouldn't notice any sort of breakage
16:29:15 <johnthetubaguy> lbragstad: rather, they have to assign the roles to the existing users during N+1, so everything works after upgrading to N+2
16:29:22 <johnthetubaguy> lbragstad: thats it, yeah
16:29:26 <dstanek> johnthetubaguy: do you plan to go as deep as vm_rebooter, catalog_endpoint_changer, etc?
16:29:33 <lbragstad> ok - that makes sense
16:29:48 <johnthetubaguy> dstanek: I am trying to ignore all that for now, just get to a happy place where such things are possible
16:30:11 <johnthetubaguy> dstanek: we give operators the ability to create all of those, but its not in the default, basically
16:30:33 <lbragstad> johnthetubaguy is that going to pan out with interoperability though?
16:30:42 <dstanek> johnthetubaguy: i'm trying to figure out the end goal of all of this.
16:30:46 <johnthetubaguy> lbragstad: which bit?
16:31:02 <lbragstad> johnthetubaguy one deployment implements reader and another implements observer, for example
16:31:08 <dstanek> and then i want to poke at it for potentially how it might work
16:31:12 <johnthetubaguy> dstanek: the end goal I am taking about here, is letting users modify policy without breaking everything
16:31:42 <johnthetubaguy> lbragstad: ah, thats where the capabilities API comes into play slightly
16:31:45 <lbragstad> dstanek the big thing i think we're talking about here, right now, is making it so that if you have a role on the project you don't access to all the things
16:32:13 <johnthetubaguy> lbragstad: at least we have standard error codes for permission denied due to policy
16:32:23 <lbragstad> dstanek (i.e. I have the 'observer' role on project 'Foo' but that doesn't actually stop me from launching instance)
16:32:29 <johnthetubaguy> lbragstad: true, thats the big one
16:32:35 <dstanek> lbragstad: sure, i'm trying to see who it fits in the bigger picture (assuming that we have one)
16:32:51 <johnthetubaguy> I am thinking really small here, on purpose
16:33:14 <johnthetubaguy> lets get stuff into a state where folks can innovate and tell us what is best to have as upstream defaults
16:33:23 <lbragstad> johnthetubaguy is it fair to say that the main thing we're discussing here is closing that security hole?
16:33:41 <johnthetubaguy> yeah, I think it probably is
16:33:52 <ayoung> Whoa...I need to read up....
16:33:56 <johnthetubaguy> but fixing that allows folks to "understand" policy I guess
16:34:04 <lbragstad> dstanek do you think that sounds like a fair starting point, or do we need to back up further?
16:34:44 <ayoung> " I am working under the assumption policy is a per service concern"  very no.   ...more as I catch up
16:35:13 <ayoung> the only way that could be true is if a token were issued for a specific service, and invalid for other services
16:35:31 <johnthetubaguy> ayoung: I think that was me saying "I was"
16:35:41 <ayoung> johnthetubaguy, ah
16:35:43 <ayoung> cool
16:35:51 <ayoung> johnthetubaguy, so you no longer see it like that, I take it?
16:36:40 <johnthetubaguy> ayoung: yes, but probably not in the way you want to me to
16:37:23 <ayoung> johnthetubaguy, that is ok, it took me a long time to get to where I am in my opinions.  THe fact that you are following me at least thus far is, frankly, more than most people
16:38:00 <ayoung> johnthetubaguy, lets start with the term delegation.  To me, Keystone is a Delegation service, not an identity service
16:38:37 <dstanek> lbragstad: it sounds like a good middle step....but i'm curious to know what the vision is.... some of ayoung's proposals have high level thoughts on where we should be heading
16:38:39 <ayoung> a token is a way of saying "I need a delegation agreement so some service can do something on my behalf"
16:38:46 <johnthetubaguy> ayoung: yeah, thats fair, especially in the LDAP case
16:39:18 <lbragstad> dstanek ++
16:39:27 <ayoung> so, delegation is a way to make operations scale
16:39:40 <ayoung> if I have to do everything manually myself, I can only handle so much
16:39:51 <dstanek> i can't formulate an opinion on whether or not we are on the right path if we don't have a concrete destination (like Seatle) or even a general location (like Southern Cal)
16:40:05 <ayoung> If I can get some other service to do stuff for me with my resources, I can get more done
16:40:06 <johnthetubaguy> ayoung: +1 that, the hierarchical quota stuff is all about exactly that
16:41:10 <ayoung> so, a role in Openstack is a label that maps to "permission to perform a set of operations"  for a specific scope.  I'll use the term project for scope, as only Keystone uses domains
16:41:54 <ayoung> Someone was thinking this way all-the-way-back to the pre-Keystonelight  code base
16:42:10 <ayoung> cuz termie pulled in "role is on a tenant" even back then
16:42:25 <ayoung> however, they coded as if roles were global
16:42:30 <ayoung> thus, admin everywhere
16:42:37 <ayoung> the only role they actually knew about
16:42:38 <johnthetubaguy> yeah, role is for a given user on a particular project scope
16:43:00 <ayoung> So, that is the first thing to fix.  Bug 968696
16:43:02 <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:43:23 <johnthetubaguy> thats fair, I think thats the spec I am pushing in Nova to get merged, effectively
16:43:43 <ayoung> johnthetubaguy, I have a patch for it
16:43:48 <lbragstad> https://chickenfriedbuffalo.files.wordpress.com/2014/03/keystone-light-keith-stone1.jpg
16:44:04 <johnthetubaguy> ayoung: yeah, I need to go look at that again now
16:44:05 <ayoung> https://review.openstack.org/#/c/384148/
16:44:30 <ayoung> johnthetubaguy, and getting that patch and fix through is what convinced me that, if we depend on getting a change through all the services, we are sunk
16:45:03 <johnthetubaguy> the problem there is not one really understands that patch or policy
16:45:04 <ayoung> johnthetubaguy, the situation in the keystone code base is actually worse
16:45:30 <ayoung> I have 2 patches as a pre-req to the Keystone one, and they are both, once again, in need of a rebase
16:45:49 <ayoung> And, let me be clear, I consider this a CVE level security hole.
16:45:57 <ayoung> THe only reason it is not a CVE is that everyone knows about it
16:46:12 <johnthetubaguy> well, for some, its a feature
16:46:16 <ayoung> but I really would like it if the entire OpenStack community were to treat that as if the house were on fire
16:46:44 <ayoung> OK, so, next step
16:46:47 <ayoung> delegation
16:46:58 <johnthetubaguy> so... I think we are skipping a bit
16:47:15 <johnthetubaguy> today people modify policy.json to give people subsets of stuff
16:47:25 <ayoung> I got my first lesson on Delegation when the Heat people asked me about it ... in Dublin, so, it must have been 4 years ago
16:47:49 <ayoung> The Trust API was my first attempt at it, and it has stood up, meh, over time
16:47:57 <ayoung> but a trust is a delegation agreement
16:48:08 <ayoung> as is a role assignment, when you think about it
16:48:13 <ayoung> and we did think about it
16:48:20 <ayoung> and thus, the unified delegation effort...
16:48:23 <ayoung> which I can link to
16:48:42 <ayoung> There is a commonality to my rantings here
16:48:52 <ayoung> they all are driven off the same core principals
16:49:06 <ayoung> "delegate the minimal amount to perform the operation"
16:49:10 <ayoung> least principal
16:49:24 <ayoung> er
16:49:32 <lbragstad> PofLP
16:49:36 <ayoung> least privilege principal
16:49:38 <ayoung> yep
16:49:55 <ayoung> Pronounce PoffUlp, I believe
16:50:09 <johnthetubaguy> right, its something that gets most people nodding, the problem we have is usability and transitioning to it
16:50:16 <ayoung> right
16:50:18 <ayoung> very right
16:50:23 <ayoung> and transition is ultra important
16:50:31 <lbragstad> 10 minutes remaining
16:50:33 <ayoung> we can't break the existing way of doing things
16:50:43 <ayoung> ok...this is why I want to do this in a video conf...
16:50:45 <lbragstad> *without* a transition period
16:50:55 <ayoung> too much to say, and hard to do on IRC
16:51:07 <lbragstad> ayoung you're doing well
16:51:12 <ayoung> so....can we agree to video conf next week?
16:51:14 <johnthetubaguy> ayoung: +1
16:51:18 <lbragstad> yes
16:51:36 <johnthetubaguy> that +1 actually applies to its hard to do on IRC, and lets do a video conf next week
16:51:42 <ayoung> johnthetubaguy, would love to have you there.  Probably the most important person, right now, as you are the nova person taking point on this
16:51:43 <lbragstad> johnthetubaguy dstanek gagehugo lamt ayoung knikolla have all confirmed attendance
16:51:49 <ayoung> excellent
16:52:13 <ayoung> I'll try to be organized and concise, so I don't take too much time, and we can have a decent discussion
16:52:13 <lbragstad> which is under 10, which means we can use Google Hangouts
16:52:20 <johnthetubaguy> actually, what about this slot next week?
16:52:27 <johnthetubaguy> to keep it simple
16:52:30 <lbragstad> yep
16:52:32 <ayoung> johnthetubaguy, btw, some other related efforts you should know about
16:52:36 <knikolla> works for me
16:52:40 <lbragstad> that's what ayoung suggested in the thread
16:52:45 <ayoung> 1.  "Request a token with a specific role"
16:52:48 <johnthetubaguy> ah, I missed that bit
16:53:03 <edmondsw> I will try to make it if someone will send me the information
16:53:04 <ayoung> this is the idea that, when I ask Nova to reboot a VM, I get a token that can only do that
16:53:14 <lbragstad> edmondsw ++ i'll add you to the thread
16:53:25 <lbragstad> edmondsw want to ping me your preferred email?
16:53:28 <ayoung> https://review.openstack.org/#/c/186979/
16:53:54 <ayoung> johnthetubaguy, the trove example you brought up is a superb starting point
16:54:17 <johnthetubaguy> do we want to talk API Keys
16:54:26 <johnthetubaguy> I think thats very relevant here
16:54:29 <ayoung> if you think of Trove, Sahara, or anything else that makes use of existing OS services as a semi-trusted third-party resource, it makes a lot of sense
16:54:41 <ayoung> johnthetubaguy, an API key, as I see it, is 2 things
16:54:44 <ayoung> 1. An identity
16:54:52 <johnthetubaguy> ayoung: +1 the trove statement
16:54:52 <ayoung> 2. a delegation agreement
16:55:11 <lbragstad> quick note before we end the meeting - i'd like to have some idea of the goals we want to accomplish next week
16:55:12 <ayoung> they really are a way to do lightweight user-like objects
16:55:41 <ayoung> lbragstad, should we use the etherpad to frame the agenda?
16:55:42 <lbragstad> i just don't want to get lost in conversation without working towards something
16:56:01 <lbragstad> ayoung yeah - that's eventually what I was going to do
16:56:08 <ayoung> link?
16:56:24 * lbragstad #link https://etherpad.openstack.org/p/policy-chat-session-one
16:56:44 <lbragstad> let's keep the goals short - since we've only got an hour
16:57:15 <lbragstad> I want to make sure we come out of the meeting with something accomplished, and having known goals before hand should help us with that
16:58:32 <johnthetubaguy> so... there is an interesting option about a release goal for queens
16:58:55 <johnthetubaguy> some quick fixes projects can do in a single cycle, so we are less... broken
16:59:05 <johnthetubaguy> how could that get packaged into a release goal for queens
16:59:26 <ayoung> johnthetubaguy, analogs of Bug 968696
16:59:29 <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:59:41 <ayoung> check is_admin_project in policy for every project
16:59:47 <lbragstad> i like the idea of using release goals to encourage adoption of what we end up moving towards
16:59:56 <edmondsw> ++
16:59:57 <ayoung> Get someone to take that per project and run it through to completion
17:00:04 <johnthetubaguy> ayoung: yeah, I think closed by default as well
17:00:12 <lbragstad> johnthetubaguy ++
17:00:21 <johnthetubaguy> well, all the projects have to commit or not, basically
17:00:42 <johnthetubaguy> ideally a few projects have examples, maybe just WIP, to frame the discussion
17:00:45 <lbragstad> alright - we're out of time
17:00:54 <lbragstad> we can spill over into -keystone or -dev
17:00:54 <johnthetubaguy> doh, yep
17:00:58 <lbragstad> -dev?
17:01:09 <lbragstad> #endmeeting