<div dir="ltr">Created spec <a href="https://review.openstack.org/#/c/94907/">https://review.openstack.org/#/c/94907/</a><div><br></div><div>I think it is WIP still, but would be nice to hear some comments/opinions</div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 22, 2014 at 1:59 AM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 18 May 2014 08:17, Miller, Mark M (EB SW Cloud - R&D - Corvallis)<br>
<div class=""><<a href="mailto:mark.m.miller@hp.com">mark.m.miller@hp.com</a>> wrote:<br>
> We are considering the following connection chain:<br>
><br>
>                -> HAProxy   ->   stunnel         ->    OS services bound to 127.0.0.1<br>
>                      Virtual IP         server IP               localhost 127.0.0.1<br>
>                      secure              SSL terminate     unsecure<br>
<br>
</div>Interestingly, and separately, HAProxy can do SSL termination now, so<br>
we might want to consider just using HAProxy for that.<br>
<div class=""><br>
> 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.<br>

<br>
</div>But we do need to have HAProxy not wildcard bind, as Greg points out,<br>
and to make OS services bind to 127.0.0.1 as Jan pointed out.<br>
<br>
I suspect we need to put this through the specs process (which ops<br>
teams are starting to watch) to ensure we get enough input.<br>
<br>
I'd love to see:<br>
 - SSL by default<br>
 - A setup we can document in the ops guide / HA openstack install<br>
guide - e.g we don't need to be doing it a third different way (or we<br>
can update the existing docs if what we converge on is better).<br>
 - Only SSL enabled endpoints accessible from outside the machine (so<br>
python processes bound to localhost as a security feature).<br>
<br>
Eventually we may need to scale traffic beyond one HAProxy, at which<br>
point we'll need to bring something altogether more sophisticated in -<br>
lets design that when we need it.<br>
Sooner than that we're likely going to need to scale load beyond one<br>
control plane server at which point the HAProxy VIP either needs to be<br>
distributed (so active-active load receiving) or we need to go<br>
user -> haproxy (VIP) -> SSL endpoint (on any control plane node) -><br>
localhost bound service.<br>
<br>
HTH,<br>
Rob<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>