16:00:47 <lbragstad> #startmeeting policy
16:00:49 <openstack> Meeting started Wed Aug 16 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:53 <openstack> The meeting name has been set to 'policy'
16:00:55 <lbragstad> ping raildo, ktychkova, rderose, htruta, hrybacki, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan_he, ayoung, morgan, raj_singh, johnthetubaguy, knikolla, nhelgeson
16:01:00 <gagehugo> o/
16:01:02 <lbragstad> o/
16:01:10 <lbragstad> #link https://etherpad.openstack.org/p/keystone-policy-meeting
16:01:17 <felipemonteiro_> o/
16:01:31 <blancos> o/
16:01:43 <edmondsw> o/
16:01:44 <felipemonteiro_> lbragstad: i know i didn't get back to you on mailing list but thanks for the feedback, it helped
16:02:44 <lbragstad> felipemonteiro_: sure thing!
16:03:03 <lbragstad> we don't have much on the agenda today - so we can go ahead and get started
16:03:09 <lbragstad> #topic global roles
16:03:36 <lbragstad> knikolla: and i met on monday to go through the existing PoC that's up
16:04:01 <lbragstad> and we came up with a road map of what needs to happen to get it into PoC shape for the PTG
16:04:07 <lbragstad> we documented it here
16:04:10 <lbragstad> #link https://etherpad.openstack.org/p/keystone-global-roles-poc
16:04:16 <cmurphy> o/
16:04:35 <lbragstad> I'll be working on step 1 this week and my goal is to have the refactor passing tests by EOW
16:05:05 <lbragstad> knikolla: plans to jump in and help out once RC2 is out the door - which will be EOW as well
16:05:33 <lbragstad> if there is anything you'd like to add to the etherpad that improves the PoC - let me know
16:05:40 <lbragstad> or if the work sounds interesting and you want to help out
16:05:49 <lbragstad> let me know - i'm happy to coordinate
16:06:01 <edmondsw> tx lbragstad
16:06:18 <lbragstad> yep! i'm looking forward to the work
16:06:25 <edmondsw> I'll look over the etherpad today
16:06:31 <lbragstad> edmondsw: thanks
16:07:47 <lbragstad> #topic policy at the PTG
16:09:30 <lbragstad> i have a dedicated time setup at the PTG to help projects with moving policy into code
16:09:40 <lbragstad> if you're project needs help here - let me know
16:09:45 <lbragstad> or sign up on the etherpad
16:10:05 <lbragstad> #link https://etherpad.openstack.org/p/policy-queens-ptg
16:10:42 <lbragstad> Still waiting on a room assignment - but this will most likely be happening on the cross-project days (monday and tuesday)
16:11:20 <lbragstad> #topic open discussion
16:11:32 <lbragstad> floor is open
16:14:00 <edmondsw> lbragstad added a couple more questions in the global roles etherpad
16:14:00 <lbragstad> looks like we can get some time back - thanks for coming!
16:14:10 <lbragstad> edmondsw: ack
16:14:15 <lbragstad> edmondsw: want to discuss them here?
16:14:20 <edmondsw> up to you
16:14:24 <lbragstad> we have the time
16:14:43 <edmondsw> sure
16:15:21 <edmondsw> 4.1... you say "new attribute to olso.policy"... but 4 is supposed to be nova changes (3 is oslo.policy), so that seems out of place or misworded
16:15:40 <lbragstad> yeah - it probably is, trying to think of what made me justify that
16:15:52 <lbragstad> now that i think about it
16:15:57 <edmondsw> feel free to remove my question when you clean it up
16:16:00 <lbragstad> nova work probably means hacking around the scope check?
16:16:27 <lbragstad> or making it so nova consumes the proper attributes from oslo.policy/oslo.context?
16:16:43 <edmondsw> nova work might be fairly involved, at least for a full implementation... maybe just fix a few things for a demo
16:16:55 <lbragstad> yeah - that's what i was thinking
16:17:07 <lbragstad> i wouldn't be surprised if that turned into a rabbit hole
16:17:24 <edmondsw> remember they have their main scope check buried in a non-obvious place in the db code
16:17:28 <lbragstad> so maybe part of that is figuring out "just how much you have to muck with nova to get the demo to work"
16:17:36 <edmondsw> yeah :)
16:18:43 <lbragstad> edmondsw: maybe that's not entirely bad
16:18:48 <lbragstad> i mean - sure
16:18:56 <lbragstad> validation should probably not be done in the database,
16:19:11 <lbragstad> but there is nothing preventing us from short-circuiting the check in higher layers
16:19:16 <edmondsw> yeah, we'll have to see... might give you one place to change, if you can figure out how
16:19:30 <lbragstad> yeah
16:19:43 <edmondsw> well not one... there are others... that's the main one though
16:20:16 <edmondsw> and what about using observer in the demo? We don't have an observer role defined in any policy yet, so are you going to do a bunch of custom policy to show that?
16:20:26 <edmondsw> seems like you might want to just stick to admin and member for this demo
16:21:15 <lbragstad> edmondsw: i wasn't planning on doing a bunch of policy changes - i was more or less writing an outline for what would be an effective demo
16:21:21 <edmondsw> otoh, customizing policy to create an observer role shouldn't be too hard
16:21:28 <lbragstad> (because everyone seems to really gravitate towards the observer role case)
16:21:39 <edmondsw> yep, definitely
16:21:57 <lbragstad> i figured using that would help people understand how things work since they already have a solid understanding of it because they want it
16:22:28 <edmondsw> definitely.. just making sure you realize there is work to be done there that has nothing to do with global scope really
16:22:42 <edmondsw> would totally be useful if we did that work
16:22:43 <lbragstad> right - it's something that helps illustrate the global scope thing
16:23:12 <lbragstad> "if i apply the observer role global, Bob should be able to see all instances across all projects"
16:23:38 <lbragstad> s/global/globally/
16:23:58 <edmondsw> yep
16:25:23 <lbragstad> edmondsw: good last point
16:25:37 <lbragstad> yes - it will require a migration
16:25:40 <lbragstad> (role migration)
16:25:50 <lbragstad> maybe show before and after?
16:26:13 <lbragstad> this is Bob and Bob has an admin role on a project - which unfortunately gives him god-mode everywhere
16:26:47 <lbragstad> then explain that Bob needs the admin role scoped globally to maintain the things he needs to do to admin his cloud
16:27:48 <edmondsw> lbragstad yeah, we'll have to talk about backward compat, which probably means opt-in
16:27:57 <lbragstad> if a user has admin on a project but shouldn't be doing things globally - then they get fixed automatically
16:28:09 <lbragstad> yeah
16:28:22 <edmondsw> and interop
16:28:31 <lbragstad> about 5.6.2
16:28:44 <lbragstad> that's going to require rework in each of the services
16:28:58 <edmondsw> yep, totally
16:29:11 <lbragstad> each project needs to go through and rework their classification of an operation to fit into multiple scoped
16:29:12 <lbragstad> scopes*
16:29:17 <edmondsw> not sure if you want to try to do a little of that to demo it here or leave that for later
16:29:33 <lbragstad> if someone is trying to create an instance using a globally scoped token, nova should catch it in validation and reject it
16:29:49 <edmondsw> only if we decide we don't want to allow that
16:30:05 <lbragstad> i'll defer to the nova folks
16:30:11 <lbragstad> since i assume they have more stake in that
16:30:19 <edmondsw> we could also decide that we do want to allow it, and just make the caller pass the project_id in the POST body
16:30:19 <lbragstad> since it would break backwards compatibility
16:30:41 <edmondsw> the new attribute would just require a new microversion
16:31:18 <lbragstad> we typically had a pretty hard stance on not having certain things floating around globally
16:31:58 <lbragstad> (that also seems to introduce new edge cases in limits and quotas)
16:32:09 <edmondsw> what do you mean?
16:32:31 <lbragstad> what if you have instances that are owned globally (not associated to a project)
16:32:40 <edmondsw> I'm not suggesting you be able to create something that's global... rather than you can create something that's scoped to a project using a token that is scoped globally
16:32:48 <lbragstad> ohh
16:32:51 <lbragstad> nevermind
16:32:54 <edmondsw> just like you can view something that's scoped to a project using a token that's scoped globally
16:33:17 <lbragstad> yeah - we can totally bring that up to the projects at the ptg
16:33:36 <lbragstad> that might help ease the token scope confusion problem
16:33:39 <edmondsw> lbragstad reworded to clarify
16:34:01 <lbragstad> (do i need a project scoped token to do X or do i need a globally scoped token?)
16:34:14 <edmondsw> exactly
16:34:49 <lbragstad> that also might be answered by a capabilities endpoint after 3.3 is done
16:34:50 <edmondsw> talking to our UI guys (PowerVC has a custom UI, not horizon), they hate the idea of having to get a different token for each project in order to present a global view
16:35:04 <lbragstad> yeah
16:35:13 <lbragstad> i think horizon feels the same way
16:35:22 <edmondsw> I would expect so
16:35:41 <lbragstad> but gyee mentioned the pain of having to constantly wonder what the required scope is for an opertion
16:35:44 <lbragstad> operation*
16:36:03 <lbragstad> 3.3 might fix that for us with a consistently exposed endpoint
16:36:14 <edmondsw> what's happening with 3.3?
16:36:19 <edmondsw> what's 3.3?
16:36:33 <lbragstad> i think i figured out why i put that under nova owrk
16:36:36 <lbragstad> let me grab an example
16:37:54 <lbragstad> #link https://github.com/openstack/keystone/blob/master/keystone/common/policies/endpoint.py#L18-L23
16:38:02 <lbragstad> what if we added something ^ there to do this:
16:38:36 <lbragstad> http://paste.openstack.org/show/618561/
16:38:57 <lbragstad> which would render the scope for a given api with the documentation or sample policy files
16:39:12 <lbragstad> but it would also make the scope available to advertise through a capabilities api
16:40:11 <lbragstad> libraries and clients would be able to programmatically determine what scope is required for an operation by inspecting the document provided by a capabilities API
16:40:37 <edmondsw> I was rather thinking we avoid the issue by not limiting APIs to a specific scope
16:41:09 <edmondsw> e.g. the create thing... let folks create using a token with either project or global scope
16:41:47 <edmondsw> the thing they're creating might still be project-scoped... maybe what you're suggesting comes in there?
16:42:13 <lbragstad> well - today the project is pulled from the token in those cases
16:42:25 <edmondsw> right... and I would assert we need to fix that
16:42:54 <lbragstad> ah
16:43:03 <edmondsw> making people get tokens scoped a certain way to do certain things is onerous and unnecessary
16:43:12 <edmondsw> (or rather, should be unnecessary)
16:43:33 <lbragstad> this would add another condition to scope checking
16:43:50 <lbragstad> but i understand the usability arguments
16:43:58 <edmondsw> you should be able to do or not do things based on your role and whether the scope of what you're trying to do is equal to or within the scope of your token, period
16:44:26 <edmondsw> then you don't need to be making statements about scope for every individual API
16:44:55 <edmondsw> and the UI teams will cheer! :)
16:44:56 <lbragstad> the only thing about that statement that doesn't apply today is the "within" bit
16:45:18 <edmondsw> right... because we don't have global roles yet
16:45:23 <edmondsw> so it didn't apply
16:45:26 <edmondsw> but now it will
16:45:52 <lbragstad> ok - counter argument
16:46:05 <lbragstad> once all this stuff is working and inplace
16:46:17 <lbragstad> does this make compromised admin-tokens too dangerous?
16:46:29 <edmondsw> more than they already are? no
16:46:40 <edmondsw> the opposite, actually
16:46:42 <lbragstad> hence the already working part
16:47:09 <lbragstad> (one of the arguments i've heard for scoping is that it limits the damage of a compromised token to a single project)
16:47:31 <edmondsw> today, a compromised admin token won't let you create except in one project, sure, but it will let you view/update/delete in all, and those things are worse
16:48:16 <lbragstad> but a compromised admin token are all of what we discussed is in place, would allow someone to create instances anywhere
16:48:33 <edmondsw> tomorrow, with global roles and ability to create with such, yes, a compromised global admin token will be slightly more powerful (can create) but that's only negligibly worse because view/update/delete are the things you really worry about first and foremost
16:49:04 <edmondsw> and you'll have far fewer such tokens than project-scoped admin tokens, so the chances of compromise are reduced
16:49:47 <edmondsw> if someone can delete things but can't create, I don't feel any better than if they could both delete and create
16:50:05 <edmondsw> I'll say "they can delete! nooooo!!!"
16:50:18 <edmondsw> and forget about create
16:50:20 <edmondsw> :)
16:50:42 <edmondsw> lbragstad right?
16:50:47 <lbragstad> yeah - that makes sense
16:51:05 <lbragstad> i need to ponder this a bit more
16:51:08 <edmondsw> sure
16:51:19 <lbragstad> i like how it eases usability of scoping though
16:53:08 <lbragstad> edmondsw: anything else on the etherpad you want to cover?
16:54:08 <edmondsw> I think that's it for now... thanks for this!
16:54:26 <lbragstad> yeah - i hope it helps get things in order to the PTG
16:54:38 <lbragstad> i'd say if we get through 5 - we're doing well
16:54:46 <edmondsw> very
16:55:03 <lbragstad> cool - anything else for open discussion?
16:55:04 <edmondsw> and, with a short agenda, we took the full hour :)
16:55:09 <lbragstad> i know it
16:55:13 <lbragstad> kinda nice
16:55:27 <lbragstad> edmondsw: do we want to save bringing this up to the nova folks until the ptg?
16:55:31 <lbragstad> the project_id thing?
16:55:41 <edmondsw> for create APIs?
16:55:56 <lbragstad> i was debating a thread to kickstart policy discussions
16:56:09 <edmondsw> yeah, without johnthetubaguy there I don't know how interested the rest are in all this
16:56:18 <lbragstad> hoping it will help us be more productive while we're in denver
16:56:45 <lbragstad> johnthetubaguy: is supposedly going to be in Denver
16:56:54 <edmondsw> it shouldn't hurt to throw something on the ML and see if we get any response
16:57:08 <edmondsw> awesome
16:57:16 <lbragstad> ok - i'll mention it when i start spamming folks about policy early next week
16:58:09 <lbragstad> alright - just about out of time
16:58:15 <lbragstad> thanks for the discussion!
16:58:17 <lbragstad> #endmeeting