[openstack-dev] [all] Consistent support for SSL termination proxies across all API services
Sean Dague
sean at dague.net
Wed Sep 23 18:17:35 UTC 2015
On 09/23/2015 07:36 AM, Julien Danjou wrote:
> On Wed, Sep 23 2015, Sean Dague wrote:
>
>> Does that solution work in the HA Proxy case where there is one
>> terminating address for multiple backend servers?
>
> Yep.
Ok, how exactly does that work? Because it seems like
oslo_middleware.ssl is only changing the protocol if the proxy sets it.
But the host in the urls will still be the individual host, which isn't
the proxy hostname/ip. Sorry if I'm being daft here, just want to
understand how that flow ends up working.
>> Because there is the concern that this impacts not only the Location
>> header, but the link documents inside the responses which clients are
>> expected to be able to link.follow. This is an honest question, I
>> don't know how the oslo_middleware.ssl acts in these cases. And HA
>> Proxy 1 to N mapping is very common deployment model.
>
> It should, but some project like Keystone does not handle that
> correctly. I just submitted a patch that fixes this kind of thing by
> using correctly the WSGI environment variable to build a correct URL.
> That fixes also the use cases where Keystone does not run on / but on
> e.g. /identity (the bug I initially wanted to fix).
>
> https://review.openstack.org/#/c/226464/
>
> If you use `wsgiref.util.application_uri(environment)' it should do
> everything correctly. With the SSL middleware enabled that Mathieu
> talked about, it will translate correctly http to https too.
Will that cover the case of webob's request.application_uri? If so I
think that covers the REST documents in at least Nova (one good data
point, and one that I know has been copied around). At least as far as
the protocol is concerned, it's still got a potential url issue.
> The {public,admin}_endpoint are only useful in the case where you map
> http://myproxy/identity -> http://mykeystone/ using a proxy
>
> Because the prefix is not passed to Keystone. If you map 1:1 the path
> part, we could also leverage X-Forwarded-Host and X-Forwarded-Port to
> avoid having {public,admin}_endpoint options.
It also looks like there are new standards for Forwarded headers, so the
middleware should probably support those as well.
http://tools.ietf.org/html/rfc7239.
-Sean
--
Sean Dague
http://dague.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150923/1b1ea40e/attachment.pgp>
More information about the OpenStack-dev
mailing list