Hi We don't have a strong attachment to stunnel though, I quickly dropped it in front of our CI/CD undercloud and Rob wrote the element so we could repeat the deployment.
In the fullness of time I would expect there to exist elements for several SSL terminators, but we shouldn't necessarily stick with stunnel because it happened to be the one I was most familiar with :) I would think that an httpd would be a good option to go with as the default, because I tend to think that we'll need an httpd running/managing the python code by default. Cheers, -- Chris Jones > On 26 Mar 2014, at 13:49, stuart.mcla...@hp.com wrote: > > Just spotted the openstack-ssl element which uses 'stunnel'... > > >> On Wed, 26 Mar 2014, stuart.mcla...@hp.com wrote: >> >> All, >> >> I know there's a preference for using a proxy to terminate >> SSL connections rather than using the native python code. >> >> There's a good write up of configuring the various proxies here: >> >> http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html >> >> If we're not using native python SSL termination in TripleO we'll >> need to pick which one of these would be a reasonable choice for >> initial https support. >> >> Pound may be a good choice -- its lightweight (6,000 lines of C), >> easy to configure and gives good control over the SSL connections (ciphers >> etc). >> Plus, we've experience with pushing large (GB) requests through it. >> >> I'm interested if others have a strong preference for one of the other >> options (stud, nginx, apache) and if so, what are the reasons you feel it >> would make a better choice for a first implementation. >> >> Thanks, >> >> -Stuart > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev