16:00:12 <lbragstad> #startmeeting policy
16:00:16 <openstack> Meeting started Wed Mar  8 16:00:12 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:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:20 <openstack> The meeting name has been set to 'policy'
16:00:23 <lbragstad> ping antwash, raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung, ravelar, morgan, raj_singh, johnthetubaguy, knikolla
16:00:24 <knikolla> o/
16:00:39 * johnthetubaguy lurks in a probably not very active way
16:00:53 <lamt> o/
16:00:58 <lbragstad> o/
16:01:00 <ayoung> oyez
16:01:02 <gagehugo> o/
16:02:51 <lbragstad> agenda #link https://etherpad.openstack.org/p/keystone-policy-meeting
16:02:55 <lbragstad> edmondsw you have the first topic on the list and it was a carry over thing from several meetings ago
16:03:08 <lbragstad> edmondsw do you still want to cover those things?
16:03:44 <edmondsw> was this the question of which policy checks need more than just project scope?
16:03:54 <edmondsw> i.e. user scope
16:04:09 <lbragstad> #topic Work through 0.2% of use case granularity
16:04:24 <rderose> o/
16:04:25 <lbragstad> Context #link http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-cp/%23openstack-meeting-cp.2017-02-08.log.html#t2017-02-08T16:51:13
16:04:27 <edmondsw> yeah, ok
16:04:41 <edmondsw> so one of the cases I already spoke to johnthetubaguy about, commented in his spec
16:05:18 <edmondsw> one sec, let me find it
16:06:20 <edmondsw> come back to me?
16:06:24 <ayoung> OK...so this is trying to come up with common groupings of policy?
16:06:35 <ayoung> The way I explained it in the past is this:
16:06:36 <edmondsw> ayoung no
16:07:00 <ayoung> "	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:07:23 <edmondsw> different discussion
16:07:33 <ayoung> oh...so missing the context from the link
16:07:40 * johnthetubaguy is confused about what the question is
16:08:07 * ayoung too
16:08:09 <lbragstad> this was a discussion we had several meetings ago - but it keeps getting bumped
16:08:23 <ayoung> What does this 2% refere to?
16:08:31 <ayoung> 0.2%?
16:08:40 <edmondsw> cases where you customize list and show differently
16:08:51 <lbragstad> from what i remember edmondsw had some cases that needed some extra granularity
16:08:57 <ayoung> isn't that what I just said?
16:09:41 <edmondsw> so I'm remembering one now... this nova API: https://developer.openstack.org/api-ref/compute/#usage-reports-os-simple-tenant-usage
16:09:43 <ayoung> OK....so to start the disccusion, we mean "by default GET and LIST have the same policy, but sometimes you want to split them" ?
16:10:00 <ayoung> agreed>
16:10:01 <ayoung> ?
16:10:08 <knikolla> aren't they different apis?
16:10:20 <edmondsw> the other examples are in keystone... e.g. when you want to let someone get a user (themselves) but not list users
16:10:42 <ayoung> OK...so here is how I would explain it:
16:10:53 <ayoung> at the lowest level, we have roles mapped to individual APIs
16:11:06 <ayoung> at the highest level we have the users organizational position
16:11:12 <ayoung> in the middle we have workflows
16:11:18 <ayoung> in english:
16:11:49 <ayoung> A user needs permission to access specific APIs to perform workflows specific to their organizational role
16:11:53 <edmondsw> knikolla yes, but the proposal was to have list and show APIs use the same policy check. The question was then where that wouldn't work
16:12:05 <lbragstad> edmondsw ++
16:12:09 <lbragstad> yeah - that was it
16:12:25 <edmondsw> sorry, took me a minute to access that cache
16:12:51 <knikolla> i see
16:12:53 <ayoung> so, by default, no role check is done right now except for Admin in almost all APIs
16:13:10 <edmondsw> ayoung wrong
16:13:12 <ayoung> some service user stuff, some bad anti-checks in Heat, I think, but for the most, just Admin or "any role will do"
16:13:25 <ayoung> edmondsw, has it been rewritten in the past month?
16:13:44 <edmondsw> ayoung oh, ok, you're right... if you discount customization
16:13:54 <edmondsw> my bad, carry on
16:13:57 <ayoung> cool
16:14:31 <ayoung> OK, so now, customization might do anything possible within the current scope of policy, I don't think we can really change those rules
16:15:00 <ayoung> so this is one of the places that really calls for the RBAC check to be separate from, and more customizable from, the scope check
16:15:20 <ayoung> by default, we can say "any role for scope"  will continue to pass.
16:15:26 <edmondsw> which we're doing...
16:15:34 <ayoung> but, if you want to customize, then you set explicit roles for APIs
16:15:44 <ayoung> and this is what I want to split out.
16:15:55 <ayoung> Implied roles make it eaiser, too, to move forward
16:15:59 <edmondsw> I don't think we really have a problem here
16:16:06 <ayoung> for example, say you have a "reader" role that can do bot get and list
16:16:20 <ayoung> and then you realize you need get to be more restrictive, that some users should only have get
16:16:30 <edmondsw> the scope check moving into code as johnthetubaguy and I worked out will be able to handle these odd .2% cases
16:16:33 <ayoung> you create a new role for that, and then have reader imply get
16:16:46 <edmondsw> no need for implied roles here, either
16:16:46 <ayoung> excellent
16:16:51 <lbragstad> cool
16:16:55 <lbragstad> so - moving on
16:16:58 <ayoung> nah, the implied roles is for the operator to make things smooth
16:16:59 <lbragstad> everyone good?
16:17:42 <ayoung> implied roles means that you can keep everything working the way it does now, but in the future, you can assigne the more specific role only, where applicable. All good?
16:17:49 <lbragstad> i'm good
16:18:02 <edmondsw> well...
16:18:02 <lbragstad> i also want to get to the next topic because I'm super curious about it
16:18:07 <lbragstad> ;)
16:18:47 <edmondsw> so taking a small step back... we would have separate checks for list and get in those .2% cases, but could combine them everywhere else... and that ok?
16:19:18 <ayoung> edmondsw, you are scaring me
16:19:28 <ayoung> the APIs should all be separate
16:19:39 <ayoung> or are you talking about a single API that can handle filters?
16:19:54 <edmondsw> talking about list vs get APIs
16:20:05 <ayoung> edmondsw, separate APIs stay separate
16:20:14 <edmondsw> nope
16:20:16 <ayoung> single APIs might need to be split
16:20:18 <edmondsw> not what we'd agreed
16:20:26 <ayoung> edmondsw, I didn't agree on anything
16:20:36 <edmondsw> no, you didn't ;)
16:20:47 <ayoung> edmondsw, if you might want to be able to vary them independantly, at any point, keep them separate
16:20:53 <ayoung> its easy to merge, hard to split
16:21:03 <ayoung> easy-> can be done by operator
16:21:14 <edmondsw> this isn't a case where you might want to split them later
16:21:15 <ayoung> hard->won't happen
16:21:22 <edmondsw> that's kinda the point
16:21:31 <ayoung> then why are they separate APIs?
16:21:51 <edmondsw> you're asking why list and get are separate APIs?
16:22:18 <ayoung> yep
16:22:33 <ayoung> separate use cases
16:22:37 <edmondsw> seems a bit obvious...
16:23:09 <ayoung> edmondsw, we talking role check or just scope check here?
16:23:22 <edmondsw> johnthetubaguy proposed that we compress these. If you have a reason not to, explain it
16:23:24 <edmondsw> role check
16:24:07 <johnthetubaguy> compress what? sorry I lots track
16:24:11 <johnthetubaguy> lost
16:24:17 <ayoung> yeah, so instead of messing around here, please just go with the Role check from middleware
16:24:20 <edmondsw> policy checks for get vs. list
16:24:30 <ayoung> scope check in code is great
16:24:33 <ayoung> make that happen
16:24:55 <lbragstad> 6 minutes left for this specific topic
16:24:55 <johnthetubaguy> well, step one for me is scope check in code, lets do that first
16:25:00 <ayoung> Yesss
16:25:05 <edmondsw> amen
16:25:09 <johnthetubaguy> cool, so that feels like agreement
16:25:25 <lbragstad> #success there was agreement in a policy meeting
16:25:28 <ayoung> and only scope check...what about is_admin
16:25:42 <ayoung> that seems like it is part of scope check
16:25:49 <ayoung> is_admin_project
16:25:56 <edmondsw> so let's take the simple-tenant-usage case... you'd have a policy check to see if you're allowed to read simple tenant usage, which would be called on both GET /os-simple-tenant-usage and GET /os-simple-tenant-usage/{tenant_id}
16:26:11 <johnthetubaguy> well there is a "global" scope permission
16:26:19 <johnthetubaguy> the question is how do you get that permission
16:26:21 <ayoung> johnthetubaguy, not really
16:26:31 <ayoung> johnthetubaguy, there is admin on this project, and admin on the admin project
16:26:46 <johnthetubaguy> well maybe
16:26:54 <edmondsw> then in the code there would be a scope check where if you're asking for a project outside your current token's scope, or you're asking for all projects, another policy rule would be checked in addition
16:26:54 <johnthetubaguy> ignoring how you define this in keystone
16:27:05 <johnthetubaguy> there is some kind of "global" thing
16:27:17 <edmondsw> is_admin_project=True
16:27:19 <ayoung> johnthetubaguy, nope, this is more than keystone, and no there is not, there is just an open bug
16:27:19 <johnthetubaguy> vs only being able to access things in your porject
16:27:32 <johnthetubaguy> right, and we default that policy to is_admin_project = True right now
16:27:40 <edmondsw> ayoung no, I think you misunderstand... we do have is_admin_project and that's what he's talking about
16:27:58 <johnthetubaguy> from an operator view right...
16:28:07 <johnthetubaguy> I want a user that can read everything in the whole system
16:28:16 <johnthetubaguy> ... OK, so thats global scope, and has the read role
16:28:25 <ayoung> johnthetubaguy, yep, that should be done by getting a role on the admin project.
16:28:32 <johnthetubaguy> oh, so that means a user in the admin project, with the role observer, or some such
16:28:43 <ayoung> you still need to check the scope of the token, just not that it matches the scope of the object from the database
16:28:53 <ayoung> yep
16:29:05 <johnthetubaguy> I think we are violently agreeing here
16:29:10 <edmondsw> yep
16:29:26 <lbragstad> is everyone good to move on?
16:29:30 <edmondsw> I am
16:29:34 <johnthetubaguy> so I have a policy rule to configure what it means to be global right now
16:29:44 <johnthetubaguy> we could hard code that to is_admin_project == True
16:30:02 <edmondsw> ++
16:30:37 <johnthetubaguy> so I am not sure how the backwards compatibility works with that, needs some thought
16:30:49 <lbragstad> johnthetubaguy mind if we circle back?
16:31:00 <ayoung> yeah, so the question I have is whether there are cases now where we are forcing admin_project roles where they should be, at least possible, to be project specific roles, and are we going to be able to do that with this scope check in code approach?
16:31:17 <ayoung> and, this is a Keystone only thing, I think.
16:32:06 <lbragstad> let's table this for now and circle back (possibly offline), i want to give blancos enough time for her topic
16:32:10 <lbragstad> #topci patrole
16:32:17 <lbragstad> blancos gagehugo lamt o/
16:32:20 <blancos> o/
16:32:21 <ayoung> the way I think is_admin_project should work should be that the role needed to perform an operation should be the same if scoped to a project or scoped to the admin_project, and if is_admin+_prioejct is set, that is always honored
16:32:23 <lamt> o/
16:32:33 <edmondsw> lbragstad typo in your topic change
16:32:40 <gagehugo> o/
16:32:48 <ayoung> Pah Troll AY!
16:32:51 <lbragstad> #topic patrole
16:32:52 <lbragstad> edmondsw thanks
16:33:08 <lbragstad> #link https://github.com/openstack/patrole
16:33:23 <blancos> Would you like me to explain it a little bit first or do like a Q&A type of thing?
16:33:28 <lbragstad> blancos go for it
16:33:34 <blancos> Okay :)
16:33:37 <lbragstad> blancos i know i'm curious about it as a whole
16:34:01 <blancos> Patrole is a Tempest plugin for RBAC validation. Internally, we wanted to create some new roles for use in each service with very specific restrictions
16:34:14 <blancos> and we wanted to make sure that these roles and restrictions we created were being properly enforced.
16:34:44 <blancos> For example, we created a role that was only able to read and we wanted to make sure that it was actually only able to read and not write or update, etc.
16:35:12 <lbragstad> nice - so it sounds like there is expected test cases for each role?
16:35:21 <lbragstad> s/is/are/
16:35:50 <blancos> We have one test for each API that isolates that API as much as possible (Nova calls like 10+ different ones to create a server) and run it for each role
16:36:04 <blancos> (New fields are added to tempest.conf)
16:36:56 <blancos> It's really helped us find bugs in policy enforcement in other projects, as well as some irregularities in errors (some services throw 404 instead of 403 when access is denied based on role)
16:37:11 <lbragstad> blancos is this tied into the gate somewhere?
16:37:35 <blancos> We're working on a CI gate for the project, and we talked at the PTG with QA about maybe creating Patrole gates for other projects as well
16:37:46 <lbragstad> blancos that'd be nice
16:38:05 <blancos> I'm guessing that's something Keystone might be interested in then?
16:38:07 <lbragstad> blancos but right now I assume it's just being run locally and bugs are filed manually against the projects?
16:38:14 <lbragstad> blancos yes - i'm interested
16:38:30 <blancos> Yes. And we have some bugs we currently are working through within the project
16:38:36 <blancos> It's still relatively new
16:38:51 <lbragstad> within patrole itself you mean?
16:39:08 <blancos> Yes, but we have a pretty large team actively working on it so they're being worked through
16:39:24 <lbragstad> blancos awesome - how many people are currently working on it?
16:40:30 <blancos> I would say around 15? And of course we're happy to have more people join :)
16:40:37 <lbragstad> wow
16:41:09 <lbragstad> is there a dedicated irc room for patrole or where do most of you hang out?
16:41:40 <blancos> Currently no, but that's something we're looking into as the project grows
16:42:12 <ayoung> blancos, if you make it harder for us to get RBAC in Middleware through because of Tempest tests I will not be happy
16:43:05 <blancos> ayoung I think this is something that would be beneficial as it's specific testing
16:43:24 <lbragstad> ayoung it sounds like it would be making it easier to validate that work
16:43:26 <blancos> And it obviously doesn't apply to all situations
16:43:31 <ayoung> OK, I need to sjhut off the music and concentrate
16:43:57 <ayoung> there is a serious lack of understanding of the problem.  THe RBAC check is half formed at the moment
16:44:14 <ayoung> if you do RBAC checks in Tempest, are you going to do them by running customized policy files?
16:45:08 <blancos> We have multiple checks for where the policies are coming from; the first is a check for custom policy.json
16:45:17 <ayoung> blancos, yeah,. kill that dead with fire
16:45:32 <lbragstad> blancos i guess that's a good question - does patrole setup the new roles and customize policy files?
16:46:06 <lbragstad> blancos on top of a devstack installation or something like that?
16:46:27 <blancos> We're really more of a testing suite; the idea is that the custom policy files would already exist in a deployment and Patrole would check to make sure the actions are being properly enforced
16:46:29 <ayoung> lets stop talking about RBAC checks from policy file.  That is not done by default, it is fragile, and it is only done that way now because it is the only tool
16:46:44 <lbragstad> blancos got it - that makes sense
16:47:04 <lbragstad> blancos so patrole really just expects a set of service endpoints to run against
16:47:14 <blancos> ayoung We also make use of oslo policy checker or, in the case of Nova, defaults in code
16:47:32 <blancos> lbragstad Yes. And if you have custom roles, those roles have to exist within Keystone
16:47:47 <blancos> (For example, the custom viewer role I mentioned earlier)
16:48:03 <lbragstad> blancos cool - so this could be something that could be worked into openstack-ansible or other deployment tools
16:48:28 <ayoung> blancos, would that work with this spec? https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/role-check-from-middleware.html
16:48:38 <blancos> lbragstad Yes I don't see why not
16:48:45 <lbragstad> blancos awesome
16:48:55 <edmondsw> blancos, so how do you actually know what the role is or isn't supposed to do, so that when you test the API calls you can tell if it was appropriately checked or not?
16:49:12 <blancos> ayoung We would most likely have to modify our framework somewhat but yes I don't see why it wouldn't work
16:49:14 <ayoung> this is purely the test side, blancos ?  IE:  set this role, and, in this deployment it should pass.  Set that role, in this deploy it should fail?
16:49:32 <ayoung> blancos, so, the test side is awesome.  It is the custom policy.json files I don't want.
16:49:58 <ayoung> UNderstand my fear?  We've had code that we can't fix due to stringent Tempest testing, and I don't want any more of that.
16:50:13 <edmondsw> ayoung I think he was just saying they'll support that case (which they would have to because that's what we currently have), but not be limited to only supporting that
16:50:18 <blancos> edmondsw We parse the policy.json into a dict and check against it. There are also log statements that tell the test runner x role should or should not be able to do something
16:50:52 <blancos> ayoung I believe I mentioned custom policy files are only one of the things we check against, but we also use other tools
16:51:03 <blancos> And of course we can expand the framework to check against more :)
16:51:35 <edmondsw> blancos so policy is the source of truth. it won't catch mistakes in your policy file, but it will somehow catch issues with code misinterpreting the policy file?
16:51:52 <edmondsw> or, as you said, being inconsistent about what permission denied looks like
16:51:56 <ayoung> blancos, my concern is that in developing the framework, you are going to code against customer JSON files, and that is going to lock us in to those customizations.
16:52:21 <blancos> edmondsw Yes, that's correct
16:52:31 <edmondsw> blancos note that sometimes it's very intentional to return 404 instead of 403 for permission denied... when you don't even want to signal to the caller that what they attempted to target actually exists
16:53:06 <blancos> edmondsw Right we've been talking to other projects about that, but so far they seemed to agree that they preferred a 403 vs. a 404 in those cases
16:53:28 <edmondsw> no no no... can't return 403 in those cases... that's a security vuln
16:54:02 <blancos> edmondsw Sorry, I should've been clearer; so far we've been doing them on a case-by-case basis and in the cases that we've mentioned, they've agreed
16:54:20 <blancos> I don't mean as a sweeping change
16:54:41 <edmondsw> that scares me a bit... there are a lot of folks out there that don't properly appreciate the quirks of security in things like this.
16:55:01 <edmondsw> hopefully they did, and the cases you discussed were really ok, but I wouldn't necessarily bet on that
16:55:14 <blancos> ayoung The dict is rebuilt whenever the tests are run, so if the environment changes (i.e., custom policy file is gone) then the tests will be run with that new information
16:55:16 <lbragstad> i'd be fine if they were all just documented somewhere - then we can at least reason about them independently
16:56:25 <blancos> I know one of my colleagues has been heading that up; if you'd like I can drop the bugs in later
16:56:49 <blancos> (the links, I mean)
16:56:51 <lbragstad> that works for me
16:57:01 <blancos> In the Keystone IRC room?
16:57:05 <lbragstad> ++
16:57:19 <edmondsw> ayoung, I think you'd just be talking about writing a bit of new code in patrole to get role checks from keystone like the middleware would do, and then fallback on their current code if keystone didn't have role check info
16:57:57 <ayoung> edmondsw, I just don't want to be locked in to today's bad decisions, but I've gone from anger to acceptance.
16:58:37 <lbragstad> were about out of time, but I wanted to thank blancos for swinging by and taking the time to field our questions
16:59:18 <blancos> No problem. Happy to spread the word about our project :)
16:59:23 <lbragstad> blancos do keep us posted if there is a dedicated place for us to talk about patrole
16:59:29 <blancos> Will do
16:59:55 <lbragstad> thanks for coming everyone!
16:59:58 <lbragstad> #endmeeting