On 04/18/2014 11:21 AM, Stephen Balukoff wrote:
Howdy, folks!
Could someone explain to me the SSL usage scenario where it makes
sense to re-encrypt traffic traffic destined for members of a back-end
pool? SSL termination on the load balancer makes sense to me, but I'm
having trouble understanding why one would be concerned about then
re-encrypting the traffic headed toward a back-end app server. (Why
not just use straight TCP load balancing in this case, and save the
CPU cycles on the load balancer?)
Look at it this way. SSL to the Endpoint protects you on the public
internet. That means that at each of the hops from you to the
Datacenter, no one can read your traffic.
So, if you are at the local coffee shop, wokring on your Neutron setup,
no one can see more than the URLs that you are using. From there, it
goes to the shop's ISP, thorugh a couple of hops, and then ends up at
your datacenter. From the ISP to the datacenter, while it is good to be
secure, the likelihood of random attack is low: these are arelatviely
secured links, and with companies that have economic incentive not to
hack your traffic. Don't get me wrong, there is a real possibility for
attack, but that is not your big risk.
So, now you are at your datacenter, and you want to talk to Neutron' API
server. You hit the SSL terminiation, and your traffic is decrypted.
And send, in the clear, with your userid and password, to Keystone to
get a token.
Same as everyone else talking to that keystone server.
Same as everyone else talking to every public server in this data center.
"So what" you think "no one has the ability to run custom code."
Um, this is OpenStack. Random VMs just teeming with all sorts of code,
malicious, friendly, intentional, whatever, is being run all over the
place.
So what is protecting your unsecure socket connection from all of this
code? Neutron. Specifically, making sure that no one has messed up
neutron connectivity and managed to keep that route from the SSL
terminator to the Neutron API server locked up, so none of those nasty
VMs can grab and sniff it. Oh sure...its never gonna happen, right?
Look at it like swimming in a public pool. There, the number of
swimmers would be limited by the size of the pool, fire regulations, and
physical access. This is the Virtual world. There are hundreds if not
thousands of people swimming in this pool. I'll stop the biological
analogy because some people reading this might be eating.
SSL. Everywhere.
We terminate a lot of SSL connections on our load balancers, but have
yet to have a customer use this kind of functionality. (We've had a
few ask about it, usually because they didn't understand what a load
balancer is supposed to do-- and with a bit of explanation they went
either with SSL termination on the load balancer + clear text on the
back-end, or just straight TCP load balancing.)
Thanks,
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
