Open Stack

On Thu, May 22, 2014, at 08:51 AM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis) wrote:
> 
> HAProxy SSL termination is not a viable option when HAProxy is used to
> proxy traffic between servers. If HAProxy terminates the SSL it will then
> proxy the traffic unencrypted to any other server across a network.
> However, since SSL termination and SSL re-encryption are now features of
> the current HAProxy development releases, I would vote to add these
> features in addition to stunnel.

Relevant ML thread from a few months ago:
http://lists.openstack.org/pipermail/openstack-dev/2014-March/031229.html

> 
> Mark 
> ________________________________________
> From: Dmitriy Shulyak [dshulyak at mirantis.com]
> Sent: Thursday, May 22, 2014 8:35 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [TripleO] Haproxy configuration options
> 
> Created spec https://review.openstack.org/#/c/94907/
> 
> I think it is WIP still, but would be nice to hear some comments/opinions
> 
> 
> On Thu, May 22, 2014 at 1:59 AM, Robert Collins
> <robertc at robertcollins.net<mailto:robertc at robertcollins.net>> wrote:
> On 18 May 2014 08:17, Miller, Mark M (EB SW Cloud - R&D - Corvallis)
> <mark.m.miller at hp.com<mailto:mark.m.miller at 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.

This would be a nice next step, but in the long term I can see users
wanting SSL termination and load balancing separated due to:
A) Different scaling requirements
B) Access control to machines with SSL certs

> 
> > 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).

+1

> 
> 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.

Putting SSL termination behind HAProxy seems odd. Typically your load
balancer wants to be able to grok the traffic sent though it which is
not possible in this setup. For an environment where sending unencrypted
traffic across the internal work is not allowed I agree with Mark's
suggestion of re-encrypting for internal traffic, but IMO it should
still pass through the load balancer unencrypted. Basically:
User -> External SSL Terminate -> LB -> SSL encrypt -> control plane

This is a bit overkill given our current state, but I think for now its
important we terminate external SSL earlier on: See ML thread linked
above for reasoning.

> 
> HTH,
> Rob

Thanks,
Greg