17:59:33 #startmeeting keystone 17:59:34 Meeting started Tue Aug 25 17:59:33 2015 UTC and is due to finish in 60 minutes. The chair is morgan. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:59:37 The meeting name has been set to 'keystone' 17:59:57 Hi everybody! feature freeze is around the corner 18:00:02 wow….meeting started on the nose 18:00:06 Please take some 18:00:19 Time and check out keystoneauth. We would like to cut 1.0 this week 18:00:30 But if it isnt ready, it isnt ready 18:00:48 This request is for a full review of the library not specific patches. 18:00:58 Ok moving on to the topics today. 18:01:05 we can't test keystoneauth with the feature branch 18:01:27 No you cant at the moment. 18:01:43 at least the ksc branch with master merged 18:02:01 (master from a few weeks ago, don't know about today's) 18:02:22 so i don't think we should release ksa if we can't test it. 18:02:33 We are in a chicken and egg 18:02:42 We are going to need to release it to really test it 18:02:45 we need a release of ksa. 18:02:58 then we can test it 18:03:23 1.0-beta 18:03:24 here's the change to release ksa 0.4.0: https://review.openstack.org/#/c/213573/ 18:03:30 The integration branch isnt going to really work until we do. And real testing cant happen until we are set. Anyway we need to declare the interfaces stable 18:03:38 then the ksc branch can run with that 18:03:50 That is the major concern with 1.0 18:04:09 I cant add ksa to g-r until we are saying the interfaces are stable 18:04:18 And testing is very limited until then 18:04:30 the feature branch doesn't use g-r 18:04:55 The feature branch also not a good representation 18:05:11 Anyway to discuss offline 18:05:32 #topic improper handling in osc of certain entities 18:05:43 henrynash: o/ 18:05:55 ok, so I think davechen raise this…you on? 18:06:09 ok, I’ll handle 18:06:25 so the issue is that osc assumes that all entitis have a name attribute 18:06:36 (that’s how osc show works) 18:06:51 and we used to adhere to that rule 18:06:51 We need a "name" attribute? 18:07:13 ..but more recently created entities don’t (e.g. IDP) 18:07:22 This is kind of a silly requirement. But meh. I dont care which way we go 18:07:45 so we either need to make osc more flexibe (my choice too) or have to give all our entities a name attrib 18:07:55 I don't think we should change keystone to meet osc. 18:08:17 make osc support extras 18:08:19 we need to be able to build the rest interface the way that works best for us. 18:08:20 just kidding 18:08:21 that’s my view too, but wanted to get other’s views 18:08:36 regions don't have names, either, i don't think 18:08:45 yeah, there a few that don't 18:08:58 bknudson: ++ 18:09:00 dolphm, region used to have name 18:09:14 Dont have a strong opinion on this. But the argument is going to be consistency in the openstack apis 18:09:30 our models should be ours and not based on outside forces 18:09:41 gyee: now, it was just region="abcxyz" and then when we made it a first class entity, we moved that arbitrary string value into the id field, so {"region": {"id": "abcxyz"} 18:09:42 Same basic argument as the pagination thing: resources should look like a certain thing 18:09:49 } 18:09:54 So assumptions can be made 18:10:09 morgan: so that’s a good question…is that a cross-OS statement - that first class entities should have a name attribute? 18:10:22 I would ask the api-wg 18:10:27 morgan: there are surely other things that exist without names... 18:10:43 If they say yes, then the direction becomes easier 18:10:50 dolphm, k, I thought "region" itself is a name, maybe not 18:10:52 morgan: ok, I’ll take that action 18:10:57 gyee: sort of, yes 18:10:59 If they say "no" or "undefined" we should change osc 18:11:17 we don't have name for certain entities, but in id we actually store names instead of uuid 18:11:44 haneef: agreed 18:11:44 like IdP, protocol, etc 18:11:50 haneef: the difference between an ID and a name is whether it's the URI reference or not 18:11:55 If we need to represent an attribute as both name and something else we can do that too 18:12:01 haneef: and mutability. IDs are not mutable, names generally are 18:12:06 For the sake of "consistency". 18:12:09 ok, et me take this to the api-wg 18:12:17 But lets see what the api-wg sayd 18:12:29 ok, so we have a sublimental question 18:12:39 henrynash: do you have more context what's the issue on osc show command? is it error-ing out? not sure if it is really an issue on osc. 18:12:57 If they don't say name should be there, we work with osc to better support the varying data models 18:13:01 so that is part of the 2nd question 18:13:12 the way osc show works is it does a list filtered on the name 18:13:31 Ick 18:13:36 But sure 18:13:43 in keystone, are rule for filtering is if you provide a filter we don’t understand, then we ignore it 18:13:54 Like i said we might need to be smarter internally if the client cant be 18:14:19 We should return no results with a bogus filter imo 18:14:22 some folks feel that maybe if you supplya filter we don’t understand you should get nothing from a list request 18:14:31 and that is the question 18:14:37 You asked for something we cant answer, no results match 18:14:47 ++ 18:15:12 what is an example of a filter we don't understand? something like: ?bugus=true ? 18:15:33 so think when we last had this discussion we decided the opposite :-), but Im fine with changing it….but suscpetd we would have to have a deprecation cycle 18:15:56 henrynash, aren't some of the filters directly tied to authorization as well 18:15:57 * morgan doesnt remeber this alternate decision 18:15:57 ? 18:16:02 like filter_protected? 18:16:06 dstanek: yes …and in this case list IDP?name=xyz (!) 18:16:19 morgan: twas a long time ago! 18:16:25 I would push towards bogus filters = no results 18:16:31 gyee: yes. domain_id filter is tied to authrorization 18:16:36 That seems... More "normal" 18:16:40 so bogus filter would yield a 401 sometime 18:16:40 morgan: ++ 18:17:03 so I’m cool woth that….but suggest we must depreacte the old functionality 18:17:05 will have to double check that code 18:17:06 gyee: we'll have to work on some of that. The protected decorators are going to go away 18:17:09 that basically means pulling out the query params we know about and assuming the rest are filters 18:17:21 dstanek: yah. A bit more work 18:17:21 morgan, ++ it's like having a sieve where the grains do not pass, which makes sense 18:17:39 henrynash: thought that is controlled in the osc code, filtering by name/id is only done if the entity supports it. 18:17:52 this can break the world since right now things would just work 18:18:06 dstanek, yeah, that's how we need to deprecate 18:18:12 lhcheng_: but you can fire any http command you like at keystone with radome filtes 18:18:24 dstanek, why* 18:18:47 henrynash: so lets propose the changes to filters and talk to api-wg 18:18:53 samueldmq: users?what=huh will give me all of the users in the future it won't 18:19:02 I think that is all we have to discuss at this point. 18:19:03 dstanek:++ 18:19:27 dstanek, yes, is there a way to deprecate bad usage of a call ? 18:19:28 I think that is all we have to discuss at this point. 18:19:32 morgan: agreed - i’ll take both to the api-wg 18:19:37 dstanek, like, warning in the logs ? that's all ? 18:19:43 Sounds good 18:19:57 Ok lets move on 18:20:05 samueldmq: not that easy since this isn't necessarily a server thing 18:20:32 henrynash: maybe we make an explicit filter= param 18:20:48 henrynash: and leave the old behavior as is for now 18:21:03 Anyway moving on - we can see what the api-wg comes back with 18:21:13 dstanek, I think so, it's basically the server behavior that is changing, isn't it ? 18:21:14 #topic Call For Reviews 18:21:32 #link https://review.openstack.org/#/c/213820/ assignment testing chain please review 18:21:47 #link https://review.openstack.org/#/c/214766/ 18:21:59 That is the websso chain, please review 18:22:08 thx 18:22:13 #link https://review.openstack.org/#/c/212045/ 18:22:23 Reseller 18:22:25 Please review 18:22:38 #topic policies 18:22:51 gyee: O/ 18:23:18 I had a chat with samueldmq over this 18:23:25 o/ 18:23:45 so there are some security issues we may need to address 18:24:10 1) policy validation, like maintaining the hash for validation at the endpoint 18:24:30 What validation? 18:24:42 Please be more specific 18:24:57 making sure the policy the endpoints received has not been altered 18:25:05 are we talking endpoint policy stuff, dynamic policy stuff, other? 18:25:21 endpoint policy 18:25:35 dstanek, policy distribution 18:25:53 gyee, like man in the middle attack? 18:25:54 morgan, that's kind of what lhcheng_ asked in the spec, a mechanism to check the policy has not been altered by a mitm attack 18:26:04 david8hu, ++ 18:26:28 david8hu, right, or just making sure the file on disk is consistent 18:26:34 dstanek and marekd suggested that TLS solves that already, but gyee wanted another level of checking (optionally) 18:26:38 ++ 18:26:51 * morgan falls back to "we should use cms and not distribute policy via keystone" but has lost that argument 18:27:10 morgan: ++ 18:27:14 and where do you get this checksum? Keystone? 18:27:20 so where does the hash come from? 18:27:25 Also subject to mitm 18:27:48 not if they are signed 18:27:50 the only safe way to do it would be to hard code it in the config or some other non-Keystone process 18:27:54 TLS is sufficient in these regards unless we are doing pki signatures and im going to -2 that for now 18:28:02 Dont over think this to start 18:28:10 This is scope creep 18:28:33 k 18:28:37 Build signing afterwards on top of it once it works. TLS is good enough for now 18:28:51 yeah, no reason to build TLS over TLS 18:29:12 not TLS over TLS 18:29:31 gyee: no need to add this in until it works 18:29:53 So focus on working before layering added security above and beyond what we rely on today 18:29:55 well, "works" is a funny definition 18:30:19 it would be hard to make it "work" without passing the security review 18:30:25 Works: is usable beyond a proof of concept 18:30:45 gyee: if TLS doesnt pass security review, keystone doesnt pass security review 18:31:12 gyee: has this been run by the openstack security team? 18:31:39 dstanek, I think the spec have a security tag on them 18:31:43 will need to double check 18:31:45 gyee: are there attack vectors you know of that go against a TLS only version of this? 18:31:45 So functionally complete. Then we can layer signing over it later. In openstack we rely on TLS for most mitm prevention 18:32:29 if they can subvert the policy file then they can also subvert the signing cert. 18:32:49 we'd like to have signing as well. But I agree that can be added later. 18:32:49 and if you can distribute the signing cert securely then use the same method to distribute the policy file 18:32:58 yeah, if they can subvert signing cert, then game over 18:33:24 gyee: and we're back to relying on TLS 18:33:35 signing cert is provisioned via CMS at bootstrap 18:33:38 So lets stick with TLS for now 18:33:41 k 18:33:57 we kinda have a similar system like that, so I assume our security team will ask for a way to verify that the policy file is not tampered. 18:34:05 Circle back on this convo during security review and after this is functionally complete 18:34:10 This is still scope creep 18:34:28 sure, that's fine, just want to raise the issue so we are aware of it 18:35:13 gyee, another thing is that you guys would like to have a sort of 'auditing' mechanism ,to know hwat endpoints were updated, right? 18:35:19 lhcheng_: cms and Samhain 18:35:28 2) we need an auditing/reporting mechanism to make sure all the nodes are updated and when 18:35:35 lhcheng_: that is my recommendation 18:36:03 gyee: back to my view: use cms. But on topic - propose something :) 18:36:24 This sounds like a spec or ML topic 18:36:30 morgan, sure, probably in M 18:36:34 Yep 18:37:06 basically, dynamically is non-starter without policy distribution 18:37:13 dynamic policy I mean 18:37:24 * dstanek thinks Keystone is becoming much more than a identity service 18:37:36 split out policy service 18:37:43 doesn't need to be in keystone 18:37:43 dstanek, keystone is not even an identity service :) 18:37:49 I largely remain unconvinced dynamic policy is worth it. 18:37:59 morgan: sure, but if can keystone can provide it less integration work for me :P 18:38:01 is policy distribute the policy over HTTP? 18:38:01 bknudson, sure, I have not issue with that :) 18:38:23 We have so many other things to fix that would inprove qol before we try and solve making policy change on demand 18:38:27 microservices 18:39:05 Seriously i see dynamic policy worth more once we split service-to-service and used-to-service authz 18:39:09 dstanek, no, HTTPS 18:39:15 I also think that if we are solving dynamic policy by slurping the files around, then we shouldn’t be in that business. That is indeed cms. 18:39:18 It also makes dynamic policy a much smaller scope 18:39:36 morgan, so a separate service for policy management/distribution 18:39:49 samueldmq: that is not waht i said at all 18:39:59 samueldmq, no, they are talking about a authz service I think 18:40:06 Nope 18:40:17 Anyway all of this is offtopic here 18:41:09 was that the last topic? 18:41:11 lhcheng_: there are ideas i have but just keep in mind that if you can subvert the policy file you can likley subvert the certs. 18:41:26 So back to standard how to manage an IDS. 18:41:31 dstanek: yep 18:41:40 And we're going to call the meeting early 18:41:49 Give everyone 20m back today. Yay! 18:41:55 Thanks everyone. 18:41:59 more coffee time! 18:42:00 thanks 18:42:00 thanks 18:42:01 #endmeeting