| *** ducttape_ has quit IRC | 00:00 | |
| *** ducttape_ has joined #openstack-meeting-cp | 00:01 | |
| *** ducttape_ has quit IRC | 00:01 | |
| *** ducttape_ has joined #openstack-meeting-cp | 00:02 | |
| *** ducttape_ has quit IRC | 00:02 | |
| *** ducttape_ has joined #openstack-meeting-cp | 00:02 | |
| *** rdopiera has quit IRC | 00:16 | |
| *** rdopiera has joined #openstack-meeting-cp | 00:18 | |
| *** MarkBaker has joined #openstack-meeting-cp | 00:43 | |
| *** MarkBaker has quit IRC | 01:03 | |
| *** MarkBaker has joined #openstack-meeting-cp | 01:15 | |
| *** MarkBaker has quit IRC | 02:16 | |
| *** reed_ has joined #openstack-meeting-cp | 02:21 | |
| *** MarkBaker has joined #openstack-meeting-cp | 02:33 | |
| *** reed_ has quit IRC | 02:47 | |
| *** ducttape_ has quit IRC | 03:07 | |
| *** diablo_rojo has quit IRC | 03:20 | |
| *** sdague has joined #openstack-meeting-cp | 03:46 | |
| *** gouthamr has quit IRC | 04:00 | |
| *** ducttape_ has joined #openstack-meeting-cp | 04:09 | |
| *** ducttape_ has quit IRC | 04:13 | |
| *** sdague has quit IRC | 04:26 | |
| *** ducttape_ has joined #openstack-meeting-cp | 05:09 | |
| *** ducttape_ has quit IRC | 05:14 | |
| *** ducttape_ has joined #openstack-meeting-cp | 06:10 | |
| *** knangia has quit IRC | 06:11 | |
| *** ducttape_ has quit IRC | 06:15 | |
| *** markvoelker has quit IRC | 06:54 | |
| *** ducttape_ has joined #openstack-meeting-cp | 07:11 | |
| *** ducttape_ has quit IRC | 07:16 | |
| *** ducttape_ has joined #openstack-meeting-cp | 08:12 | |
| *** markvoelker has joined #openstack-meeting-cp | 08:12 | |
| *** Rockyg has joined #openstack-meeting-cp | 08:16 | |
| *** ducttape_ has quit IRC | 08:17 | |
| *** ducttape_ has joined #openstack-meeting-cp | 09:13 | |
| *** ducttape_ has quit IRC | 09:17 | |
| *** ducttape_ has joined #openstack-meeting-cp | 10:14 | |
| *** ducttape_ has quit IRC | 10:19 | |
| *** sdague has joined #openstack-meeting-cp | 10:53 | |
| *** ducttape_ has joined #openstack-meeting-cp | 11:15 | |
| *** ducttape_ has quit IRC | 11:20 | |
| *** dhellmann has quit IRC | 12:00 | |
| *** dhellmann has joined #openstack-meeting-cp | 12:01 | |
| *** reed has quit IRC | 12:11 | |
| *** ducttape_ has joined #openstack-meeting-cp | 12:16 | |
| *** ducttape_ has quit IRC | 12:21 | |
| *** david-lyle has quit IRC | 12:30 | |
| *** david-lyle has joined #openstack-meeting-cp | 12:33 | |
| *** sdague has quit IRC | 12:55 | |
| *** ducttape_ has joined #openstack-meeting-cp | 13:17 | |
| *** gouthamr has joined #openstack-meeting-cp | 13:20 | |
| *** ducttape_ has quit IRC | 13:21 | |
| *** ducttape_ has joined #openstack-meeting-cp | 13:25 | |
| *** gouthamr has quit IRC | 13:26 | |
| *** MarkBaker has quit IRC | 13:39 | |
| *** lamt has joined #openstack-meeting-cp | 13:44 | |
| *** gouthamr has joined #openstack-meeting-cp | 13:46 | |
| *** ducttape_ has quit IRC | 13:54 | |
| *** KeithMnemonic has joined #openstack-meeting-cp | 13:57 | |
| *** MarkBaker has joined #openstack-meeting-cp | 14:04 | |
| *** sdague has joined #openstack-meeting-cp | 14:13 | |
| *** sdague has quit IRC | 14:14 | |
| *** sdague has joined #openstack-meeting-cp | 14:14 | |
| *** lamt has quit IRC | 14:19 | |
| *** ducttape_ has joined #openstack-meeting-cp | 14:27 | |
| *** lamt has joined #openstack-meeting-cp | 14:49 | |
| *** sdague has quit IRC | 14:51 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 14:55 | |
| *** sdague has joined #openstack-meeting-cp | 15:04 | |
| *** jaugustine has joined #openstack-meeting-cp | 15:11 | |
| *** sdague has quit IRC | 15:40 | |
| *** sdague has joined #openstack-meeting-cp | 15:43 | |
| *** jaugustine has quit IRC | 15:53 | |
| *** blancos has joined #openstack-meeting-cp | 15:58 | |
| lbragstad | #startmeeting policy | 16:00 |
|---|---|---|
| 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 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| *** openstack changes topic to " (Meeting topic: policy)" | 16:00 | |
| openstack | The meeting name has been set to 'policy' | 16:00 |
| lbragstad | ping antwash, raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung, ravelar, morgan, raj_singh, johnthetubaguy, knikolla | 16:00 |
| knikolla | o/ | 16:00 |
| *** edmondsw has joined #openstack-meeting-cp | 16:00 | |
| *** gagehugo has joined #openstack-meeting-cp | 16:00 | |
| * johnthetubaguy lurks in a probably not very active way | 16:00 | |
| *** ayoung has joined #openstack-meeting-cp | 16:00 | |
| lamt | o/ | 16:00 |
| lbragstad | o/ | 16:00 |
| ayoung | oyez | 16:01 |
| gagehugo | o/ | 16:01 |
| *** ravelar has joined #openstack-meeting-cp | 16:01 | |
| *** rderose has joined #openstack-meeting-cp | 16:01 | |
| lbragstad | agenda #link https://etherpad.openstack.org/p/keystone-policy-meeting | 16:02 |
| lbragstad | edmondsw you have the first topic on the list and it was a carry over thing from several meetings ago | 16:02 |
| lbragstad | edmondsw do you still want to cover those things? | 16:03 |
| *** diablo_rojo_phon has joined #openstack-meeting-cp | 16:03 | |
| edmondsw | was this the question of which policy checks need more than just project scope? | 16:03 |
| edmondsw | i.e. user scope | 16:03 |
| *** spilla has joined #openstack-meeting-cp | 16:04 | |
| lbragstad | #topic Work through 0.2% of use case granularity | 16:04 |
| *** openstack changes topic to "Work through 0.2% of use case granularity (Meeting topic: policy)" | 16:04 | |
| rderose | o/ | 16:04 |
| 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 |
| edmondsw | yeah, ok | 16:04 |
| edmondsw | so one of the cases I already spoke to johnthetubaguy about, commented in his spec | 16:04 |
| *** jonesn has joined #openstack-meeting-cp | 16:04 | |
| edmondsw | one sec, let me find it | 16:05 |
| edmondsw | come back to me? | 16:06 |
| ayoung | OK...so this is trying to come up with common groupings of policy? | 16:06 |
| ayoung | The way I explained it in the past is this: | 16:06 |
| edmondsw | ayoung no | 16:06 |
| 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 |
| edmondsw | different discussion | 16:07 |
| ayoung | oh...so missing the context from the link | 16:07 |
| * johnthetubaguy is confused about what the question is | 16:07 | |
| * ayoung too | 16:08 | |
| lbragstad | this was a discussion we had several meetings ago - but it keeps getting bumped | 16:08 |
| ayoung | What does this 2% refere to? | 16:08 |
| ayoung | 0.2%? | 16:08 |
| edmondsw | cases where you customize list and show differently | 16:08 |
| lbragstad | from what i remember edmondsw had some cases that needed some extra granularity | 16:08 |
| ayoung | isn't that what I just said? | 16:08 |
| 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 |
| 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:09 |
| ayoung | agreed> | 16:10 |
| ayoung | ? | 16:10 |
| knikolla | aren't they different apis? | 16:10 |
| *** antwash has joined #openstack-meeting-cp | 16:10 | |
| 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 |
| ayoung | OK...so here is how I would explain it: | 16:10 |
| ayoung | at the lowest level, we have roles mapped to individual APIs | 16:10 |
| ayoung | at the highest level we have the users organizational position | 16:11 |
| ayoung | in the middle we have workflows | 16:11 |
| ayoung | in english: | 16:11 |
| ayoung | A user needs permission to access specific APIs to perform workflows specific to their organizational role | 16:11 |
| 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:11 |
| lbragstad | edmondsw ++ | 16:12 |
| lbragstad | yeah - that was it | 16:12 |
| edmondsw | sorry, took me a minute to access that cache | 16:12 |
| knikolla | i see | 16:12 |
| ayoung | so, by default, no role check is done right now except for Admin in almost all APIs | 16:12 |
| edmondsw | ayoung wrong | 16:13 |
| 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 |
| ayoung | edmondsw, has it been rewritten in the past month? | 16:13 |
| edmondsw | ayoung oh, ok, you're right... if you discount customization | 16:13 |
| edmondsw | my bad, carry on | 16:13 |
| ayoung | cool | 16:13 |
| 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:14 |
| 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 |
| ayoung | by default, we can say "any role for scope" will continue to pass. | 16:15 |
| edmondsw | which we're doing... | 16:15 |
| ayoung | but, if you want to customize, then you set explicit roles for APIs | 16:15 |
| ayoung | and this is what I want to split out. | 16:15 |
| ayoung | Implied roles make it eaiser, too, to move forward | 16:15 |
| edmondsw | I don't think we really have a problem here | 16:15 |
| ayoung | for example, say you have a "reader" role that can do bot get and list | 16:16 |
| ayoung | and then you realize you need get to be more restrictive, that some users should only have get | 16:16 |
| edmondsw | the scope check moving into code as johnthetubaguy and I worked out will be able to handle these odd .2% cases | 16:16 |
| ayoung | you create a new role for that, and then have reader imply get | 16:16 |
| edmondsw | no need for implied roles here, either | 16:16 |
| ayoung | excellent | 16:16 |
| lbragstad | cool | 16:16 |
| lbragstad | so - moving on | 16:16 |
| ayoung | nah, the implied roles is for the operator to make things smooth | 16:16 |
| lbragstad | everyone good? | 16:16 |
| 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 |
| lbragstad | i'm good | 16:17 |
| edmondsw | well... | 16:18 |
| lbragstad | i also want to get to the next topic because I'm super curious about it | 16:18 |
| lbragstad | ;) | 16:18 |
| 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:18 |
| ayoung | edmondsw, you are scaring me | 16:19 |
| ayoung | the APIs should all be separate | 16:19 |
| ayoung | or are you talking about a single API that can handle filters? | 16:19 |
| edmondsw | talking about list vs get APIs | 16:19 |
| ayoung | edmondsw, separate APIs stay separate | 16:20 |
| edmondsw | nope | 16:20 |
| ayoung | single APIs might need to be split | 16:20 |
| edmondsw | not what we'd agreed | 16:20 |
| ayoung | edmondsw, I didn't agree on anything | 16:20 |
| edmondsw | no, you didn't ;) | 16:20 |
| ayoung | edmondsw, if you might want to be able to vary them independantly, at any point, keep them separate | 16:20 |
| ayoung | its easy to merge, hard to split | 16:20 |
| ayoung | easy-> can be done by operator | 16:21 |
| edmondsw | this isn't a case where you might want to split them later | 16:21 |
| ayoung | hard->won't happen | 16:21 |
| edmondsw | that's kinda the point | 16:21 |
| ayoung | then why are they separate APIs? | 16:21 |
| *** MarkBaker has quit IRC | 16:21 | |
| edmondsw | you're asking why list and get are separate APIs? | 16:21 |
| ayoung | yep | 16:22 |
| *** MarkBaker has joined #openstack-meeting-cp | 16:22 | |
| ayoung | separate use cases | 16:22 |
| edmondsw | seems a bit obvious... | 16:22 |
| ayoung | edmondsw, we talking role check or just scope check here? | 16:23 |
| edmondsw | johnthetubaguy proposed that we compress these. If you have a reason not to, explain it | 16:23 |
| edmondsw | role check | 16:23 |
| johnthetubaguy | compress what? sorry I lots track | 16:24 |
| johnthetubaguy | lost | 16:24 |
| ayoung | yeah, so instead of messing around here, please just go with the Role check from middleware | 16:24 |
| edmondsw | policy checks for get vs. list | 16:24 |
| ayoung | scope check in code is great | 16:24 |
| ayoung | make that happen | 16:24 |
| lbragstad | 6 minutes left for this specific topic | 16:24 |
| johnthetubaguy | well, step one for me is scope check in code, lets do that first | 16:24 |
| ayoung | Yesss | 16:25 |
| edmondsw | amen | 16:25 |
| johnthetubaguy | cool, so that feels like agreement | 16:25 |
| lbragstad | #success there was agreement in a policy meeting | 16:25 |
| ayoung | and only scope check...what about is_admin | 16:25 |
| ayoung | that seems like it is part of scope check | 16:25 |
| ayoung | is_admin_project | 16:25 |
| 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:25 |
| johnthetubaguy | well there is a "global" scope permission | 16:26 |
| johnthetubaguy | the question is how do you get that permission | 16:26 |
| ayoung | johnthetubaguy, not really | 16:26 |
| ayoung | johnthetubaguy, there is admin on this project, and admin on the admin project | 16:26 |
| johnthetubaguy | well maybe | 16:26 |
| 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 |
| johnthetubaguy | ignoring how you define this in keystone | 16:26 |
| johnthetubaguy | there is some kind of "global" thing | 16:27 |
| edmondsw | is_admin_project=True | 16:27 |
| ayoung | johnthetubaguy, nope, this is more than keystone, and no there is not, there is just an open bug | 16:27 |
| johnthetubaguy | vs only being able to access things in your porject | 16:27 |
| johnthetubaguy | right, and we default that policy to is_admin_project = True right now | 16:27 |
| edmondsw | ayoung no, I think you misunderstand... we do have is_admin_project and that's what he's talking about | 16:27 |
| johnthetubaguy | from an operator view right... | 16:27 |
| johnthetubaguy | I want a user that can read everything in the whole system | 16:28 |
| johnthetubaguy | ... OK, so thats global scope, and has the read role | 16:28 |
| ayoung | johnthetubaguy, yep, that should be done by getting a role on the admin project. | 16:28 |
| johnthetubaguy | oh, so that means a user in the admin project, with the role observer, or some such | 16:28 |
| 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 |
| ayoung | yep | 16:28 |
| johnthetubaguy | I think we are violently agreeing here | 16:29 |
| edmondsw | yep | 16:29 |
| lbragstad | is everyone good to move on? | 16:29 |
| edmondsw | I am | 16:29 |
| johnthetubaguy | so I have a policy rule to configure what it means to be global right now | 16:29 |
| johnthetubaguy | we could hard code that to is_admin_project == True | 16:29 |
| edmondsw | ++ | 16:30 |
| *** markvoelker has quit IRC | 16:30 | |
| johnthetubaguy | so I am not sure how the backwards compatibility works with that, needs some thought | 16:30 |
| lbragstad | johnthetubaguy mind if we circle back? | 16:30 |
| 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 |
| ayoung | and, this is a Keystone only thing, I think. | 16:31 |
| lbragstad | let's table this for now and circle back (possibly offline), i want to give blancos enough time for her topic | 16:32 |
| lbragstad | #topci patrole | 16:32 |
| lbragstad | blancos gagehugo lamt o/ | 16:32 |
| blancos | o/ | 16:32 |
| 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 |
| lamt | o/ | 16:32 |
| edmondsw | lbragstad typo in your topic change | 16:32 |
| gagehugo | o/ | 16:32 |
| ayoung | Pah Troll AY! | 16:32 |
| lbragstad | #topic patrole | 16:32 |
| lbragstad | edmondsw thanks | 16:32 |
| *** openstack changes topic to "patrole (Meeting topic: policy)" | 16:32 | |
| lbragstad | #link https://github.com/openstack/patrole | 16:33 |
| blancos | Would you like me to explain it a little bit first or do like a Q&A type of thing? | 16:33 |
| lbragstad | blancos go for it | 16:33 |
| blancos | Okay :) | 16:33 |
| lbragstad | blancos i know i'm curious about it as a whole | 16:33 |
| 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 |
| blancos | and we wanted to make sure that these roles and restrictions we created were being properly enforced. | 16:34 |
| 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:34 |
| lbragstad | nice - so it sounds like there is expected test cases for each role? | 16:35 |
| lbragstad | s/is/are/ | 16:35 |
| 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:35 |
| blancos | (New fields are added to tempest.conf) | 16:36 |
| 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:36 |
| lbragstad | blancos is this tied into the gate somewhere? | 16:37 |
| 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 |
| lbragstad | blancos that'd be nice | 16:37 |
| blancos | I'm guessing that's something Keystone might be interested in then? | 16:38 |
| lbragstad | blancos but right now I assume it's just being run locally and bugs are filed manually against the projects? | 16:38 |
| lbragstad | blancos yes - i'm interested | 16:38 |
| blancos | Yes. And we have some bugs we currently are working through within the project | 16:38 |
| blancos | It's still relatively new | 16:38 |
| lbragstad | within patrole itself you mean? | 16:38 |
| blancos | Yes, but we have a pretty large team actively working on it so they're being worked through | 16:39 |
| lbragstad | blancos awesome - how many people are currently working on it? | 16:39 |
| blancos | I would say around 15? And of course we're happy to have more people join :) | 16:40 |
| lbragstad | wow | 16:40 |
| lbragstad | is there a dedicated irc room for patrole or where do most of you hang out? | 16:41 |
| blancos | Currently no, but that's something we're looking into as the project grows | 16:41 |
| 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:42 |
| blancos | ayoung I think this is something that would be beneficial as it's specific testing | 16:43 |
| *** ducttape_ has quit IRC | 16:43 | |
| lbragstad | ayoung it sounds like it would be making it easier to validate that work | 16:43 |
| blancos | And it obviously doesn't apply to all situations | 16:43 |
| ayoung | OK, I need to sjhut off the music and concentrate | 16:43 |
| *** ducttape_ has joined #openstack-meeting-cp | 16:43 | |
| ayoung | there is a serious lack of understanding of the problem. THe RBAC check is half formed at the moment | 16:43 |
| ayoung | if you do RBAC checks in Tempest, are you going to do them by running customized policy files? | 16:44 |
| *** ducttape_ has quit IRC | 16:44 | |
| *** ducttape_ has joined #openstack-meeting-cp | 16:44 | |
| blancos | We have multiple checks for where the policies are coming from; the first is a check for custom policy.json | 16:45 |
| ayoung | blancos, yeah,. kill that dead with fire | 16:45 |
| lbragstad | blancos i guess that's a good question - does patrole setup the new roles and customize policy files? | 16:45 |
| lbragstad | blancos on top of a devstack installation or something like that? | 16:46 |
| *** jaugustine has joined #openstack-meeting-cp | 16:46 | |
| 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 |
| 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 |
| lbragstad | blancos got it - that makes sense | 16:46 |
| lbragstad | blancos so patrole really just expects a set of service endpoints to run against | 16:47 |
| blancos | ayoung We also make use of oslo policy checker or, in the case of Nova, defaults in code | 16:47 |
| blancos | lbragstad Yes. And if you have custom roles, those roles have to exist within Keystone | 16:47 |
| blancos | (For example, the custom viewer role I mentioned earlier) | 16:47 |
| lbragstad | blancos cool - so this could be something that could be worked into openstack-ansible or other deployment tools | 16:48 |
| 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 |
| blancos | lbragstad Yes I don't see why not | 16:48 |
| lbragstad | blancos awesome | 16:48 |
| 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:48 |
| 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 |
| 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 |
| ayoung | blancos, so, the test side is awesome. It is the custom policy.json files I don't want. | 16:49 |
| 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:49 |
| 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 |
| 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 |
| 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:50 |
| blancos | And of course we can expand the framework to check against more :) | 16:51 |
| 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 |
| edmondsw | or, as you said, being inconsistent about what permission denied looks like | 16:51 |
| 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:51 |
| blancos | edmondsw Yes, that's correct | 16:52 |
| 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:52 |
| 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 |
| edmondsw | no no no... can't return 403 in those cases... that's a security vuln | 16:53 |
| 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 |
| blancos | I don't mean as a sweeping change | 16:54 |
| *** ducttape_ has quit IRC | 16:54 | |
| 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:54 |
| edmondsw | hopefully they did, and the cases you discussed were really ok, but I wouldn't necessarily bet on that | 16:55 |
| 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 |
| lbragstad | i'd be fine if they were all just documented somewhere - then we can at least reason about them independently | 16:55 |
| 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 |
| blancos | (the links, I mean) | 16:56 |
| lbragstad | that works for me | 16:56 |
| blancos | In the Keystone IRC room? | 16:57 |
| lbragstad | ++ | 16:57 |
| 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 |
| 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:57 |
| lbragstad | were about out of time, but I wanted to thank blancos for swinging by and taking the time to field our questions | 16:58 |
| blancos | No problem. Happy to spread the word about our project :) | 16:59 |
| lbragstad | blancos do keep us posted if there is a dedicated place for us to talk about patrole | 16:59 |
| blancos | Will do | 16:59 |
| lbragstad | thanks for coming everyone! | 16:59 |
| lbragstad | #endmeeting | 16:59 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 16:59 | |
| openstack | Meeting ended Wed Mar 8 16:59:58 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:59 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-03-08-16.00.html | 17:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-03-08-16.00.txt | 17:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-03-08-16.00.log.html | 17:00 |
| *** gagehugo has left #openstack-meeting-cp | 17:00 | |
| *** jonesn has quit IRC | 17:00 | |
| *** blancos has left #openstack-meeting-cp | 17:01 | |
| *** ravelar has quit IRC | 17:03 | |
| *** antwash has left #openstack-meeting-cp | 17:08 | |
| *** markvoelker has joined #openstack-meeting-cp | 17:13 | |
| *** KeithMnemonic has quit IRC | 17:15 | |
| *** raildo has joined #openstack-meeting-cp | 17:26 | |
| *** KeithMnemonic has joined #openstack-meeting-cp | 17:53 | |
| *** ducttape_ has joined #openstack-meeting-cp | 17:55 | |
| *** ducttape_ has quit IRC | 17:59 | |
| *** ducttape_ has joined #openstack-meeting-cp | 18:02 | |
| *** ducttape_ has quit IRC | 18:47 | |
| *** sdague has quit IRC | 18:49 | |
| *** sdague has joined #openstack-meeting-cp | 18:50 | |
| *** diablo_rojo has quit IRC | 19:00 | |
| *** spilla has left #openstack-meeting-cp | 19:05 | |
| *** breitz has quit IRC | 19:25 | |
| *** breitz has joined #openstack-meeting-cp | 19:26 | |
| *** ducttape_ has joined #openstack-meeting-cp | 19:47 | |
| *** markvoelker has quit IRC | 20:27 | |
| *** ShaneRowe has joined #openstack-meeting-cp | 20:32 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 20:34 | |
| *** ShaneRowe has quit IRC | 20:47 | |
| *** ducttape_ has quit IRC | 20:52 | |
| *** jaugustine has quit IRC | 21:03 | |
| *** ducttape_ has joined #openstack-meeting-cp | 21:05 | |
| *** markvoelker has joined #openstack-meeting-cp | 21:27 | |
| *** raildo has quit IRC | 21:31 | |
| *** markvoelker has quit IRC | 21:32 | |
| *** gouthamr has quit IRC | 21:38 | |
| *** Rockyg has quit IRC | 21:42 | |
| *** MarkBaker has quit IRC | 21:52 | |
| *** sdague has quit IRC | 21:55 | |
| *** gouthamr has joined #openstack-meeting-cp | 22:01 | |
| *** ducttape_ has quit IRC | 22:05 | |
| *** ducttape_ has joined #openstack-meeting-cp | 22:05 | |
| *** knangia has joined #openstack-meeting-cp | 22:07 | |
| *** edmondsw has left #openstack-meeting-cp | 22:15 | |
| *** markvoelker has joined #openstack-meeting-cp | 22:54 | |
| *** ducttape_ has quit IRC | 22:55 | |
| *** ducttape_ has joined #openstack-meeting-cp | 22:55 | |
| *** ducttape_ has quit IRC | 23:35 | |
| *** diablo_rojo has quit IRC | 23:37 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 23:37 | |
| *** ducttape_ has joined #openstack-meeting-cp | 23:38 | |
| *** diablo_rojo_phon has quit IRC | 23:40 | |
| *** david-lyle has quit IRC | 23:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!