18:00:02 <lbragstad> #startmeeting keystone
18:00:03 <openstack> Meeting started Tue Sep 26 18:00:02 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:07 <openstack> The meeting name has been set to 'keystone'
18:00:08 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:00:21 <lbragstad> ping ayoung, breton, cmurphy, dstanek, edmondsw, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, lwanderley, notmorgan, rderose, rodrigods, samueldmq, spilla, aselius, dpar
18:00:23 <knikolla> o/
18:00:26 <hrybacki> o/
18:00:27 <gagehugo> o/
18:00:28 <spilla> o/
18:00:32 <rodrigods> o/
18:00:53 <kmalloc> o/
18:01:26 <raildo> o/
18:01:38 <lbragstad> we'll give it a minute for folks to join
18:01:46 <lamt____> o/
18:02:48 <lbragstad> alrighty
18:02:53 <lbragstad> #topic announcements: trello
18:03:01 <lbragstad> #link http://lists.openstack.org/pipermail/openstack-dev/2017-September/122627.html]
18:03:05 <lbragstad> #undo
18:03:06 <openstack> Removing item from minutes: #link http://lists.openstack.org/pipermail/openstack-dev/2017-September/122627.html]
18:03:07 <lbragstad> #link http://lists.openstack.org/pipermail/openstack-dev/2017-September/122627.html
18:03:12 <lbragstad> #link https://trello.com/b/5F0h9Hoe/keystone
18:03:26 <lbragstad> i made a bunch of updates to the trello board and attempted to fill in details
18:03:35 <lbragstad> if something isn't clear, please let me know
18:03:38 <hrybacki> thanks lbragstad
18:03:53 <gagehugo> nice
18:04:11 <lbragstad> also - i'm open to suggestions
18:04:31 <hrybacki> I'm curious if folks have been using it?
18:04:48 <lbragstad> i have, but that's probably obvious with the updates i've been making
18:04:49 <edmondsw> o/
18:05:23 <lbragstad> it feels really nice to actually have things documented somewhere - i'll say that for sure
18:05:31 <hrybacki> +1
18:05:43 <knikolla> beats a spreadsheet
18:05:46 <hrybacki> and I will say that Trello excels at asynch communication that is easy to digest after the fact
18:05:53 <lbragstad> right
18:06:14 <hrybacki> I'm happy to give a 'Trello Training' session for anyone that hasn't used it before and would like one
18:06:21 <lbragstad> i'm hoping it works out for us this release
18:06:30 <lbragstad> hrybacki: i'm up to learn some new tricks
18:06:50 <lbragstad> i used it a bunch last year - but i'd consider my usage to be fairly primitive
18:06:55 <hrybacki> Cool -- hand me an action to prep a quick session
18:07:13 <lbragstad> #action hrybacki to plan a "Trello Training" session
18:07:18 <hrybacki> maybe tie that into office hours in a week or two?
18:07:26 <lbragstad> yeah - that's a good idea
18:07:37 <lbragstad> a post to the mailing list would be good
18:07:45 * hrybacki nods
18:07:50 <lbragstad> we could do it right after the meeting
18:07:55 <hrybacki> yeah
18:08:29 <lbragstad> cool - that's all i have there, anyone else have things related to trello?
18:08:56 <lbragstad> #topic announcements: sydney forum sessions
18:09:06 <lbragstad> the deadline for topic submissions is in a few days
18:09:17 <lbragstad> i've started an etherpad to start brainstorming sessions
18:09:24 <lbragstad> #link https://etherpad.openstack.org/p/SYD-keystone-forum-sessions
18:09:55 <lbragstad> If folks want to give that a once over and post anything there I can submit formal proposals for it before the 29th
18:10:00 <lbragstad> anyone have thoughts?
18:10:21 <lbragstad> for reference - this was the etherpad we used for Boston https://etherpad.openstack.org/p/BOS-Keystone-brainstorming
18:10:51 <gagehugo> do we want another consumable keystone forum session?
18:11:13 <lbragstad> we could - that makes a bit more sense with JWT
18:11:18 <hrybacki> ftr I will not be funded to attend Sydney. But I'm saving for the next PTG in case I lack company funding for that as well
18:11:52 <lbragstad> hrybacki: ack - you can also apply for travel support, the foundation is good about that
18:11:58 <lbragstad> i used the program for Boston
18:12:12 <hrybacki> lbragstad: I'll ping you about that after meeting
18:12:22 <kmalloc> I will also not be in SYD.
18:12:42 <edmondsw> lbragstad I just got travel approval
18:14:47 <rodrigods> i will be there! :)
18:15:04 <lbragstad> regardless of being able to go - if you want things represented or done in Sydney, let me know and i'll make a point to represent it when i'm there
18:15:29 <hrybacki> lbragstad++
18:15:45 <lbragstad> I'll leave the etherpad open for a day and start submitting topics tomorrow
18:16:27 <lbragstad> sorry about not getting this out soon - it kinda crept up on me
18:17:57 <lbragstad> I'll followup with an email after the meeting, too
18:18:02 <lbragstad> #topic open discussion
18:18:04 <lbragstad> floor is open
18:19:12 <lbragstad> reminder that we do have office hours today
18:19:18 <lbragstad> starting in about 40 minutes
18:19:40 <ayoung> lbragstad, we in the open discussion part of the  meting?
18:19:42 <ayoung> meeting
18:19:50 <lbragstad> ayoung: yes we are
18:20:03 <ayoung> So,  question on the decision to pull support for RBAC in middleware
18:20:18 <ayoung> I only caught it in cmurphy 's blog update.  THanks cmurphy!
18:20:52 <ayoung> I'd argue that  before you pull it, you need to specify how you are going to replace it, and solve the problems that it addresses
18:21:33 <ayoung> I'm willing to support any plan that active works toward solving the problem of discoverability, but I have yet to hear anyone else propose one.  Was there any such discussion?
18:21:54 <lbragstad> you want an answer to "what can I do with this token" right?
18:22:17 <ayoung> lbragstad, so,  I would not quite phrase it that way
18:22:39 <ayoung> lbragstad, I would more phrase it as "I need to set up a service to do X, what roles do I need to grant to them in order to do it"
18:23:08 <lbragstad> i think both of those can be addressed using a capabilities API
18:23:10 <ayoung> so, while that would also cover what you say, It is only a subset of the use cases.  But, yes, that is one of them
18:23:39 <edmondsw> ayoung I think there are different answers for different use cases that you care about
18:24:12 <lbragstad> i remember someone in the room bringing up a security concern somewhere in that discussion, too
18:24:21 <lbragstad> i can't remember if that was kmalloc? jamielennox?
18:24:25 <edmondsw> one answer is pluggable oslo.policy, e.g. for Apache fortress
18:24:47 <ayoung> lbragstad, so capabilities I've heard as supporting "what resources  does this service provide"  like different hypervisors etc.  How would the capabilities API work for this?
18:24:52 <edmondsw> lbragstad I think it was both of them
18:25:14 <kmalloc> ayoung: i'd bake the representation into the service via oslo.policy's code
18:25:18 <ayoung> edmondsw, policy does not provide a way to map them from URL to policy.  My guess is capabilites is also going to have this problem?
18:25:19 <kmalloc> middleware is the wrong place to put it
18:25:28 <kmalloc> middleware is already doing too much
18:25:36 <ayoung> kmalloc, oslo.policy does not know about the URL, though.
18:25:40 <lbragstad> ayoung: let me find a spec - it framed the purpose and direction of capability apis
18:25:40 <kmalloc> or middleware can expose oslo.policy directly
18:25:45 <kmalloc> middleware DOESNT either really.
18:25:56 <edmondsw> ayoung we are documenting URLs tied to policy rules... community-wide goal for queens
18:26:42 <ayoung> OK...so the answer is "we will have a static mapping of URLS to Policy rules, an then a way to query the policy rules (and more) via the capabilites API"
18:26:44 <edmondsw> but maybe I don't understand what you're after there
18:26:56 <kmalloc> ayoung: that would be the way i'd push
18:27:14 <ayoung> Are we going to query each service for the capabilites?
18:27:18 <kmalloc> yep.
18:27:26 <kmalloc> keystone cannot be the centralized source for it
18:27:38 <kmalloc> it runs into all the headaches we ran into trying to move policyt int our api
18:27:54 <lbragstad> kmalloc: did you have the concern about exposing roles for APIs?
18:28:11 <kmalloc> i'm throwing in the towel on centralizing that, it is a ton of headaches and with many issues on updates, signaling, services being aware, etc
18:28:19 <ayoung> so the one problem I see with this is that the definition of roles is managed in the keystone server.  Are we just going to make the set of roles static?
18:28:33 <kmalloc> ayoung: we are moving towards guaranteed roles
18:28:35 <lbragstad> no - not necessarily
18:28:36 <kmalloc> some*
18:28:49 <kmalloc> not all static, but some roles will be guaranteed, otherwise ask the services.
18:28:49 <lbragstad> i have an idea there - but i haven't had the opportunity to write it down yet
18:29:26 <ayoung> one goal in my design was to be able to split a big role into smaller roles, and allow delegation of the smaller role only.  Will this information make its way out to the remote services?
18:29:27 <kmalloc> capabilities should be unprotected, and we can report what role(s) are needed for capability x
18:29:45 <kmalloc> depends on the expansion
18:29:56 <kmalloc> if the expansion is done on the remote end, sure
18:29:59 <lbragstad> but we should also be able to ask a service "what can I do with this token?"
18:30:01 <kmalloc> if not, no. not for the moment
18:30:08 <kmalloc> lbragstad: sure. that is fine.
18:30:18 <lbragstad> cool
18:31:26 <ayoung> "What can I do with this token" is pretty easy if the capabilities are statically published
18:31:40 <kmalloc> ayoung: that is the idea
18:31:42 <lbragstad> well
18:31:43 <lbragstad> kinda
18:31:49 <ayoung> Horizon (the primary consumer of that feature) can deduce it from the data provided
18:31:51 <kmalloc> we could do the calculation for you as well on that page
18:31:51 <lbragstad> part of that depends on how the service is configured
18:32:06 <kmalloc> s/page/api
18:32:38 <lbragstad> so you could consider the role -> permission policies as a super set that can be pruned down to a more specific answer based on the configuration of the service
18:33:16 <ayoung> OK...so walk me through how I would tell an operator to do the following.  Lets say compute:reboot_server is a policy that falls behind the actions API, and we have it set to use the "expecte" role of "Member"
18:33:22 <lbragstad> (e.g. i might have the role that allows me to live migrate instance but i can't actually live migrate instances because nova isn't configured to use a virt driver that supports it)
18:33:38 <ayoung> and we want to make a new role or permission or whatever you call it, that can only pass that one policy check
18:34:28 <ayoung> assuming we've created the role in keystone and set up an inference rule that lets Member imply rebooter, we would then have to update the policy on the compute nodes that enforce that, right?
18:34:43 <kmalloc> ayoung: correct
18:34:59 <kmalloc> if only "Rebooter" can do that
18:35:08 <ayoung> kmalloc, not Only
18:35:18 <ayoung> kmalloc, rebooter can ONLY dothat, but so can Member and Admin
18:35:30 <ayoung> Member and Admin can do that plus more
18:35:32 <edmondsw> ayoung you would either a) customize policy for that one rule to make it "role:Member or role:mynewthang" instead of just "role:Member" or b) make it "role:mynewthang" and setup the roles in keystone such that Member implies mynewthang
18:35:46 <kmalloc> edmondsw: thanks that was what i was going for
18:36:33 <ayoung> OK, so that still leaves the problem that people need to be able to safely customize rules like that, but should not touch the scope check
18:36:52 <ayoung> are we counting on the multiple-layers of policy files to help split those two things apart?
18:36:55 <kmalloc> scope check is def. on the list to push down into the services in a better way.
18:36:57 <edmondsw> scope checks need to move into code, so they won't be *able* to touch them
18:37:10 <lbragstad> right - i'm working on that this release
18:37:12 <lbragstad> fwiw
18:37:15 <kmalloc> basically, we're baking the scope check into code and representing that better in the policy-in-code definitions
18:37:23 <kmalloc> do policy can'
18:37:28 <kmalloc> t be broken on those lines
18:37:29 <lbragstad> i plan to draft a community goal for rocky that helps achieve that across openstack
18:37:37 <edmondsw> +1000
18:37:49 <kmalloc> we have some changes in osol.policy nbeeded to make it happen
18:37:54 <kmalloc> but it's a low barrier
18:38:02 <lbragstad> yeah - i'm going to be getting to those today
18:38:05 <ayoung> and scope check is going to bake in the rule for is_admin_project or the Global-roles-like-thing that is going to replace it
18:38:06 <kmalloc> and i think we have a good path forward on it based upon the PTG
18:38:16 <kmalloc> ayoung: in the definition within nova
18:38:44 <kmalloc> saying "X action is scope-required to project and then nova will be able to say object.owner==scope
18:38:50 <kmalloc> it's a different policy-enforcement point
18:38:58 <kmalloc> we have 3 levels of checking (in 2 checks) now
18:39:07 <lbragstad> 3?
18:39:13 <lbragstad> project, system, and?
18:39:13 <kmalloc> 1) role check, 2) scope-type check (project)
18:39:20 <kmalloc> and the last is the ownership check
18:39:25 <lbragstad> oh - nevermind
18:39:27 <kmalloc> 1 and 2 are enforcement point 1
18:39:28 <lbragstad> different page
18:39:43 <kmalloc> and the ownership check is done once the data is loaded from the db.
18:39:56 <lbragstad> yep
18:39:58 <lbragstad> ok
18:40:17 <ayoung> scope-type can be done prior, but the actual scope check is part of the ownership check?
18:40:26 <kmalloc> scope-type is done with role
18:40:39 <kmalloc> and ownership is "token.scope == resource.owner"
18:40:46 <kmalloc> sorry token.scope.id
18:41:11 <kmalloc> nova has to do the scope check itself
18:41:16 <ayoung> I'm not clear on what you mean by scope-type done with a role
18:41:25 <kmalloc> scope-type: project, domain, system
18:41:32 <lbragstad> so - think of role check as two smaller checks
18:41:37 <lbragstad> does the role match the operation
18:41:51 <ayoung> so scope type is role irrelevant.  It is done based on resource, right?
18:41:55 <lbragstad> and does the token being used have a construct that represents elevated scope
18:41:57 <lbragstad> if needed
18:42:08 <kmalloc> correct
18:42:12 <kmalloc> it is role-irrelevant
18:42:25 <lbragstad> if token.scope == 'system' and policy.scope == 'system'
18:42:33 <lbragstad> for example
18:42:42 <kmalloc> lbragstad: token.scope_type*
18:42:44 <lbragstad> we have to make sure each project enforces that consistently
18:42:52 <lbragstad> kmalloc: yes - thanks
18:43:34 <ayoung> Do we have cases (out side of keystone and domains) where the scope is not going to be on target.project_id?
18:43:53 <lbragstad> you mean 'system'?
18:43:55 <edmondsw> so oslo.policy will bark if token.scope is not in policy.scope, else it will return back nicely and the service needs to limit what the user can do to their token.scope
18:44:21 <kmalloc> nova and/or neutron port mucking might not be the target
18:44:22 <ayoung> I mean, I know Nova used to put that in the URL, but I think that the only scope we have now is project scope.  So, system scope is implicit
18:44:33 <edmondsw> we also talked about a 'region' scope, but that's probably further down the road
18:44:36 <kmalloc> in the case of global things (or glance in the case of global/public images)
18:44:50 <lbragstad> live migration is a good example of system scope
18:45:07 <edmondsw> system vs. project will be the primary distinction
18:45:19 <lbragstad> or https://developer.openstack.org/api-ref/compute/#hypervisors-os-hypervisors
18:45:28 <kmalloc> edmondsw: ++
18:45:41 <edmondsw> lbragstad actually, I think we agreed live migration is project scope :)
18:45:50 <kmalloc> edmondsw: it might be both
18:45:50 <lbragstad> doing things with hypervisors would be an example of system level operations since hypervisors don't really belong to projects
18:45:55 <kmalloc> it is an example of "both"
18:45:58 <lbragstad> edmondsw: yeah - it can apply to both
18:46:07 <kmalloc> a lot of nova is both
18:46:18 <edmondsw> not sure I agree there
18:46:19 <kmalloc> but glance public images is a case of "defintely system"
18:46:27 <edmondsw> maybe
18:46:37 <kmalloc> like cloud-wide provider supplied images
18:46:38 <lbragstad> or listing the uptime of a hypervision, i can't think of a way where that makes sense in project scope
18:46:47 <lbragstad> hypervisor*
18:46:48 <kmalloc> or adjusting hypervisor values.
18:47:04 <ayoung> OK,  this is fine.  Can someone be on the hook to write this up?
18:47:13 <kmalloc> ayoung: lbragstad has a lot of the info.
18:47:18 <lbragstad> that's already on me
18:47:23 <lbragstad> and i've started that work
18:47:26 <kmalloc> and i think hrybacki has some of the details/pictures
18:47:29 <kmalloc> from the PTG
18:47:39 <lbragstad> i'll be breaking that into two separate specs for oslo.policy
18:47:49 <hrybacki> #link https://etherpad.openstack.org/p/queens-PTG-keystone-policy-roadmap
18:47:56 <hrybacki> pics are towards the bottom
18:48:28 <ayoung> lbragstad, sounds good.  I'll keep pushing at it to see if we can find holes, but my biggest concern is that it depends on the projects implementing it.  Are there project reps tagged to do the capabilites work?
18:48:43 <kmalloc> ayoung: community goal in rocky
18:48:50 <kmalloc> same as policy-in-code is for queens
18:48:57 <lbragstad> which i will likely champion unless others want to help out
18:49:07 <kmalloc> the projects have been good at getting it done once we have a champion and agreement from the TV
18:49:09 <kmalloc> TC*
18:49:40 <lbragstad> current progress https://www.lbragstad.com/policy-burndown/
18:49:48 <lbragstad> #link https://www.lbragstad.com/policy-burndown/
18:50:24 <lbragstad> ten minutes left - anyone else have something they'd like to talk about?
18:51:52 <lbragstad> cool - let's get some time back before office hours starts
18:51:58 <lbragstad> thanks everyone!
18:52:00 <lbragstad> #endmeeting