16:00:08 <lbragstad> #startmeeting policy
16:00:09 <openstack> Meeting started Wed Sep  6 16:00:08 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:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:13 <openstack> The meeting name has been set to 'policy'
16:00:20 <lbragstad> #link https://etherpad.openstack.org/p/keystone-policy-meeting
16:00:22 <lbragstad> agenda ^
16:00:38 <lbragstad> it's a little light today - but i assume everyone is getting ready for the ptg or wrapping other things up
16:01:08 <lbragstad> #topic policy-and-docs-in-code community goal
16:01:16 <lbragstad> quick update here
16:01:29 <blancos> o/
16:01:29 <lbragstad> I spent yesterday working through the projects that don't appear to be impacted by the goal
16:01:45 <ayoung> What guidance are we providing with regard to role names to projects that are doing this?
16:01:49 <lbragstad> and i proposed patches to governance to update those accordingly
16:02:09 <lbragstad> ayoung: we're not - we're just ensuring they move what they have in code
16:02:22 <lbragstad> we not requiring renames or refactoring
16:02:34 <ayoung> Does that mean the role enforcement will be in code?
16:02:35 <lbragstad> but.. that's a good question
16:02:39 <ayoung> admin?
16:03:11 <lbragstad> role enforcement will be done by the oslo.policy enforce object, like it always has
16:03:20 <ayoung> It would be best if they could tag an API as "admin" without hardcoding what that means
16:03:36 <lbragstad> yeah
16:03:39 <lbragstad> i also have these
16:03:41 <lbragstad> #link https://review.openstack.org/#/c/500141/
16:03:46 <lbragstad> #link https://review.openstack.org/#/c/500207/
16:03:58 <ayoung> something like "default the admin_required rule to mean role:admin"  but not codify that on each line of the policy enforcement
16:04:23 <lbragstad> that seems specifically related to https://review.openstack.org/#/c/500141/
16:04:52 <ayoung> They should be able to add a single rule, even maybe in a config file, that specifies just how to do admin at both cloud and project scope
16:05:06 <edmondsw> o/
16:06:28 <ayoung> Actually, that would be a really valuable first step;  each of the projects should identify on a per-api basis which of scope of admin they mean: global or project scoped
16:06:37 <lbragstad> yeah
16:06:48 <ayoung> even if the default implementation does not distinguish, lets future proof them at that level
16:06:49 <lbragstad> i completely agree
16:06:55 <edmondsw> with global roles, scope is no longer a policy thing at all
16:07:30 <lbragstad> ayoung: you're talking about https://review.openstack.org/#/c/500207/1/specs/queens/include-scope-in-policy.rst right?
16:07:41 <ayoung> I tjhink so...loooking
16:08:03 <lbragstad> yeah - it'd be awesome to get that functionality into oslo this release somehow
16:08:16 <lbragstad> that way projects that have policy in code can start implementing it
16:08:19 * edmondsw adds that to his reading list
16:08:31 <lbragstad> edmondsw: #link https://review.openstack.org/#/c/500141/ too
16:08:35 <ayoung> edmondsw, lets use the terminology that Global IS a scope.
16:08:57 <ayoung> or Cloud or even service scope, to distinguish from project scope
16:09:11 <lbragstad> something elevated above project
16:09:12 <edmondsw> definitely
16:09:33 <ayoung> the only operations we consider "unscoped" are on the Keystone server itself. And unscoped token should not be accepted by a remote service
16:09:42 <lbragstad> right
16:09:44 <ayoung> and an unscoped token should probable not have global roles on it
16:09:44 <edmondsw> agreed
16:09:51 <ayoung> but that is getting ahead of the discussion
16:10:10 <edmondsw> unscoped tokens shouldn't have roles or any kind
16:10:16 <edmondsw> s/or/of/
16:10:33 <ayoung> Cool.  So we will talk about tokens scoped to one of three things:  domain, project, or global?
16:10:42 <edmondsw> yep
16:10:54 <ayoung> cool.  please continue lbragstad
16:11:06 <lbragstad> correct - the piece that the oslo spec helps projects align operations with those scopes
16:11:18 <lbragstad> helps with*
16:11:58 <lbragstad> so - if anyone has feedback on either of those oslo specs, i'd love to hear it
16:12:12 <lbragstad> we're also on the schedule to visit with the oslo folks at the ptg about it
16:12:16 <ayoung> can we provide example rules in them?
16:12:33 <lbragstad> #link https://etherpad.openstack.org/p/oslo-ptg-queens
16:12:42 <ayoung> and we should probably standardize what we mean by "owner"
16:13:01 <edmondsw> I like the use cases for include-scope-in-policy at any rate... will read more later
16:13:16 <lbragstad> i would imagine that to be a conversations with a larger group, just to make sure we level set on consistent terms and don't assume owner means the same thing everywhere
16:13:39 <edmondsw> "owner" definitely doesn't mean the same thing everywhere :)
16:13:40 <lbragstad> i'd need to dig into other projects and how they use owner
16:13:46 <ayoung> we should also encourage them to not have ADMIN_OR... in the rule names, as admin is an override, and should be able to do anything.
16:13:58 <edmondsw> ++
16:14:00 <lbragstad> or i can just take edmondsw's word for it :)
16:14:21 <ayoung> I would suspect that for most places they use "owner" to mean "member of project with write permissions"
16:14:25 <edmondsw> in some places owner is a user, in others it's a project
16:14:25 <lbragstad> so - really quick on the policy in code stuff/communtiy goal
16:14:42 <lbragstad> it also built a version of dhellmann's burndown chart to track that work
16:14:44 <lbragstad> #link https://www.lbragstad.com/policy-burndown/
16:14:45 <edmondsw> ayoung drop the "with write permissions"
16:15:14 <lbragstad> that should publish new results twice a day
16:15:36 <ayoung> edmondsw, I would actually like it if they distinguished at the API level whether read/write is expected
16:15:40 <hrybacki> lbragstad++
16:15:47 <ayoung> I think that is the heart of what you mean?
16:16:00 <ayoung> Member implies Write and Read
16:16:38 <edmondsw> ayoung I just meant that "owner" is sometimes used for read as well as write, I believe... nothing really write-specific about it
16:16:47 <ayoung> yeah, I figured that is what you meant
16:17:19 <ayoung> I tend to think of permissions in a DAG, so write kindof implies read, but Member definintely implies read and write
16:17:44 <edmondsw> ayoung but if I followed your comment about distinguishing, yeah, docs for each policy should definitely be clear as to whether it is a read or write operations (and more)
16:17:45 <ayoung> really, we have admin+red+write as one set and member+read+write as a second.
16:18:32 <ayoung> as the read-only role people are asking for might need to read info that a Member should not read.
16:19:22 <ayoung> what if we provided a default set of Rules and suggest to the projects that they implement them.
16:19:42 <edmondsw> there is an odd case with nova ssh keys that we'll have to be conscious of here... in that case, I believe the user to which the key belongs can do things that even admin can't... i.e. admin isn't a true superset
16:19:48 <ayoung> ADMIN_WRITE,  ADMIN_READ, MEMBER_WRITE,  MEMBER_READ.
16:19:50 <ayoung> edmondsw, yes
16:19:55 <ayoung> and that should be OWNER
16:20:04 <ayoung> or USER?
16:20:09 <edmondsw> :)
16:20:16 <ayoung> something that indicates permission is at the per-user level.
16:20:33 <ayoung> OWNER_READ:  Get my Keys.
16:20:36 <edmondsw> owner has been overloaded too much... I'd prefer we be clearer and say user if that's what is meant
16:20:43 <ayoung> edmondsw, ++
16:21:43 <ayoung> USER: user_id=target.user_id or trustee_id=target.user_id
16:22:02 <ayoung> Ugh
16:22:12 <ayoung> no way to scope those operations in a trust
16:22:24 <ayoung> would need to user impersonation today
16:22:26 <ayoung> yuck
16:23:19 <ayoung> OK, lbragstad which of those two specs do you want me to add the suggested rules to?
16:23:37 <lbragstad> well - the one is specific to deprecating policies, so probably not that one
16:23:42 <lbragstad> other other is for adding scope
16:23:50 * knikolla needs to go. but will read the log.
16:23:54 <lbragstad> which is probably closer to what you're thinking?
16:24:09 <lbragstad> ayoung: if not, we can break it off into it's own spec, too
16:24:26 <edmondsw> I'd have said separate spec, I think
16:24:34 <lbragstad> ok
16:24:36 <ayoung> well, it ties in with scope, though
16:24:54 <edmondsw> yeah, maybe that one... I haven't read it yet :)
16:25:38 <edmondsw> sure, throw it in there... we can always pull it out if need be
16:25:53 <edmondsw> does seem like it might fit there
16:26:15 <lbragstad> #topic open discussion
16:27:34 <lbragstad> anything else we want to cover today?
16:28:04 <edmondsw> none from me
16:28:47 <lbragstad> cool
16:28:53 <lbragstad> looks like we can get some time back
16:29:03 <lbragstad> reminder we won't have a meeting next week because of the PTG
16:29:12 <lbragstad> if you're going to be there, travel safe!
16:29:16 <edmondsw> ++
16:29:29 <lbragstad> thanks for coming!
16:29:32 <lbragstad> #endmeeting