Open Stack

On Sat, Sep 3, 2016, at 09:41 AM, Dean Troyer wrote:
> 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.

I actually think the split isn't a bad idea - IMO I would have just made
one user facing var for the sake of simplicity (which is what Dean seems
to be proposing below) but internally its still probably good to make a
split between ssl frontend and internal apis. The way things are coded
this split is already paid for: service installers already bind to their
own internal port and tell the tls proxy about the mapping, and by
having the split we get a bunch of extra flexibility.

My thinking is that with [1] we can support a mix of services which
support ssl termination on their own (simply run them with ssl
termination on and have apache ssl to the backend as well), run only
http (done in the patch), or run within apache (keystone/horizon)
using a single service and code path which looks almost identical. It
also is trivial to support the use case Masanori was describing with
this setup (although I'm still unsure whether devstack actually wants
to support that).

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

Getting tls on by default is exactly what I was going for in
https://review.openstack.org/#/c/364016/2 but this is making me rethink
the method I proposed there. I now think the easiest way to attack this
is to make tls-proxy work again, and then make USE_SSL turn on tls-proxy
by default (or require it to be enabled). After that whether a service
manages ssl directly is an unrelated issue we can solve service-by-
service while still working and having tls on by default - we just turn
on tls for the services and have them tell the tls-proxy to talk to the
backend over tls.

>
> Eek, making DevStack more secure, who whoulda thunk it?
>
> dt
>
> --
>
> Dean Troyer
> dtroyer at gmail.com

Cheers,
Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160904/d6d850f2/attachment.html>