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.i...@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 >> dtro...@gmail.com > > Cheers, > Greg
Aaand I chopped off [1] - 1: https://review.openstack.org/#/c/364013/
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
