16:00:47 <lbragstad> #startmeeting policy
16:00:48 <openstack> Meeting started Wed Feb  8 16:00:47 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:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:52 <openstack> The meeting name has been set to 'policy'
16:01:03 <lbragstad> ping raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung, stevemar, ravelar, morgan, raj_singh
16:01:54 <lbragstad> agenda #link https://etherpad.openstack.org/p/keystone-policy-meeting
16:02:14 <dstanek> howdy
16:02:15 <lbragstad> not sure if johnthetubaguy is around?
16:02:21 <lamt> o/
16:02:22 <lbragstad> dstanek gagehugo edmondsw o/
16:02:25 <rderose> o/
16:02:26 <lbragstad> lamt o/
16:02:27 <gagehugo> o/
16:03:02 <edmondsw> o/
16:03:20 <ruan_20> o/
16:03:44 <lbragstad> we'll give folks another minute to join before we get started
16:04:29 <lbragstad> agenda #link https://etherpad.openstack.org/p/keystone-policy-meeting for those who need it
16:05:20 <lbragstad> #topic Nova's policy goals for Pike
16:05:40 <lbragstad> we don't have much for announcements - so we can jump right in
16:05:54 <lbragstad> johnthetubaguy proposed a set of goals nova wants to accomplish for Pike
16:06:02 <lbragstad> #link https://review.openstack.org/#/c/427872/
16:06:27 <johnthetubaguy> we have a talk at the nova-api meeting today about things, we may be shifting focus a bit after that
16:06:39 <johnthetubaguy> but its stuff we are actively discussing right now
16:07:05 <lbragstad> johnthetubaguy this one? #link http://eavesdrop.openstack.org/#Nova_API_Meeting
16:07:45 <johnthetubaguy> yeah
16:08:03 <lbragstad> johnthetubaguy awesome - i'll see if I can swing by
16:08:48 <lbragstad> that spec has a lot of relevance with this meeting - so feel free to review it
16:09:09 <lbragstad> I'm attempting to keep tabs on it - but i assume it will make for some good discussion at the PTG
16:09:20 <lbragstad> which moves into our next topic
16:09:25 <lbragstad> #topic Keystone specs for richer policy
16:10:03 <johnthetubaguy> so I could cover quickly the discussion if that helps
16:10:08 <lbragstad> after seeing the work johnthetubaguy did for nova - i took a stab at doing the same for keystone #link https://review.openstack.org/#/q/status:open+project:openstack/keystone-specs+branch:master+topic:bp/richer-policy
16:10:11 <johnthetubaguy> sorry half in a stand up that was running long
16:10:13 <johnthetubaguy> ah, cool
16:10:17 <lbragstad> johnthetubaguy go for it
16:10:22 <johnthetubaguy> so we are thinking we should focus on the docs
16:11:01 <lbragstad> johnthetubaguy new docs or existing ones?
16:11:20 <johnthetubaguy> so using olso.polcy
16:11:23 <johnthetubaguy> let me get a link
16:12:11 <johnthetubaguy> #link http://docs.openstack.org/developer/nova/sample_policy.html
16:12:22 <johnthetubaguy> this is what nova today generates from the code
16:12:38 <lbragstad> johnthetubaguy nice
16:13:19 <johnthetubaguy> so there is one doc comment in there alreday
16:13:23 <lbragstad> johnthetubaguy are the docs going to describe what each operation does?
16:13:26 <johnthetubaguy> is terrible, but we have a route forward there
16:13:39 <johnthetubaguy> so there is a nice way to think about this
16:13:55 <johnthetubaguy> operators should be able to read this sample policy file, and no longer have to read the code
16:14:04 <johnthetubaguy> if thats true, we did it right
16:14:13 <lbragstad> johnthetubaguy so exactly like configu
16:14:14 <johnthetubaguy> thats what we are doing for the configuration
16:14:16 <johnthetubaguy> yeah
16:14:17 <lbragstad> configuration*
16:14:37 <johnthetubaguy> if you search for os_compute_api:os-attach-interfaces:create
16:14:40 <johnthetubaguy> it has a quick note
16:14:51 <johnthetubaguy> its almost good enough actually, and its just a one liner
16:15:02 <lbragstad> so - would it look like? #link https://github.com/openstack/keystone/blob/029476272fb869c6413aa4e70f4cae6f890e598f/keystone/conf/auth.py#L22-L28
16:15:37 <johnthetubaguy> so in the code we have this
16:15:38 <johnthetubaguy> https://github.com/openstack/nova/blob/4f91ed3a547965ed96a22520edcfb783e7936e95/nova/policies/attach_interfaces.py#L25
16:15:42 <johnthetubaguy> so yeah, basically the same
16:15:56 <johnthetubaguy> right now all our rules have to be registered, and you get the chance to specify the docs
16:16:14 <lbragstad> ah - so the RuleDefault as a description attribute
16:16:34 <johnthetubaguy> yeah
16:16:37 <johnthetubaguy> the other side of this:
16:16:38 <johnthetubaguy> https://github.com/openstack/nova/blob/master/tox.ini#L91
16:16:47 <johnthetubaguy> its basically just like config
16:17:13 <lbragstad> aha
16:17:32 <lbragstad> when did the RuleDefault object get a description attribute?
16:17:36 <johnthetubaguy> there is the upgrade conversation if we want to do renames, but basically I am thinking in pike we might focus on just getting some docs in there
16:17:40 <johnthetubaguy> lbragstad: not sure actually
16:17:57 <lbragstad> i swear i checked for that last week
16:18:26 <johnthetubaguy> https://github.com/openstack/oslo.policy/blob/9e3d46b1707152094cc2c2bdd45e22898d79140c/oslo_policy/policy.py#L791
16:18:30 * johnthetubaguy shrugs
16:19:12 <johnthetubaguy> seems like it got added with rule default
16:19:18 <lbragstad> huh - cool
16:19:20 <johnthetubaguy> that was always our intention at least
16:19:21 <johnthetubaguy> https://github.com/openstack/oslo.policy/commit/bb1127232695c07eb8e3622714b7de7cf7219ccc
16:19:30 <johnthetubaguy> auto gen docs that match the config
16:19:48 <lbragstad> so the auto generation already pulls the description
16:19:51 <johnthetubaguy> yep
16:19:53 <lbragstad> it looks like
16:19:56 <lbragstad> that's aweesome
16:20:07 <lbragstad> that is essentially the next topic i had on the agenda
16:20:12 <johnthetubaguy> so yeah, for pike, we plan to fill that in
16:20:13 <dstanek> johnthetubaguy: i like this idea
16:20:13 <edmondsw> so just docs... any thought being given to the code changes that need to happen, like https://review.openstack.org/#/c/384148/
16:21:05 <dstanek> johnthetubaguy: you don't do anything dynamic with the rules through right? like at import time change the stuff that is in the list (besides the % operator stuff)?
16:21:06 <edmondsw> and one of the things I find most confusing in nova is that scope is restricted to the current project via code in some places (like it should be) but in other places you have to worry about scope in the policy file
16:21:12 <edmondsw> good luck making that clear in docs...
16:21:17 <johnthetubaguy> so right now, I have put about 1 billion things on the table to consider, I need to trim that down into some stages
16:21:19 <edmondsw> it needs to be fixed in code
16:21:26 <johnthetubaguy> dstanek: dynamic? why would you want that?
16:22:02 <johnthetubaguy> edmondsw: yeah, thats on the "to fix" list, admin vs non admin used to be hardcoded to, but we have carefully removed that now, baby steps
16:22:14 <edmondsw> cool
16:22:16 <dstanek> johnthetubaguy: i wouldn't :-)
16:22:26 <dstanek> johnthetubaguy: i was just wondering if you guys did that
16:22:32 <johnthetubaguy> dstanek: heh, no worries
16:22:51 <johnthetubaguy> dstanek: I don't see any use case for it, most folks want to audit policy, dynamic seems to fight that somewhat
16:23:06 <lbragstad> johnthetubaguy the registration steps is what determines if you're going to use the default or a policy defined in an existing policy.json/yml file somewhere, right?
16:23:22 <johnthetubaguy> the registration step is the default
16:23:31 <johnthetubaguy> we don't have any policy file in tree any more
16:23:41 <lbragstad> aha
16:23:44 <johnthetubaguy> by default Nova works with no policy file being present on the disk
16:23:47 <edmondsw> johnthetubaguy, I would love to be involved in helping you fix the project scope check issue when you can get to it
16:23:49 <dstanek> johnthetubaguy: yeah, i agree. i was thinking that someone will eventually want to change policy based on config, or something else
16:23:58 <dstanek> then it's hard to know what is happening
16:24:08 <johnthetubaguy> edmondsw: cool, more hands on there could really help
16:24:36 <johnthetubaguy> dstanek: now available capabilities of the system is a different thing, policy always stays static for me, like you say
16:24:43 <lbragstad> johnthetubaguy so far nova is the only project to put policy into code, right?
16:24:49 <johnthetubaguy> lbragstad: AFAIK, yes
16:25:12 <edmondsw> cinder has a spec for it, but didn't make ocata
16:25:26 <lbragstad> so for keystone - that'd be our first step #link https://review.openstack.org/#/c/428453/
16:25:40 <johnthetubaguy> so there is some fun tooling that helps you merge a file with the defaults in the code, and to help find what duplicates you have in your file, to help with upgrades
16:25:40 <edmondsw> lbragstad +1
16:25:54 <johnthetubaguy> haven't had feedback on if that works for people yet, but its what they asked for
16:26:05 <smcginnis> Really no progress on that on the Cinder side for now.
16:26:07 <lbragstad> we might be able to coordinate parallel efforts to fill in descriptions as we do that?
16:26:08 <dstanek> lbragstad: this should be pretty easy to get in right? you haven't heard of any pushback have you?
16:26:44 <lbragstad> dstanek no real pushback yet - but i'm continuing to advertise it
16:27:01 <lbragstad> and still looking for feedback and people to help out with the effort
16:27:21 <lbragstad> (the sooner we do that the sooner we'll be on the same page as nova/other projects)
16:27:29 <lbragstad> which would make doing what johnthetubaguy wants easier
16:27:33 <dstanek> lbragstad: let push in it before the haters have a chance to see it :-D
16:27:50 <lbragstad> dstanek :)
16:28:04 <johnthetubaguy> so there are some interesting thoughts earlier on turning the policy file upside down
16:28:06 <lbragstad> "nothing to see here, move along citizen, move along"
16:28:30 <lbragstad> johnthetubaguy how so?
16:28:49 <johnthetubaguy> right now we say { p1: admin_or_owner, p2: admin, p3:admin ...}
16:28:57 <johnthetubaguy> as in define who can do each rule
16:29:05 <johnthetubaguy> but as an operator really you want to see
16:29:37 <johnthetubaguy> { owner_can_do: [p1], admin_can_do: [p2, p3] }
16:29:42 <johnthetubaguy> or something like that
16:29:44 <edmondsw> +1
16:29:48 <lamt> +1
16:29:48 <lbragstad> ++
16:29:59 <edmondsw> that was popular quickly :)
16:30:10 <lbragstad> i imagine that would play into capability APIs nicely
16:30:17 <johnthetubaguy> so its totally sdague who brought that up, it seems to make sense
16:30:46 <lbragstad> nova and cinder both have specs for capability APIs
16:30:57 <johnthetubaguy> now that pivot might make sense before we add lots of roles
16:31:04 <sdague> I think the more important thing, is this could be new stanzas in the policy
16:31:14 <sdague> which wouldn't conflict with existing ones
16:31:24 <sdague> so there is a smooth transition across as it's additive
16:31:30 <lbragstad> sdague ++
16:31:40 <edmondsw> how would they not conflict?
16:32:06 <johnthetubaguy> they take preference, and it looks different to the old cruft
16:32:08 <johnthetubaguy> interesting
16:32:27 <lbragstad> you would have to define both to be consistent, but then tell the enforcement point which one to use?
16:32:52 <johnthetubaguy> I would say the new one wins, or you just fail to start if it conflicts
16:33:08 <johnthetubaguy> but it means the old one still works
16:33:13 <lbragstad> right
16:33:15 <johnthetubaguy> and the new one would work
16:33:19 <johnthetubaguy> which is more important
16:33:44 <lbragstad> so - that would be an alternative to the richer policy roles?
16:34:04 <edmondsw> so it's not the old way OR checks from the new way?
16:34:05 <lbragstad> or a prerequisite?
16:34:06 <johnthetubaguy> a way of making the richer policy defaults easier to deal with maybe?
16:34:31 <johnthetubaguy> I quite like it as a prerequisite myself, the more I think about it
16:34:48 <edmondsw> I assume the new way still lets you do things besides just check role... e.g. operator can do p1 if xyz
16:35:08 <lbragstad> put policy into code -> redefine policy by role instead of operation -> introduce more granular roles ?
16:35:09 <johnthetubaguy> for the record, there is loads to go through here, which is why I think I want to focus on getting the docs started :)
16:35:46 <lbragstad> johnthetubaguy yeah - i would think that'd be something we'd have to do regardless
16:35:53 <johnthetubaguy> lbragstad: I nova I we have some other de-cruft-i-fy bits that edmondsw hinted at earlier, but yeah, something like that
16:35:56 <johnthetubaguy> lbragstad: totally
16:36:07 <johnthetubaguy> hmm, typing failed me there
16:36:18 <johnthetubaguy> insert some grammar bits as you see fit
16:36:31 <lbragstad> i was able to parse it :)
16:37:02 <lbragstad> so - does anyone see any red flags with the policy in code + documentation around the current operations?
16:37:48 <edmondsw> these new stanzas being organized by role is pretty much the opposite of the approach ayoung was pushing to pull role checks out to middleware
16:38:33 <edmondsw> you wouldn't do both
16:39:01 <johnthetubaguy> so we would never be able to have all policy checks in middleware, unless it implemented most of our API for us
16:39:20 <johnthetubaguy> now it would bring consistency, but the APIs already existing, and they aren't consistent enough
16:39:31 <edmondsw> yeah, that wasn't the proposal... just to do role checks, not the rest
16:39:47 <edmondsw> I think I like this better, at first glance
16:39:58 <johnthetubaguy> having said that, maybe we want a "can access nova API" role check for all requests, that could be a thing I see people liking
16:39:59 <edmondsw> this = sdague's proposal
16:40:33 <johnthetubaguy> so we can still have standards to help with names etc
16:40:51 <johnthetubaguy> but in reality we still need a list of all the rules, with documentation, else no one will have a clue whats going on
16:40:58 <sdague> edmondsw: don't consider this as formal as a proposal at this point, it is an observation of the way that admins think about and want to interact with our stuff
16:41:22 <lbragstad> johnthetubaguy ++
16:41:54 <lbragstad> johnthetubaguy that should only make "standardizing" a set of roles easier
16:41:56 <johnthetubaguy> they are solving a different set of problems of course, some of this is agreeing on the most important problems to solve
16:42:10 <sdague> also, having fought over all the complexity of roles for even the most basic things today in working through issues to cut the stable/ocata branch, I am skeptical the current course and speed on roles is helping operators
16:42:12 <edmondsw> sdague i.e., someone else should drive that if they think it's a good idea? :)
16:42:44 <edmondsw> sdague can you elaborate on that last comment a bit more?
16:43:24 <sdague> edmondsw: https://bugs.launchpad.net/keystone/+bug/1662911
16:43:24 <openstack> Launchpad bug 1662911 in OpenStack Identity (keystone) "v3 API create_user does not use default_project_id" [Undecided,New]
16:43:51 <sdague> anyway, this is probably going to divert from the core discussion here
16:44:26 <sdague> I think the important thing on policy is to remember that it is an interface for operators for them to clearly express their intent of how they expect the system to work
16:44:38 <johnthetubaguy> sdague: ++
16:44:52 <sdague> and if that expression doesn't align with the way people think about it, they will introduce bugs and security issues
16:45:31 <johnthetubaguy> something tells me we need less granular rules for many things
16:45:59 <johnthetubaguy> an operator cares about reading servers for a project, not listing, getting, filter, etc
16:46:06 <lbragstad> johnthetubaguy less granular than what we have today?
16:46:18 <sdague> johnthetubaguy: right, though that's a project artifact
16:46:22 <johnthetubaguy> maybe grouped or hierarchical
16:46:23 <lbragstad> ah - so grouping similar operations
16:46:48 <johnthetubaguy> the other thing is we let people basically make the API non-interoperable today, which also feels bad (and I don't just mean fix it with API discoverability)
16:46:59 <johnthetubaguy> s/API/capability/
16:47:03 <sdague> johnthetubaguy: yeh, one thing at a time
16:47:14 <johnthetubaguy> yeah, sorry, as you see, I keep getting carried away
16:47:47 <lbragstad> i think this is good - because it helps us figure out what the big picture should be
16:47:51 <johnthetubaguy> the doc would should help us better understand what we have today, and should help operators come back with more interesting questions
16:47:53 <sdague> because I think the biggest concrete concern today is the system is confusing enough that it is really easy to have a giant security hole and not realize it
16:48:00 <johnthetubaguy> sdague: +1000
16:48:05 <lbragstad> sdague ++
16:48:29 <johnthetubaguy> "oh that rule means any user can destroy my cloud now, whoops"
16:49:26 <lbragstad> so - it still sounds like in order to do any of this we will need in-code policy
16:49:44 <johnthetubaguy> I think so
16:49:51 <lbragstad> or in-code policy will make it much easier
16:49:55 <johnthetubaguy> yeah, that
16:50:21 <lbragstad> does anyone disagree with that assessment?
16:51:13 <edmondsw> johnthetubaguy, I think we need to allow folks to customize listing, getting, etc individually... but I would love to see sensible defaults that use common rules... e.g. "os_compute_api:servers:show": "os_compute_api:servers:list" so if you want to change both you only have to change the list one
16:51:15 * johnthetubaguy is hoping thats the silence of agreement
16:51:49 <edmondsw> or a new rule that both show and list point to by default, and you change that to change them both
16:52:20 <johnthetubaguy> yeah, I am really meaning about adding a new rule as a default, at least at first
16:52:47 <johnthetubaguy> having said that, I don't really get the use case for different rules for each of those
16:53:15 <edmondsw> 99.8% of the time they're the same, but I do have cases where I've customized them differently
16:53:37 <lbragstad> edmondsw can you share the 0.2%?
16:53:45 <johnthetubaguy> but was the 0.2% a real deal break, or just because you could?
16:53:47 <edmondsw> I'll have to go find them...
16:53:57 <edmondsw> I think they were pretty important
16:54:07 <johnthetubaguy> edmondsw: would be great to get data on that
16:54:46 <johnthetubaguy> now if enable list would create a ddos, thats probably a slightly different case
16:55:32 <lbragstad> FYI - we're at the 5 minute mark
16:58:06 <lbragstad> edmondsw would you be interesting in bringing those use cases to the meeting next week?
16:58:28 <edmondsw> I will try to run them down
16:58:33 <lbragstad> edmondsw cool
16:58:41 <lbragstad> does anyone have any last minute things?
16:59:35 <lbragstad> johnthetubaguy sdague thanks for sharing
16:59:53 <johnthetubaguy> thanks, was a good discussion
17:00:17 <lbragstad> do we want to propose the upside-down-policy thing?
17:00:25 <lbragstad> in a spec or something like that?
17:01:13 <lbragstad> either way - i can look into that. thanks for coming everyone!
17:01:16 <lbragstad> #endmeeting