[openstack-dev] [all] Consistent support for SSL termination proxies across all API services

Sean Dague sean at dague.net
Tue Sep 22 17:46:10 UTC 2015


On 09/22/2015 12:12 PM, Mathieu Gagné wrote:
> On 2015-09-22 7:00 AM, Sean Dague wrote:
>>
>> My feeling on this one is that we've got this thing in OpenStack... the
>> Service Catalog. It definitively tells the world what the service
>> addresses are.
>>
>> We should use that in the services themselves to reflect back their
>> canonical addresses. Doing point solution rewriting of urls seems odd
>> when we could just have Nova/Cinder/etc return documents with URLs that
>> match what's in the service catalog for that service.
>>
> 
> Sorry, this won't work for us. We have a "split view" in our service
> catalog where internal management nodes have a specific catalog and
> public nodes (for users) have a different one.
> 
> Implementing the secure_proxy_ssl_header config would require close to
> little code change to all projects and accommodate our use case and
> other ones we might not think of. For example, how do you know "from"
> which of the following URLs (publicURL, internalURL, adminURL) the users
> is coming? Each might be different and even not all be SSL.
> 
> The oslo.middleware project already has the SSL middleware [1]. It would
> only be a matter of enabling this middleware by default in the paste
> config of all projects.
> 
> [1]
> https://github.com/openstack/oslo.middleware/blob/master/oslo_middleware/ssl.py

The split view definitely needs to be considered, but a big question
here is whether we should really be doing this with multiple urls per
catalog entry, or dedicated catalog entries for internal usage.

There are a lot of things to work through to get our use of the service
catalog consistent and useful going forward. I just don't relish another
layer of work arounds that decide the service catalog is not a good way
to keep track of what our service urls are, that has to be unwound later.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list