On 2015-09-22 1:46 PM, Sean Dague wrote: > 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.
We are using a dedicated catalog for internal usage and override service endpoint wherever possible in OpenStack services. We don't use publicURL, internalURL or adminURL. > 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. The oslo_middleware.ssl middleware looks to offer little overhead and offer the maximum flexibility. I appreciate the wish to use the Keystone catalog but I don't feel this is the right answer. For example, if I deploy Bifrost without Keystone, I won't have a catalog to rely on and will still have the same lack of SSL termination proxy support. The simplest solution is often the right one. -- Mathieu __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
