16:01:39 <lbragstad> #startmeeting policy
16:01:40 <openstack> Meeting started Wed May 24 16:01:39 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:44 <openstack> The meeting name has been set to 'policy'
16:01:47 <knikolla> o/
16:01:49 <lbragstad> ping raildo, ktychkova, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung, morgan, raj_singh, johnthetubaguy, knikolla, nhelgeson
16:01:51 <lbragstad> o/
16:01:53 <blancos> o/
16:01:53 <hrybacki> o/
16:01:59 <gagehugo> o/
16:02:01 <lbragstad> #link https://etherpad.openstack.org/p/keystone-policy-meeting
16:02:04 <lbragstad> agenda^
16:02:05 <nhelgeson> o/
16:02:09 <ayoung> hrybacki, too!
16:03:15 <ayoung> lbragstad, I took the liberty of copuying most of last weeks agenda forward.  take a look and please OK/object
16:03:32 <ayoung> we got through so little last week
16:04:23 <lamt> o/
16:04:38 <felipemonteiro> o/
16:05:07 <ayoung> From the previous discussions, it sounds like getting a solution to Admin-everywhere is highest priority
16:05:25 <ayoung> as  such, I wrote up an explanation in the plainest terms I could muster
16:05:27 <lbragstad> look like this weeks agenda is a copy/paste of last weeks
16:05:39 <ayoung> #link http://adam.younglogic.com/2017/05/fixing-bug-96869/
16:05:49 <lbragstad> had a blip there with my network connection
16:05:58 <ayoung> lbragstad, yep, it is.  We spent all of last week on the Goals doc
16:06:11 <ayoung> I wanted to hit some more tactical stuff before we get back into that
16:06:14 <ayoung> OK with you?
16:06:26 <gagehugo> fixing-bug-968696 was a good read
16:06:36 <ayoung> gagehugo, TYVM
16:06:49 <edmondsw> o/
16:06:50 <lbragstad> ayoung: do you mind if we start with http://lists.openstack.org/pipermail/openstack-dev/2017-May/117419.html
16:06:59 <ayoung> If you have not read it, please do so.  It should help make clearer what we are trying to do.
16:07:00 <lbragstad> ?
16:07:06 <ayoung> #link  http://lists.openstack.org/pipermail/openstack-dev/2017-May/117419.html
16:07:14 <lbragstad> thanks
16:07:59 <hrybacki> gagehugo++
16:08:11 <ayoung> lbragstad, So, regardless of is_admin_project vs global roles, the policy will need to be enforced in the remote services.  It think my write up still applies, with minor modifications
16:08:20 <ayoung> lets talk global roles for a moment, though
16:08:22 <lbragstad> ayoung: absolutely
16:08:33 <ayoung> Kubernetes has a similar concept; Roles vs ClusterRoles
16:08:45 <ayoung> a ClusterRole is not scoped to a namespace
16:08:54 <ayoung> k8s is kubernetes for short
16:09:01 <ayoung> namespace is kindof what k8s calls a project
16:09:22 <ayoung> one thing about having them separate is they could go into the same token response
16:09:51 <ayoung> lest say we call ours GLobalROles or CLusterRole or whatever, we could have a new section in the token validation response that enumerates them
16:10:05 <lbragstad> #link https://youtu.be/WvnXemaYQ50?t=19m39s
16:10:10 <ayoung> role assignments for global roles would be on a global target
16:10:45 <ayoung> good link...but a little long for this meeting. Suggest people watch wjhen they have time
16:10:49 <edmondsw> ayoung to be honest I wasn't super impressed with what k8s has... better than what we have currently, but not as good as what we've been discussing as our future
16:11:06 <ayoung> edmondsw, fair enough.  I'm just learning it myself
16:11:28 <lbragstad> sure - for folks who want to get an idea of what k8s has for policy and contrast it to what we do today - that link might help
16:11:30 <ayoung> so, assuming we got with global roles, the steps we'd need would be something like this:
16:11:38 <ayoung> 1. DEFINE the api for them
16:11:51 <lbragstad> #topic global roles
16:11:54 <ayoung> 2. Add global roles GR for short
16:12:03 <ayoung> 2. Add global roles to token validation response
16:12:14 <ayoung> 3. Add global roles to oslo-context
16:12:23 <ayoung> 4. enforce policy on Global roles
16:12:42 <ayoung> note that this will break exisiting deployments if we do not provide a transition scheme
16:12:55 <ayoung> ie. no one will have any global roles defined, nor any users with them
16:13:28 <ayoung> Thus, we'd probably have to adopt the same approach we did with is_admin_project:
16:13:54 <ayoung> start by making all admin role assignments into GlobalRoles until some switch is set
16:14:17 <ayoung> otherwise, we end up rewriting policy files twice, and that will be a disaster
16:14:32 <ayoung> we want to touch nova once and only once and be done with it
16:14:37 <edmondsw> ayoung it sounds like you're suggesting we have global roles
16:14:41 <ayoung> edmondsw, no
16:14:55 <ayoung> edmondsw, I'm suggesting I've thought through what it would take to implement them
16:14:56 <edmondsw> what we've been discussing is roles that could be scoped either locally or globally
16:15:06 <ayoung> and I want people to be aware of the pain involved
16:15:12 <edmondsw> not global roles vs. local roles... roles, period
16:15:17 <edmondsw> and scoping is separate
16:15:34 <edmondsw> scoping comes in with how you make the assignment
16:15:42 <ayoung> edmondsw, ok...so let me address that
16:15:47 <edmondsw> goes back to my "we can do better than k8s" comment
16:16:03 <ayoung> right now, a token is either scoped or unscoped.  Unscoped tokens are not currrently usable outside of keystone
16:16:30 <ayoung> we could, if we want, use unscoped tokens to do global roles, and put them in the roles field.
16:16:36 <ayoung> what that would then do with policy is this
16:16:45 <edmondsw> no
16:16:55 <edmondsw> we already had this discussion and said no to that
16:17:00 <ayoung> we'd have two stanzas, one that checked the role for scoped, one that checks the role for unscoped
16:17:06 <edmondsw> unscoped != global scoped
16:17:15 <ayoung> edmondsw, which is why I was using a different name for them: GR versus Role
16:17:20 <edmondsw> unscoped is the empty set, global scoped is the universal set
16:17:30 <lbragstad> ++
16:17:32 <ayoung> edmondsw, or we explicitly request a token with global scoping, yes
16:17:34 <edmondsw> it's not different types of roles, though... it's roles + scope
16:17:58 <lbragstad> i would agree but i'd also expect operators/deployers to confirm that
16:18:08 <ayoung> regardless, the policy file needs to have a different check for a globally scoped role than for a project scoped role
16:18:32 <edmondsw> ayoung no, scope checks should be in code, not policy
16:18:40 <ayoung> edmondsw, stop
16:18:46 <ayoung> edmondsw, you are being argumentative.
16:18:48 <ayoung> I know that
16:18:54 <ayoung> please don't be pedantic
16:19:01 <edmondsw> ayoung ha! pot calling the kettle... ;)
16:19:01 <ayoung> I am talking about from where we are today
16:19:31 <ayoung> edmondsw, policy file is the reality on every service.  Nova and Keystone have the policy-file-less approach
16:19:46 <ayoung> I'm not going to tell Neutron it needs to adopt it
16:19:53 <edmondsw> I thought we already agreed that fixing 968696 will involve doing scope checks in code
16:20:05 <ayoung> edmondsw, for Keystone and Nova, yes
16:20:19 <ayoung> edmondsw, for the other projects, I am not willing to rewrite them to that level
16:20:30 <edmondsw> I'm not sure you can fix this without doing so
16:20:35 <ayoung> I think that decision can be taken up by whomever choses to fix the bug on those systems
16:20:43 <edmondsw> stronger than that... I'm pretty sure you can't
16:20:49 <edmondsw> sure
16:21:43 <ayoung> edmondsw, so, I don't think there is anything we need to do in python code that you cannot do in the policy.json file today.  Just that modifications have a greater probility of breaking things
16:21:59 <ayoung> glance and neutron and cinder can all be fixed in their default policy files for the first step
16:22:15 <ayoung> if they go to scope check in code, they should then inherit the fix
16:22:53 <ayoung> which is an argument against an explicit GLobalROle change.  Policy is in flux, and we will soon have python code enforcing the bug effect
16:23:01 <ayoung> I'd like to get the fix through as fast as possible
16:23:31 <ayoung> changing from is_admin_project to GlobalRoles will delay that, and confuse the message, even if the term is the better term
16:24:20 <ayoung> is_admin_project can be seen as an implementation of global roles using exisint mechanisms.  It exposes a low level detail that GR does not.
16:24:43 <lbragstad> i think having operator or deployer input would be valuable
16:25:01 <lbragstad> because we can implement global role assignments via project scoping
16:26:19 <ayoung> So, if fixing 968696 is the highest priority, I am going to suggest we not change the mechanism we are using to solve it
16:27:09 <ayoung> because it will push back the fix by a good bit...we are too late for Pike as it is,  Which means it won't go uin until queens, and then the fix for the other projects backs up behind that
16:27:16 <edmondsw> ayoung I don't see any reason we can't do both in parallel
16:27:18 <ayoung> R if we are really lucky
16:27:28 <ayoung> edmondsw, sure
16:27:39 <ayoung> edmondsw, I'm ok with that, so long as we prioritize 968696
16:27:54 <ayoung> And with that, I would like to find out who is actually planning on workin on this
16:28:02 <ayoung> right now I know of gagehugo actively writing code
16:28:18 <ayoung> is anyone else willing to work on the fixes for any of the other services?
16:28:49 <hrybacki> I am willing to dedicate some cycles to the cause
16:28:54 <ayoung> hrybacki, excellent
16:29:07 <ayoung> hrybacki, we have need for fixes in
16:29:21 <ayoung> Neutron and Cinder from scratch
16:29:34 <ayoung> there is a half-kiestered fix in for glance
16:29:43 <ayoung> gagehugo is tackling nova
16:29:49 <hrybacki> gagehugo++
16:29:54 <ayoung> and I think was flagged to take the keystone changes too
16:30:15 <gagehugo> ayoung yeah I was looking at what we might need to do for tempest
16:30:19 <hrybacki> ayoung: would that mean he is taking over some of the patches you've already got up or something completely new?
16:30:41 <gagehugo> hrybacki was using ayoungs patches
16:30:42 <hrybacki> don't mean to de-rail -- I'm happy to help with some guidance (as this clearly has a lot of history)
16:30:47 <ayoung> hrybacki, all submitted patches are linked to from the etherpad
16:30:55 <hrybacki> ack
16:31:03 <ayoung> hrybacki, this is not derailing.  The is re-railing
16:31:17 <lbragstad> i think we need more operator and deployer feedback for the global role or is_admin_project approach
16:31:27 <ayoung> lbragstad, go for it, but don't hold this up
16:31:37 <ayoung> I really don;'t think they will care
16:31:45 <ayoung> RBAC is something that most people ignore until it bites them
16:31:56 <ayoung> if we document what we are doing, they will get the same end result
16:32:14 <edmondsw> this operator cares and wants global roles... trying to explain is_admin_project is a mess
16:32:14 <ayoung> and, if we go in parallel, we can roll this fix in to global roles without hurting them
16:32:28 <ayoung> edmondsw, it was your idea
16:32:31 <edmondsw> I'll do it while I have to, but we need to get that replaced with global roles
16:32:39 <edmondsw> ayoung sort of
16:33:02 <lbragstad> if we want to do this in parallel - then we should change the is_admin_project bits
16:33:02 <hrybacki> do we have a plan for getting more operator feedback?
16:33:03 <edmondsw> ayoung and that was just to implement a quick fix... 18 months later we still don't have a fix
16:33:15 <edmondsw> it was never to be a permanent solution
16:33:33 <lbragstad> hrybacki: #link http://lists.openstack.org/pipermail/openstack-dev/2017-May/117419.html
16:33:50 <hrybacki> thanks lbragstad
16:33:50 <ayoung> yep
16:34:11 <lbragstad> hrybacki: no problem
16:34:22 <ayoung> So, go write up the global roles spec
16:34:33 <ayoung> get the code started in keystone, including the transition plan
16:34:36 <lbragstad> #link https://review.openstack.org/#/c/464763/8/specs/keystone/ongoing/global-roles.rst
16:35:00 <edmondsw> lbragstad that email was sent to the dev ML... what about the operator ML?
16:35:54 <lbragstad> edmondsw: #link http://lists.openstack.org/pipermail/openstack-operators/2017-May/013547.html
16:36:09 <lbragstad> edmondsw: i sent it to the operator and dev lists
16:36:22 <edmondsw> lbragstad great, tx
16:38:23 <ayoung> are you serious about doing it in parallel, or do you want to prioritize global roles over is_admin_project for the fix?
16:38:36 <lbragstad> edmondsw: no problem
16:39:20 <lbragstad> ayoung: I'm serious about getting the feedback - because I think it is important
16:39:44 <ayoung> lbragstad, are you putting a hold on the is_admin_project fixes until we get that feed back?
16:41:35 <lbragstad> i don't want to implement is_admin_project fixes only to have operator migrate to global roles
16:41:46 <lbragstad> operators*
16:41:55 <lbragstad> that seems like a lot of work
16:42:02 <lbragstad> which is why i'm asking for feedback
16:42:56 <ayoung> lbragstad, a lot of work has been done already
16:43:15 <ayoung> are you telling me you want to throw that out>
16:43:36 <lbragstad> ayoung: no - i'm not saying we need to throw it out
16:43:39 <ayoung> and if so, I would like to point out that the time to have this discussion should have been when that idea was floated
16:44:46 <ayoung> And when those specs were posted, and approaved. And implemented.
16:45:40 <lbragstad> ayoung: i'd like to get buy in from operators that they are ok migrating an approach for global roles
16:45:48 <lbragstad> twice
16:46:17 <ayoung> This is a long, multi-project effort. Having it reset this late in the process due to a name change is a waste
16:46:55 <lbragstad> it's not a naming change - it's a structural change for elevated privileges in my opinion
16:47:03 <ayoung> So, I want to know who is committing to see this through
16:47:10 <ayoung> its a name change
16:47:16 <ayoung> is_admin_project to global
16:48:02 <ayoung> operators want a read-only role
16:48:11 <ayoung> this is holding that up
16:48:29 <ayoung> because we've prioritize 968696 over that
16:48:53 <ayoung> you are doing the operators no favors here.
16:49:54 <ayoung> so, are you willing to derail the is_admin_project fix, and further postpone RBAC in middleware, to change is_admin_project to global?
16:50:02 <ayoung> And if so, who is going to pay for it?
16:50:05 <samueldmq> isn't global related to 968696?
16:50:19 <ayoung> samueldmq, its another way to get there, but longer
16:50:19 <samueldmq> I thought it was a way to keep allowing what is possible today: global scope
16:50:43 <ayoung> it is, but it needs to be implemented
16:50:55 <ayoung> and we went through the comparable pain already for is_admin_project
16:51:26 <samueldmq> so the question is use is_admin_project to allow global roles
16:51:37 <samueldmq> or implement global roles as proposed in lbragstad's spec
16:51:39 <samueldmq> correct?
16:51:45 <ayoung> samueldmq, sort of
16:52:01 <samueldmq> okay, would it be useful to get input from other projects too?
16:52:18 <ayoung> the question is whether to wait on fixing 968696 in the remote services used the global scope proposed, or to fix it now with the implemented mechanisms
16:52:28 <samueldmq> I still need to look at global roles spec myself, I understand your proposal, fully got your blog post
16:52:36 <ayoung> I;'d say it would be useful to stop waste time and effort and just fix the damn thing
16:53:28 <samueldmq> how do global role (or is_admin_project) go with the current idea for migrating scope checks to the code?
16:53:44 <samueldmq> do we plan to add that in the files for now, then migrate them to the code later?
16:53:53 <ayoung> the check needs to be done regardless
16:53:59 <samueldmq> agreed
16:54:06 <samueldmq> my question is what's the plan on the check
16:54:12 <ayoung> if we do it in code, we have the more flexible language of Python to implement
16:54:20 <samueldmq> we put them on the files for now, and they will go to code once the rest goes too?
16:54:27 * samueldmq nods
16:54:42 <ayoung> that realyl only matters for advance cases, like domain vs project vs global scoped tokens for creating projects
16:55:34 <samueldmq> yeah and I guess the answer to that will depend on how fast we can advance on 968696 and how fast migrating scopes to code is gonna take
16:55:37 <ayoung> So, I have hrybacki and gagehugo that are planning on writing code using the existing mechanisms
16:55:44 <samueldmq> I was just checking we were in the same page
16:55:51 <ayoung> for nova, the review is submitted
16:56:17 <ayoung> for Keystone, its been kicked back and needs a little more work, but what is needed is in place
16:56:18 <samueldmq> that's good to see we have resources to work on this front
16:56:35 <ayoung> samueldmq, I cannot work on this myself any more
16:56:53 <samueldmq> ok, I will review the global roles approach too, before that I can say anything :(
16:56:54 <ayoung> so if we are going a different direction, someone needs to own that, and understand the real costs
16:57:04 <samueldmq> but I got your proposal and I understand it solves the issue
16:57:12 * samueldmq nods
16:57:14 <ayoung> including the hacks we've had to do to provide a forward compatable solution
16:57:35 <ayoung> a global scope is going to have to map to something people have now, or we are going to have to dual check or something
16:57:36 <edmondsw> samueldmq we can't fix this in the policy files without adding a bunch of new policy checks, so it's easier (and what we want anyway) to just do scope checks in the code to start with
16:57:43 <ayoung> which is why we went with is_admin_project
16:58:01 <ayoung> edmondsw, for Keystone
16:58:09 <ayoung> edmondsw, not for glance, cinder, or neutron
16:58:13 <edmondsw> ayoung not only for keystone
16:58:25 <ayoung> edmondsw, and we already fixed the pyhthon code for nova
16:58:25 <samueldmq> edmondsw: I get that, that's where my question on what we do now and how we address the to-code migration
16:58:44 <samueldmq> FYI we're almost out of time
16:58:44 <ayoung> ASnd we are out of time
16:59:13 <ayoung> and we did not discuss the RBAC in middleware, because we were once again derailed.
16:59:23 <hrybacki> :(
16:59:35 <edmondsw> ayoung you dominated the conversation, so you can't blame anyone else on that ;)
17:00:31 <samueldmq> #endmeeting
17:00:33 <lbragstad> #endmeeting