Open Stack

On Fri, Sep 2, 2016 at 11:30 PM, Masanori Itoh <masanori.itoh at gmail.com>
wrote:

> It eliminates 'stud' usage and replace it by apache2/mod_ssl, right?
>
> But, there are use cases like:
>   - use apache2/mod_wsgi for better performance
>   and
>   - have an out-of-the-box SSL terminator (box)
>

What is the ongoing use case for a distinct terminator?  To simulate an
actual non-Apache terminator?  I really don't know how often this is
needed, if the TLS can be properly handled otherwise.


> Also, we have 'USE_TLS' option enabling to terminate SSL by
> apache2/mod_ssl.
>

This should become a default True


> So, I think it's better to leave 'tls-proxy' using a non-apache SSL
> terminater like 'stud' or 'hitch'
> as an option for the use case above.
> My fix is like that.
>
> What do you think about?
>

The addition of stud was originally driven in order to test client TLS
operation because of the mess that enabling SSL/TLS on the services
directly was at the time and haproxy was overkill.  The complicated split
configuration should really be an anti-pattern for OpenStack deployment and
needs to just go away in favor of a TLS-everywhere approach using
preferably Apache or haproxy (although this is still overkill for DevStack
IMHO).  We should be doing that anyway to ensure that all of the internally
used client libs are properly TLS-capable (I believe this is the case now).

The TLS_PROXY setting could either go away or be an alias for USE_TLS.  And
honestly, we should think about setting USE_TLS True by default anyway.

Eek, making DevStack more secure, who whoulda thunk it?

dt

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160903/7bea41a1/attachment.html>