16:00:14 <lbragstad> #startmeeting policy
16:00:15 <openstack> Meeting started Wed Jan 18 16:00:14 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:16 <lbragstad> ping  raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung, stevemar, ravelar
16:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:19 <openstack> The meeting name has been set to 'policy'
16:00:24 <lbragstad> agenda #link https://etherpad.openstack.org/p/keystone-policy-meeting
16:00:24 <gagehugo> o/
16:00:25 <morgan> lbragstad: you should add me to the ping list
16:00:29 <stevemar> o/
16:00:29 <rderose> o/
16:00:41 <morgan> o/
16:00:47 <lbragstad> ping  raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung, stevemar, ravelar, morgan
16:00:49 <lbragstad> :)
16:00:52 <gagehugo> o/
16:00:53 <lbragstad> morgan done
16:00:59 <morgan> lbragstad: tyvm
16:01:16 <knikolla> o/
16:01:26 <lbragstad> also - if anyone knows of anyone else that is interested in policy and isn't on the ping list, let them know
16:01:35 <lbragstad> (cross project especially)
16:02:15 <lbragstad> # topic Recap discussion from mailing list
16:02:31 <lbragstad> #topic Recap discussion from the mailing list
16:02:41 <lbragstad> #link http://lists.openstack.org/pipermail/openstack-dev/2017-January/109967.html
16:02:49 <lbragstad> If you remember from last meeting, we wanted to try and come to consensus on the status of the two policy files we have
16:02:57 <lbragstad> Looks like we don't have any feedback so far :(
16:03:04 <lbragstad> If you have any thoughts or ideas, please don't hesitate to share them!
16:03:09 <lbragstad> cc morgan ^
16:03:32 <morgan> so. i can say why we have 2
16:03:35 <morgan> it is a very simple reason
16:03:55 <lbragstad> #topic keystone's policy file tribal knowledge
16:04:03 <stevemar> ++ to topic
16:04:14 <morgan> the orignial dumb file is installed by default and the v3 policy file would break many deployments not overriding it without new additional roles
16:04:15 <lbragstad> morgan go for it
16:04:17 <stevemar> lets all gather around the fire
16:04:29 <morgan> v3 policy file was created as a template for what we wanted
16:04:35 <morgan> but things like bootstrap didn't exist
16:04:52 <lbragstad> morgan `keystone-manage boostrap`?
16:04:53 <morgan> so everything was done mostly in migrations and in direct sql injection
16:04:57 <morgan> lbragstad: yep
16:05:01 <lbragstad> ah
16:05:20 <stevemar> so how can we migrate over to the new one?
16:05:22 <morgan> the main reason we haven't pivoted to the v3 policy is because any deployment relying on dumb policy would stop working
16:05:27 <morgan> 2 options have been proposed
16:05:31 <morgan> break people (bad)
16:05:33 <morgan> but doable
16:05:36 <lbragstad> stevemar i have an idea how - but i'll wait for others to weigh in
16:05:38 <morgan> with a upgrade doc
16:05:55 <stevemar> are we really breaking people? they don't just blindly copy the file over
16:06:15 <lbragstad> morgan what would the upgrade consist of?
16:06:17 <morgan> 2: pivot the config for policy, make it shift to a new default if it exists (not "sample") we use it,
16:06:24 <morgan> with an upgrade doc
16:06:32 <morgan> stevemar: it's not us it is packagers
16:06:37 <morgan> and deployment tools
16:06:42 <morgan> some have in the past copied it
16:06:57 <morgan> with the death of v2 coming soon (tm), it may be an easier sell
16:07:17 <morgan> the upgrade is setting up the new roles, assigning the roles to the right  (user, project) combos
16:07:27 <morgan> and setting up things like is-admin-project (if needed)
16:07:33 <morgan> then dropping the policy file in place
16:07:53 <morgan> many production systems still just use :admin: and :member: and the very limited default policy
16:08:16 <morgan> so we need to communicate the deprecation and encode the new stuff in the tools such as `keystone manage-bootstrap`
16:08:28 <morgan> AND we need dsvm to run with v3 policy
16:08:33 <morgan> right now it can't afaik
16:08:35 <lbragstad> morgan so bootstrap would be used to create new roles?
16:08:56 <stevemar> lbragstad: just a handful?
16:09:01 <morgan> lbragstad: or at least it needs a template for the proper defaults
16:09:20 <morgan> probably a yaml that sets the mappings up
16:09:41 <morgan> so a deployer can override the basics if needed (otherwise it;ll have like 5-10 more cli options to fill in)
16:09:49 <breton> fuel doesn't modify it and uses basically the on in etc/
16:10:15 <lbragstad> got it -
16:10:16 <morgan> breton: thanks, that is my point right there. many tools use the simple basic policy file.
16:10:24 <lbragstad> so we have three options
16:10:35 <morgan> i am still an advocate for moving this way
16:10:45 <morgan> it just was a mire of mess before we had more of our own tools in place
16:10:46 <lbragstad> 1.) break people by just switching the default policy to the v3 cloud sample one
16:11:09 <breton> for example the new policy file will probably break hierarchical quotas in cinder
16:11:11 <lbragstad> 2.) use keystone-manage bootstrap to provide a migration path by creating new roles and assigning them
16:11:31 <morgan> now we have more options and with v2 coming up on eol, it becomes much more straight forward to say it makes sense to put the effort in, since v2 member/admin is still a requirement of roles
16:11:38 <morgan> without those roles v2 wont work
16:11:59 <breton> because cinder lists projects being an admin somewhere and in v3 it requires to be domain admin
16:12:15 <breton> *v3cloudsample
16:12:34 <morgan> it sounds like we need a dsvm to be able to be run that does the cross-gate thing to validate what all is horked
16:12:45 <morgan> and this is going to be a lot like getting people on v3 auth
16:12:46 <morgan> ftr
16:12:50 <morgan> a long, painful process
16:12:59 <morgan> (probably not as painful as v3 auth)
16:13:25 <breton> i also think it will make us re-think how we deal with service users now
16:13:26 <morgan> breton: that is mostly a function of what roles the cinder user has.
16:13:45 <morgan> breton: largely that is a v2 vs v3 thing that has been on the backburner
16:14:00 <breton> because today everybody assumes that service user is an admin (everywhere) and can do whatever it wants
16:14:02 <morgan> since v2 was still *required* until recently to run a cloud
16:14:08 <morgan> meaning admin just was the right choice
16:14:39 <morgan> anyway, story time is over :)
16:14:44 <morgan> now yall know the tribal history
16:14:52 <lbragstad> morgan thanks
16:14:59 <lbragstad> the third option would be
16:15:39 <lbragstad> option 3.) codify the existing (insufficient for v3) policy into oslo.policy like nova has done, and use tooling in oslo.policy to move the defaults to something that works for v3cloudsample
16:15:51 <lbragstad> so - using oslo.policy as the vehicle to consolidate
16:16:00 <morgan> that is option 3, which we didn't have until very recently
16:16:15 <lbragstad> morgan right
16:16:15 <morgan> i like options 2 and 3.
16:16:21 <lbragstad> I would be fine with either 2 or 3 depending on the migration of #2
16:16:24 <morgan> option 1 is still distateful
16:16:30 <morgan> distasteful*
16:16:30 <lbragstad> right
16:16:45 <lbragstad> I would agree
16:16:54 <lbragstad> does anyone else have thoughts?
16:16:56 <morgan> regardless of the path, we need a gate job to test (like we have for v3 only)
16:17:47 <rderose> once v2 is eol'd, can we just move to the new policy file?
16:17:47 <lbragstad> morgan yeah - so the gate job would run with all v3cloudsample policies overriding the defaults
16:18:26 <morgan> rderose: same issues as before. we don't want to just break people
16:18:31 <lbragstad> rderose that's a good question, because I assume there will still be deployers that are using the *old* policy file
16:18:35 <morgan> but we can provide a clean migration path
16:18:58 <morgan> i think the migration path will be hard to build because who knows what people have done in their deployments
16:19:07 <lbragstad> right
16:19:21 <lbragstad> but that's the nice thing about option 3
16:19:29 <ruan_19> is it possilbe to delegate to an external PDP like Fortress?
16:19:31 <lbragstad> anything they have in their policy file will override the defaults
16:19:36 <morgan> fwiw, i have always thought we should get much more prescriptive on required policy setup
16:19:49 <morgan> aka a service user looks like X
16:19:57 <morgan> and we start pushing down that path to force the issue
16:20:01 <morgan> with little wiggle room
16:20:15 <lbragstad> ruan_19 we have had people do that before - but fortress doesn't really take project scope into consideration
16:20:19 <morgan> i don't like taking options away from deployers, but in the case of policy, i think we need to
16:20:45 <morgan> ruan_19: we have support in oslo.policy, but we don't have anyone gating on it
16:20:53 <ruan_19> I mean make the possibility to an external PDP
16:21:03 <morgan> ruan_19: we could, it is supported
16:21:13 <morgan> just not currently tested directly in that manner
16:21:37 <lbragstad> it would provide deployers with another option for policy enforcement
16:21:59 <morgan> lbragstad: i am not really usually for taking a ton of options away from deployers, but i thnk in the case of policy we (openstack) needs to be much more opinionated/prescriptive
16:22:13 <morgan> so we can have more consistency/better security story
16:22:21 <lbragstad> morgan i would agree
16:22:22 <ruan_19> when I check the current code, the PDP delegation is not easy, we should modify the configuration file for each service
16:22:45 <morgan> ruan_19: correct. it is not easy, it is doable
16:23:06 <morgan> at least in keystone it is doable. it was a requirement from henrynash
16:23:11 <lbragstad> morgan so far - I envision that process starting with encoding policy into oslo.policy and using that to move to better defaults out of the box, then we should start documenting the patterns (hopefully into a community goal or project assertion?)
16:23:34 <morgan> lbragstad: that works for me.
16:23:39 <ruan_19> if we agree to consolidate policies, the delegation will be easier
16:23:51 <lbragstad> i think it would be great to have a document that defines what policy is in openstack
16:24:08 <morgan> ruan_19: that is a hard sell, consolidations become difficult in the distributed architecture of openstack
16:24:34 <lbragstad> ruan_19 consolidate the policy files for each service?
16:24:35 <morgan> it becomes a distribution/chicken/egg issue and many tools used for configuration cannot handle it.
16:24:50 <morgan> it is not a bad idea, just we;ve been down the path many times
16:24:53 <morgan> just ask ayoung ;)
16:25:07 <morgan> so lots of pitfalls to navigate
16:25:26 <lbragstad> right - that's hard
16:25:55 <lbragstad> ruan_19 I assume you mean taking all policy files and collapsing them somewhere under a specific service
16:26:18 <ruan_19> yes, what we are looking for
16:26:26 <ruan_19> what we are working
16:28:46 <lbragstad> ayoung spent a lot of time trying to do that with his dynamic policy approach
16:28:57 <morgan> and with the policy api
16:29:01 <morgan> and with other things
16:29:08 <morgan> it really has been tried 5 or 6 ways now
16:29:34 <morgan> it still isn't a bad idea. it just has a lot of pitfalls
16:29:44 <morgan> like... what happens when a file is updated, how does the service know
16:30:10 <morgan> make sure distribution is there, make sure we don't add yet-another-round-trip to check if something is allowed
16:30:15 <lbragstad> i think strong arming the other projects to relinquish control of their policy files is going to be hard
16:30:22 <lbragstad> i would opt for developing a clear and explicit set of guidelines that help them correct their policy on their own
16:30:48 <morgan> lbragstad: and a "keystone will stop using 'member' and 'admin' by XXX"
16:30:57 <morgan> lbragstad: by default
16:31:41 <lbragstad> right - we could make that a goal and have something to tie to each project, like a project tag
16:31:51 <rderose> morgan: ++
16:31:55 <lbragstad> asserts:support-rich-rbac
16:31:57 <morgan> or... a gate job >.>
16:32:00 <lbragstad> asserts:supports-rich-rbac
16:32:11 <morgan> but sure. a tag if the TC is up for that type of tagging
16:32:17 <morgan> (psst stevemar weigh in here)
16:32:17 <lbragstad> morgan in addition to a gate job since it would have to be tested somehow
16:36:15 <lbragstad> ok - so it sounds like we have an action item to document the tribal knowledge discussed here
16:36:28 <lbragstad> and vocalize the options we have?
16:36:38 <morgan> sounds about right.
16:36:48 <lbragstad> then we can start moving forward on one
16:36:49 <morgan> make sure you drop a post to the operator list
16:36:56 <lbragstad> ++
16:37:35 <lbragstad> i think once we have an upgrade path in place, we could probably start looking at what the defaults should be for each operation
16:37:47 <lbragstad> (and start moving towards a richer policy)
16:38:15 <lbragstad> but I would expect that work to come after we setup guidelines with other projects (?)
16:38:41 <lbragstad> for example; in OpenStack what should a 'reader' role be able to do?
16:39:39 <morgan> yep
16:39:56 <morgan> i would also like to set much stricter guidelines on "service" accounts
16:39:56 <lbragstad> I would like to see if we could start having that discussion in ATL
16:40:20 <lbragstad> morgan example?
16:40:24 <morgan> such as "cannot be admin"
16:40:29 <lbragstad> ah
16:40:40 <morgan> must have a "service" role... or some such
16:40:47 <lbragstad> so - identifying operations in openstack that a service user is required to perform
16:40:54 <morgan> make sure service accounts are really scoped to actions
16:40:57 <lbragstad> and only allowing those operations through that role
16:41:00 <morgan> not "can do whatever they want"
16:41:03 <lbragstad> right
16:41:09 <morgan> they may be "admin" in their service
16:41:27 <morgan> but not globally
16:41:33 <edmondsw> I think there should actually be different service roles for different services... e.g. "nova" role vs. "cinder" role
16:41:37 <lbragstad> that'd be a good security exercise
16:41:39 <morgan> we may also want to revisit unscoped roles.
16:41:49 <morgan> action to discuss within keystone
16:42:08 <morgan> it may make sense to go back on the previous choice and allow roles tht are not project/domain locked
16:42:14 <lbragstad> #action let's revisit the concept of unscoped roles
16:42:40 <morgan> it may not make sense for a service user to need a project scope for example.
16:42:54 <lbragstad> #action document the tribal knowledge around keystone's policy files in http://lists.openstack.org/pipermail/openstack-dev/2017-January/109967.html
16:42:58 <edmondsw> morgan I'm definitely of the opinion that we should support global role assignments
16:43:07 <morgan> but that is a keystone-specific convo being brought back from an action here
16:43:24 <morgan> i am unsure how i feel about global roles, but it is worth re-visiting the discussion
16:43:25 <edmondsw> and not just for service roles
16:43:32 <morgan> (it may also simplify 'cloud admin')
16:43:36 <morgan> long term.
16:43:39 <lbragstad> at this point - i'm open to any/all discussions
16:43:42 <edmondsw> it *definitely* simplifies cloud admin
16:43:50 <morgan> but a lot of mechanisms need to be fixed that assume "scope" if we do that
16:44:21 <morgan> since we're revisiting policy, we might as well revisit some core RBAC concepts we have had for a while
16:46:15 <lbragstad> morgan like what?
16:46:32 <morgan> global roles
16:46:33 <morgan> ;)
16:46:40 <morgan> sorry, that was implied not said directly
16:46:40 <lbragstad> oh - sure
16:47:41 <lbragstad> ok - are there any action items that were missed?
16:49:47 <lbragstad> #topic open discussion
16:49:54 <lbragstad> does anyone have anything else?
16:50:14 <lbragstad> questions, comments, concerns, snide remarks?
16:50:17 <lbragstad> ;)
16:51:59 <lbragstad> alright - we can end early to give folks some time back
16:52:06 * morgan throws things from the peanut gallery
16:52:16 <lbragstad> thanks for coming and thanks for the discussion!
16:52:18 <lbragstad> #endmeeting