Open Stack

On Sun, Sep 4, 2016, at 10:51 AM, Gregory Haynes wrote:
> 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

Aaand I chopped off [1] -

1: https://review.openstack.org/#/c/364013/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160904/f3b61fe5/attachment.html>