16:00:01 <lbragstad> #startmeeting policy
16:00:02 <openstack> Meeting started Wed Nov 29 16:00:01 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:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:04 <lbragstad> #link https://etherpad.openstack.org/p/keystone-policy-meeting
16:00:06 <openstack> The meeting name has been set to 'policy'
16:00:07 <lbragstad> agenda ^
16:00:14 <lbragstad> ping raildo, ktychkova, rderose, htruta, hrybacki, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan_he, ayoung, kmalloc, raj_singh, johnthetubaguy, knikolla, nhelgeson
16:00:24 <lamt> o/
16:00:28 <hrybacki> o/
16:00:33 <knikolla> o/
16:00:37 <cmurphy> o/
16:00:49 <lbragstad> so - we don't have anything on the agenda
16:01:05 <lbragstad> but i figured we could meet and open it up to any policy topics if folks have any
16:01:11 <lbragstad> #topic open discussion
16:01:33 <hrybacki> Do we want to kick up the polciy exploring sessions again or wait until after the new year?
16:02:10 <edmondsw_> o/
16:02:23 <lbragstad> hrybacki:  i'm good with either
16:02:24 <edmondsw_> I vote wait until the new year
16:02:50 <hrybacki> +1
16:03:00 <lbragstad> do we feel like we got some useful bits out of the ones we had/
16:03:08 <lbragstad> and would a summary there be beneficial?
16:03:33 <hrybacki> I think it attracted a pretty diverse crowd which was nice
16:03:47 <edmondsw_> I thought they were useful
16:04:41 <lbragstad> it helped reinforce the needs for the initial steps we're taking
16:04:46 <lbragstad> at least in my opinion
16:05:24 <lbragstad> and it highlighted some key differences between what other systems have to protect with policy and what openstack has to protect with policy
16:05:51 * hrybacki nods
16:06:16 <lbragstad> if folks think a summary would be useful - i can attempt to jot down my thoughts and aggregate notes
16:06:54 <hrybacki> It would be a good thing to add to our next email to the ML advertising the next session for sure
16:07:06 <lbragstad> hrybacki:  a link to a summary?
16:07:23 * hrybacki nods -- or a concise version in the body of the email
16:07:30 <lbragstad> yeah
16:08:42 <lbragstad> in other news
16:08:48 <lbragstad> #link http://lists.openstack.org/pipermail/openstack-dev/2017-November/124966.html
16:08:57 <lbragstad> i sent out a quick status on goal progress
16:09:34 <lbragstad> a few projects are getting really close to being done
16:10:04 <lbragstad> also
16:10:16 <lbragstad> #info tc is now accepting goals for rocky
16:10:32 <lbragstad> i have a todo to draft a goal for getting projects to use scope-types
16:10:43 <edmondsw> lbragstad do all of those actually need changes for the policy goal? Should only need changes where there's an API, so e.g. why is heatclient in the list?
16:11:02 <lbragstad> edmondsw: yeah - that's a good question, i need to follow up with ricolin there
16:11:08 <lbragstad> i'm not sure why that is in the list
16:11:16 <edmondsw> and all those networking- and neutron- ones that aren't started
16:11:19 <edmondsw> etc.
16:11:29 <lbragstad> yep - i pinged mlavalle about those
16:11:36 <edmondsw> cool
16:11:37 <lbragstad> i can go ask again
16:12:19 <lbragstad> were there any other goals we wanted to propose for rocky?
16:12:25 <edmondsw> gnocchi and aodh seem to be missing from the email
16:12:26 <lbragstad> from a policy roadmap perspective?
16:12:46 <lbragstad> #link https://trello.com/b/bpWycnwa/policy-roadmap
16:13:40 <cmurphy> something that came up in the tc office hours was that it's hard to set a goal that no one has completed yet, better to already have a few early adopters taht everyone else can copy from and make the goal just getting everyone else to follow suit
16:13:51 <edmondsw> lbragstad I'd love to see a community goal for removing any policy hardcoding, such as things that are hardcoded for admin, ResellerAdmin in swift, etc.
16:14:00 <hrybacki> good point cmurphy
16:14:02 <lbragstad> cmurphy: ++
16:14:09 <lbragstad> edmondsw: yeah - that'd be a good one,too
16:14:13 <lbragstad> edmondsw: #link https://review.openstack.org/#/q/status:merged+project:openstack/aodh+branch:master+topic:policy-and-docs-in-code
16:14:22 <lbragstad> i'll update aodh in governance
16:15:05 <lbragstad> cmurphy: so maybe we do a trial run with scope_types in rocky with keystone and a couple other projects
16:15:17 <lbragstad> and slate scope types for a proposal as a queens goal for S
16:15:43 <lbragstad> which shouldn't set our roadmap back, since the functionality to fix admin-ness isn't changing
16:16:07 <cmurphy> ++
16:16:36 <lbragstad> sweet - that actually removes a todo from my list
16:16:42 <edmondsw> sounds good. I don't think we should need a trial run for removing policy hardcoding, though... Seems like a very project-specific thing
16:16:56 <lbragstad> trial run or a goal?
16:17:02 <edmondsw> I do think we need a goal
16:17:06 <lbragstad> if it's project specific - does it need a goal?
16:17:32 <lbragstad> or if it's is extremely project specific?
16:17:49 <edmondsw> I would still think it needs a goal
16:17:53 <edmondsw> so that everyone does it
16:18:11 <edmondsw> it's project-specific in the sense that everyone has hardcoded things differently
16:18:21 <lbragstad> so - in order to complete that refactor, isn't using scope-types required?
16:18:23 <edmondsw> but it's common in the sense that nobody should hardcode anything
16:18:42 <edmondsw> why would scope-types be required?
16:18:59 <edmondsw> I think this is parallel to scope
16:19:00 <lbragstad> becuase you'd need to actually fix the problem of admin-ness in order to remove the hardcoded checks
16:19:07 <edmondsw> allow hardcoding scope, but nothing else
16:20:09 <edmondsw> maybe I'm missing something, but I don't think we should need to fix 968696 to remove hardcoded policy checks
16:20:25 <edmondsw> role checks, anyway
16:20:38 <edmondsw> I'm not talking about removing hardcoding of policy checks
16:20:43 <edmondsw> s/policy/scope/
16:20:51 * lbragstad is confused
16:21:21 <lbragstad> in order to remove hardcoded "admin" checks, right?
16:21:39 <lbragstad> where a service just checks that a user has the "admin" role regardless of what they are scoped to?
16:21:45 <edmondsw> or other things, e.g. ResellerAdmin in swift
16:21:49 <lbragstad> yeah
16:21:56 <edmondsw> forget scope
16:22:00 <edmondsw> other than that, yes
16:22:09 <lbragstad> but scope has to be a part of that doesn't it?
16:22:20 <edmondsw> why?
16:22:33 <lbragstad> if we remove the hardcoded check of a string, oslo.policy has to evaluate scope, too
16:22:44 <lbragstad> right?
16:23:26 <edmondsw> something does, but not oslo.policy
16:23:34 <edmondsw> not until we have scope-types anyway
16:23:43 <edmondsw> today, scope checks are generally done in code
16:23:47 <edmondsw> hardcoded
16:23:51 <edmondsw> and should stay that way
16:24:02 <edmondsw> because they shouldn't be customizable
16:24:04 <lbragstad> i guess i could be more specific here
16:24:10 <lbragstad> role-scope check
16:24:18 <lbragstad> versus just scope-check
16:24:39 <lbragstad> "does the user have the required role for this operation on the right scope"
16:24:53 <edmondsw> I would say there is no such thing as role-scope check... there is role check and there is scope check and there is target attribute check, and they are all independent and unrelated
16:25:18 <edmondsw> they are only related in that you have to pass all of them
16:25:31 <edmondsw> but they can all be implemented independently
16:25:34 <lbragstad> 1.) role check = does this user have the role necessary to perform this operation
16:25:54 <edmondsw> yes
16:26:04 <lbragstad> 2.) scope check = is the token using the proper scope for the operation being done (system vs. project)
16:26:14 <edmondsw> yes
16:26:33 <lbragstad> 3.) target attribute check = is the thing being acted on in the right project, etc... (all service specific)
16:26:46 <edmondsw> yes
16:26:48 <lbragstad> in order to removed hardcoded "admin" checks
16:26:53 <lbragstad> don't 1 and 2 need to be done?
16:27:02 <lbragstad> in order to fix that as a community goal?
16:27:06 <edmondsw> I think that would just be related to #1
16:27:32 <lbragstad> ok
16:27:43 <edmondsw> define policy checks that are customizable to indicate what role should be allowed, instead of hardcoding that only the admin role is allowed
16:27:56 <lbragstad> yeah - i think i see what you mean now
16:28:10 <lbragstad> i'd need to go through a bunch of the projects to figure out where that is being violated
16:28:27 <edmondsw> yeah
16:28:36 <lbragstad> if it's only a handful of projects, maybe we can just do it with bugs
16:28:44 <lbragstad> instead of proposing a community goal
16:28:59 <edmondsw> that's fair
16:29:01 <lbragstad> but - yeah, i think that totally depends on how many services are doing that
16:29:13 <edmondsw> I know it's a problem in nova and swift at least
16:29:24 <edmondsw> and I think cinder?
16:29:55 <edmondsw> and probably all the telemetry projects
16:30:13 <lbragstad> sounds like we have something to chase before a formal proposal - either way i agree we should fix that
16:30:21 <edmondsw> yep
16:31:20 <lbragstad> anything else we should do as a rocky goal?
16:32:40 <lbragstad> default roles?
16:32:53 <lbragstad> #link https://trello.com/c/C1INH5AI/7-define-default-roles
16:33:08 <hrybacki> That's an important one
16:33:24 <lbragstad> even if it is just admin, reader, writer...
16:33:50 <edmondsw> I think that one needs a trial first
16:34:47 <lbragstad> so something we can try and pilot in rocky
16:34:49 <edmondsw> at least more discussion on "how"
16:35:21 <lbragstad> if all goes well we can remove the policy.v3cloudsample.json file since it will be obsolete at that point
16:35:24 <edmondsw> because we don't want to break backward compat, and that will be tricky
16:35:39 <edmondsw> lbragstad isn't v3cloudsample already obsolete?
16:36:11 <lbragstad> i suppose, but we could officially remove it saying "yep, this is no longer needed because we have sensible defaults out-of-the-box"
16:36:18 <edmondsw> oh, we probably need to fix a bunch of scope checking before we remove it?
16:36:25 <lbragstad> yeah...
16:37:22 <lbragstad> so, community goal, yes or no?
16:37:33 <lbragstad> it will generate discussion that's for sure
16:37:44 <hrybacki> I want to say yes. Might we at a minimum propose it?
16:38:09 <lbragstad> yeah - worst case, it gets shot down and we learn a little more about what still needs to be done
16:39:09 <lbragstad> and maybe we break it into a couple goals
16:39:16 <lbragstad> 1.) define a set of defaults
16:39:22 <lbragstad> 2.) implement a set of defaults
16:39:56 <edmondsw> I don't think #1 needs a goal
16:40:10 <hrybacki> 3.) test a set of defaults
16:40:17 <lbragstad> probably not - but we do need people to participate in the discussion
16:40:26 <edmondsw> and you can't separate 2 and 3
16:40:35 <edmondsw> :)
16:41:04 <lbragstad> traditionally - any sort of default roles discussion had lived in either nova-specs or keystone-specs
16:41:18 <lbragstad> and i think we need to have it at a level where other projects can jump into that discussion
16:41:34 * lbragstad is open to suggestions here
16:41:47 <edmondsw> I think it should be a cross-project spec
16:42:04 <lbragstad> that might work
16:42:21 <lbragstad> are cross-project specs voted on by tc?
16:42:24 <lbragstad> and tc managed?
16:42:32 <edmondsw> I'm not entirely sure how that works
16:43:10 <edmondsw> but I think that's the right place to do it, and I would start that ball rolling and get that spec approved before we propose a goal that everyone implements it
16:43:33 <lbragstad> yeah - i agree
16:44:48 <lbragstad> so, it looks like we have an action there
16:45:22 <lbragstad> i think that kinda wraps up the rocky goals questions i had
16:45:27 <lbragstad> does anyone have anything else?
16:46:22 * hrybacki shakes his head
16:46:52 <lbragstad> cool - thanks for coming everyone
16:46:57 <lbragstad> #endmeeting