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