Open Stack

On Thu, Sep 17, 2015 at 08:38:54PM -0400, Mathieu Gagné wrote:
> Hi,
> 
> While debugging LP bug #1491579 [1], we identified [2] an issue where an
> API sitting being a proxy performing SSL termination would not generate
> the right redirection. The protocol ends up being the wrong one (http
> instead of https) and this could hang your request indefinitely if
> tcp/80 is not opened and a firewall drops your connection.
> 
> I suggested [3] adding support for the X-Fowarded-Proto header, thinking
> Nova didn't supported it yet. In fact, someone suggested setting the
> public_endpoint config instead.
> 
> So today I stumbled across this review [4] which added the
> secure_proxy_ssl_header config to Nova. It allows the API to detect SSL
> termination based on the (suggested) header X-Forwarded-Proto just like
> previously suggested.
> 
> I also found this bug report [5] (opened in 2014) which also happens to
> complain about bad URLs when API is sitting behind a proxy.
> 
> Multiple projects applied patches to try to fix the issue (based on
> Launchpad comments):
> 
> * Glance added public_endpoint config
> * Cinder added public_endpoint config
> * Heat added secure_proxy_ssl_header config (through
> heat.api.openstack:sslmiddleware_filter)
> * Nova added secure_proxy_ssl_header config
> * Manila added secure_proxy_ssl_header config (through
> oslo_middleware.ssl:SSLMiddleware.factory)
> * Ironic added public_endpoint config
> * Keystone added secure_proxy_ssl_header config (LP #1370022)
> 
> As you can see, there is a lot of inconsistency between projects. (there
> is more but lets start with that one)
> 
> My wish is for a common and consistent way for *ALL* OpenStack APIs to
> support the same solution for this common problem. Let me tell you (and
> I guess I can speak for all operators), we will be very happy to have
> ONE config to remember of and set for *ALL* OpenStack services.
> 
> How can we get the ball rolling so we can fix it together once and for
> all in a timely fashion?

Totally agree. This seems like maybe a good thing for the API working
group to put together.

FWIW, in Ironic, we added the public_endpoint config to fix the bug
quickly, but we'd really prefer to support both that and the
secure_proxy_ssl_header option. It would use public_endpoint if it is
set, then fall back to the header config, then fall back to
request_host like it was before.

// jim