That depends on your security requirements. If HAProxy is proxying requests to multiple servers and you terminate the SSL at HAProxy, then you will be sending the request unencrypted from one server to another. I am not at all opposed to adding the capabilities to configure HAProxy to terminate and even re-encrypt requests for those who have a different set of security requirements. Looks like I will need both the stunnel server and client.
Mark -----Original Message----- From: Robert Collins [mailto:robe...@robertcollins.net] Sent: Wednesday, May 21, 2014 3:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [TripleO] Haproxy configuration options On 18 May 2014 08:17, Miller, Mark M (EB SW Cloud - R&D - Corvallis) <mark.m.mil...@hp.com> wrote: > We are considering the following connection chain: > > -> HAProxy -> stunnel -> OS services bound to > 127.0.0.1 > Virtual IP server IP localhost > 127.0.0.1 > secure SSL terminate unsecure Interestingly, and separately, HAProxy can do SSL termination now, so we might want to consider just using HAProxy for that. > In this chain none of the ports need to changed. One of the major issues I > have come across is the hard coding of the Keystone ports in the OpenStack > service's configuration files. With the above connection scheme none of the > ports need to change. But we do need to have HAProxy not wildcard bind, as Greg points out, and to make OS services bind to 127.0.0.1 as Jan pointed out. I suspect we need to put this through the specs process (which ops teams are starting to watch) to ensure we get enough input. I'd love to see: - SSL by default - A setup we can document in the ops guide / HA openstack install guide - e.g we don't need to be doing it a third different way (or we can update the existing docs if what we converge on is better). - Only SSL enabled endpoints accessible from outside the machine (so python processes bound to localhost as a security feature). Eventually we may need to scale traffic beyond one HAProxy, at which point we'll need to bring something altogether more sophisticated in - lets design that when we need it. Sooner than that we're likely going to need to scale load beyond one control plane server at which point the HAProxy VIP either needs to be distributed (so active-active load receiving) or we need to go user -> haproxy (VIP) -> SSL endpoint (on any control plane node) -> localhost bound service. HTH, Rob _______________________________________________ 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
