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

Sean Dague sean at dague.net
Tue Sep 22 17:34:42 UTC 2015


On 09/22/2015 11:34 AM, Ben Nemec wrote:
> On 09/22/2015 06:00 AM, Sean Dague wrote:
>> On 09/18/2015 02:30 PM, Ben Nemec wrote:
>>> I've been dealing with this issue lately myself, so here's my two cents:
>>>
>>> It seems to me that solving this at the service level is actually kind
>>> of wrong.  As you've discovered, that requires changes in a bunch of
>>> different places to address what is really an external issue.  Since
>>> it's the terminating proxy that is converting HTTPS traffic to HTTP that
>>> feels like the right place for a fix IMHO.
>>>
>>> My solution has been to have the proxy (HAProxy in my case) rewrite the
>>> Location header on redirects (one example for the TripleO puppet config
>>> here: https://review.openstack.org/#/c/223330/1/manifests/loadbalancer.pp).
>>>
>>> I'm not absolutely opposed to having a way to make the services aware of
>>> external SSL termination to allow use of a proxy that can't do header
>>> rewriting, but I think proxy configuration should be the preferred way
>>> to handle it.
>>
>> 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.
>>
>> 	-Sean
>>
> 
> That also seems perfectly reasonable, although it looks like we're not
> using the service catalog internally now?  I see hard-coded endpoints in
> nova.conf for the services it talks to.

Nova uses it for cinder, and can for neutron, not for glance. A big part
of this is that people kept doing end runs around it instead of thinking
about how we make service discovery a base thing that all services use
in talking to each other or reflecting back to the user.

https://review.openstack.org/#/c/181393/ is an attempt to try to get a
handle on the whole situation.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list