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