Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
On 09/28/2015 05:01 AM, Julien Danjou wrote: > On Wed, Sep 23 2015, Julien Danjou wrote: > > > […] > >> I'm willing to clear that out and come with specs and patches if that >> can help. :) > > Following-up on myself, I went ahead and I wrote a more complete version > of the current proxy middleware we have – which also supports RFC7239: > > https://review.openstack.org/#/c/227868/ > > With that in place, having a proxy (SSL or not) correctly configured in > front of any WSGI application should be completely transparent for the > application, with no need of additional configuration. > > If that suits everyone, I'll then propose deprecation of the > oslo_middleware.ssl middleware in favor of this one. Great, thanks, Julien, that looks like a good ball to move forward here in Mitaka. My +1 added to the patch. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
On Wed, Sep 23 2015, Julien Danjou wrote: […] > I'm willing to clear that out and come with specs and patches if that > can help. :) Following-up on myself, I went ahead and I wrote a more complete version of the current proxy middleware we have – which also supports RFC7239: https://review.openstack.org/#/c/227868/ With that in place, having a proxy (SSL or not) correctly configured in front of any WSGI application should be completely transparent for the application, with no need of additional configuration. If that suits everyone, I'll then propose deprecation of the oslo_middleware.ssl middleware in favor of this one. -- Julien Danjou -- Free Software hacker -- http://julien.danjou.info signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
On 09/24/2015 03:40 AM, Julien Danjou wrote: > On Thu, Sep 24 2015, Jamie Lennox wrote: > > Hi Jamie, > >> So this is a long thread and i may have missed something in it, >> however this exact topic came up as a blocker on a devstack patch to >> get TLS testing in the gate with HAproxy. >> >> The long term solution we had come up with (but granted not proposed >> anywhere public) is that we should transition services to use relative >> links. > > This would be a good solution too indeed, but I'm not sure it's *always* > doable. > >> As far as i'm aware this is only a problem within the services >> themselves as the URL they receive is not what was actually requested >> if it went via HAproxy. It is not a problem with interservice requests >> because they should get URLs from the service catalog (or otherwise >> not display them to the user). Which means that this generally affects >> the version discovery page, and "links" from resources to like a next, >> prev, and base url. > > Yes, but what we were saying is that this is fixable by using HTTP > headers that the proxy set, and translating them to a correct WSGI > environment. Basically, that will make think WSGI that it's a front-end, > so it'll build URL correctly for the outer world. > >> Is there a reason we can't transition this to use a relative URL >> possibly with a django style WEBROOT so that a discovery response >> returned /v2.0 and /v3 rather than the fully qualified URL and the >> clients be smart enough to figure this out? > > We definitely can do that, but there is still a use case that would not > be covered without a configuration somewhere which is: > e.g. http://foobar/myservice/v3 -> http://myservice/v3 > > If you return an absolute /v3, it won't work. :) It's also a pretty serious change in document content. We've been returning absolute URLs forever, so assuming that all the client code out there would work with relative code is a really big assumption. That's a major API bump for sure. And it seems like we have enough pieces here to get something better with the proxy headers (which could happen early in Mitaka) and to fill in the remaining bits if we clean up the service catalogue use. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
On Thu, Sep 24 2015, Jamie Lennox wrote: Hi Jamie, > So this is a long thread and i may have missed something in it, > however this exact topic came up as a blocker on a devstack patch to > get TLS testing in the gate with HAproxy. > > The long term solution we had come up with (but granted not proposed > anywhere public) is that we should transition services to use relative > links. This would be a good solution too indeed, but I'm not sure it's *always* doable. > As far as i'm aware this is only a problem within the services > themselves as the URL they receive is not what was actually requested > if it went via HAproxy. It is not a problem with interservice requests > because they should get URLs from the service catalog (or otherwise > not display them to the user). Which means that this generally affects > the version discovery page, and "links" from resources to like a next, > prev, and base url. Yes, but what we were saying is that this is fixable by using HTTP headers that the proxy set, and translating them to a correct WSGI environment. Basically, that will make think WSGI that it's a front-end, so it'll build URL correctly for the outer world. > Is there a reason we can't transition this to use a relative URL > possibly with a django style WEBROOT so that a discovery response > returned /v2.0 and /v3 rather than the fully qualified URL and the > clients be smart enough to figure this out? We definitely can do that, but there is still a use case that would not be covered without a configuration somewhere which is: e.g. http://foobar/myservice/v3 -> http://myservice/v3 If you return an absolute /v3, it won't work. :) -- Julien Danjou // Free Software hacker // http://julien.danjou.info signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
So this is a long thread and i may have missed something in it,
however this exact topic came up as a blocker on a devstack patch to
get TLS testing in the gate with HAproxy.
The long term solution we had come up with (but granted not proposed
anywhere public) is that we should transition services to use relative
links.
As far as i'm aware this is only a problem within the services
themselves as the URL they receive is not what was actually requested
if it went via HAproxy. It is not a problem with interservice requests
because they should get URLs from the service catalog (or otherwise
not display them to the user). Which means that this generally affects
the version discovery page, and "links" from resources to like a next,
prev, and base url.
Is there a reason we can't transition this to use a relative URL
possibly with a django style WEBROOT so that a discovery response
returned /v2.0 and /v3 rather than the fully qualified URL and the
clients be smart enough to figure this out?
On 24 September 2015 at 07:51, Julien Danjou wrote:
> On Wed, Sep 23 2015, Sean Dague wrote:
>
>> 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.
>
> No problem, you're no supposed to know everything. :)
>
> As ZZelle said too, we can set the correct host and port expected by
> honoring X-Forwarded-Host and X-Forwarded-Port, which are set by HTTP
> proxies when they act as reverse-proxies and forward requests.
> That will make the WSGI application unaware of the fact that there is a
> request proxy in front of them. Magic!
>
> We could do that in the SSL middleware (and maybe rename it?) or in
> another middleware, and enable them by default. So we'd have that
> working by default, which would be great IMHO.
>
>> 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.
>
> That should work with any WSGI request, so I'd say yes.
>
>>> 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.
>
> Good point, we should update the middleware as needed.
>
> Though they still not cover that use case where you have a base URL that
> is different between the proxy and the application. I don't think it's a
> widely used case, but still, there are at 2 least two way to support it:
> 1. Having config option (like Keystone currently has)
> 2. Having a special e.g. X-Forwarded-BaseURL header set by the proxy
>that we would catch in our middleware and would prepend to
>environment['SCRIPT_NAME'].
>
> The 2 options are even compatible, though I'd say 2. is probably simpler
> in the long run and more… "unified".
>
> I'm willing to clear that out and come with specs and patches if that
> can help. :)
>
> --
> Julien Danjou
> # Free Software hacker
> # http://julien.danjou.info
>
> __
> 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
>
__
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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
On Wed, Sep 23 2015, Sean Dague wrote:
> 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.
No problem, you're no supposed to know everything. :)
As ZZelle said too, we can set the correct host and port expected by
honoring X-Forwarded-Host and X-Forwarded-Port, which are set by HTTP
proxies when they act as reverse-proxies and forward requests.
That will make the WSGI application unaware of the fact that there is a
request proxy in front of them. Magic!
We could do that in the SSL middleware (and maybe rename it?) or in
another middleware, and enable them by default. So we'd have that
working by default, which would be great IMHO.
> 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.
That should work with any WSGI request, so I'd say yes.
>> 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.
Good point, we should update the middleware as needed.
Though they still not cover that use case where you have a base URL that
is different between the proxy and the application. I don't think it's a
widely used case, but still, there are at 2 least two way to support it:
1. Having config option (like Keystone currently has)
2. Having a special e.g. X-Forwarded-BaseURL header set by the proxy
that we would catch in our middleware and would prepend to
environment['SCRIPT_NAME'].
The 2 options are even compatible, though I'd say 2. is probably simpler
in the long run and more… "unified".
I'm willing to clear that out and come with specs and patches if that
can help. :)
--
Julien Danjou
# Free Software hacker
# http://julien.danjou.info
signature.asc
Description: PGP signature
__
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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
Hi > 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. > Host and X-Forwarded-Proto headers are provided by the proxy to the service. Host and X-Forwarded-Proto headers are either built by the proxy or forwarded (if there are many proxies). > 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. I let Julien answers :) > 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. > Good to know! I can update SSLMiddleware to handle it as the rfc uses the format: "Forwarded: proto=https" which is different from de facto standard (supported by SSLMiddleware): "X-Forwarded-Proto: https" Cédric __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
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
signature.asc
Description: OpenPGP digital signature
__
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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
On Wed, Sep 23 2015, ZZelle wrote: > * It doesn't work when the service itself acts as a proxy (typically nova > image-list) > * it doesn't work when you rewrite from > https://://... > to http://:/... > because the information is not provided in the headers (except if > you exploit a webob limitation) Yup, that's what I wrote in my previous mail – that's the only case not covered correctly except if you have specific oslo.config option à la Keystone. Though we could also use and document a header that we would use inside OpenStack to pass the around. That would avoid having anything to configure in each service, just setting a proper header in your proxy. Which means less configuration to do for OpenStack – always a good thing IMHO. -- Julien Danjou # Free Software hacker # http://julien.danjou.info signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
Hi, SSLMiddleware takes into account a Header[1] to set wsgi.url_scheme which allows a proxy to provide the original protocol to Heat/Neutron/... Does that solution work in the HA Proxy case where there is one > terminating address for multiple backend servers? 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 ensures the protocol provided in headers will be used to generate correct Location Headers and links. BUT there are some limitations: * It doesn't work when the service itself acts as a proxy (typically nova image-list) * it doesn't work when you rewrite from https://://... to http://:/... because the information is not provided in the headers (except if you exploit a webob limitation) Cédric/ZZelle@IRC __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
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.
> 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.
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.
--
Julien Danjou
-- Free Software hacker
-- http://julien.danjou.info
signature.asc
Description: PGP signature
__
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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
On 09/22/2015 05:30 PM, Mathieu Gagné wrote:
> On 2015-09-22 4:52 PM, Sean Dague wrote:
>> On 09/22/2015 03:16 PM, Mathieu Gagné wrote:
>>>
>>> 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.
>>
>> I do get there are specific edge cases here, but I don't think that in
>> the general case we should be pushing a mode where Keystone is optional.
>> It is a bedrock of our system.
>>
>
> I understand that Keystone is "a bedrock of our system". This however
> does not make it THE solution when simpler proven existing ones exist. I
> fail to understand why other solutions can't be considered.
>
> I opened a dialog with the community to express my concerns about the
> lack of universal support for SSL termination proxy so we can find a
> solution together which will cover ALL use cases.
>
> I proposed using an existing solution (oslo_middleware.ssl) (that I
> didn't know of until now) which takes little to no time to implement and
> cover a lot of use cases and special edge cases.
Does that solution work in the HA Proxy case where there is one
terminating address for multiple backend servers? 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.
The dialog isn't over, this is still an exploration. Nothing's going to
happen in code right now, because everything is in deep freeze for the
RC spins, the release, and summit planning. But we do need all the cards
on the table about options and trade offs if we are going to get 20+
projects aligned on a thing.
> Operators encounters and *HAVE* to handle a lot of edge cases. We are
> trying *very hard* to open up a dialog with the developer community so
> they can be heard, understood and addressed by sharing our real world
> use cases.
>
> In that specific case, my impression is that they unfortunately happens
> to not be a priority when evaluating solutions and will actually make my
> job harder. I'm sad to see we can't come with an agreement on that one.
> I feel like I failed to properly communicate my needs as an operator and
> make them understood to others.
Here is the parameter space we are playing with:
1. Are the "Location:" headers correct, or understood in a way that
clients will do the right thing:
a. when direct connected
b. when connected in a 1 to 1 SSL termination proxy
c. when connected in a 1 to N HA Proxy
2. Are the links provided in REST documents correct, or understood in a
way that libraries like requests / phantomjs can follow links natively:
a. when direct connected
b. when connected in a 1 to 1 SSL termination proxy
c. when connected in a 1 to N HA Proxy
3. Are the minority of services that have "operate without keystone" as
a design tenant able to function.
a. when direct connected
b. when connected in a 1 to 1 SSL termination proxy
c. when connected in a 1 to N HA proxy
Today {1,2,3}{a} are handled by services auto figuring out their URL.
That might mean that you jump across from internalURL to publicURL when
following links, because the addresses in the documents are what the
server believes it's URL is.
{1,2,3}{b,c} are handled by manually configuring each api daemon about
what it's URL should be. Recent experiences with a novaclient release
demonstrated that a lot of people aren't actually doing that.
The answer to 3,c seems like it's always going to be manual.
The X-Forwarded-* headers seem like they address {1,3}{b} fine. But the
implications on {1,2,3}{c} are unclear. It's also unclear how {2}{b}
functions in that model and if the clients will interpret that in all
scenarios even document links.
Upgrading the service catalog usage would address {1,2}{a,b,c}, but make
{3}{b} live in the land of manual configs.
We need to get the full map out here, and help fill in details of where
our holes are, which solutions plug which ones, and what set of
tradeoffs we're going to be working around in future releases. Once
we've got that, and our solution going forward, we can start banging the
drum to get all the projects headed in a direction here.
-Sean
--
Sean Dague
http://dague.net
__
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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
On Tue, Sep 22, 2015 at 05:30:36PM -0400, Mathieu Gagné wrote: > On 2015-09-22 4:52 PM, Sean Dague wrote: > > On 09/22/2015 03:16 PM, Mathieu Gagné wrote: > >> > >> 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. > > > > I do get there are specific edge cases here, but I don't think that in > > the general case we should be pushing a mode where Keystone is optional. > > It is a bedrock of our system. > > > > I understand that Keystone is "a bedrock of our system". This however > does not make it THE solution when simpler proven existing ones exist. I > fail to understand why other solutions can't be considered. > > I opened a dialog with the community to express my concerns about the > lack of universal support for SSL termination proxy so we can find a > solution together which will cover ALL use cases. > > I proposed using an existing solution (oslo_middleware.ssl) (that I > didn't know of until now) which takes little to no time to implement and > cover a lot of use cases and special edge cases. > > Operators encounters and *HAVE* to handle a lot of edge cases. We are > trying *very hard* to open up a dialog with the developer community so > they can be heard, understood and addressed by sharing our real world > use cases. > > In that specific case, my impression is that they unfortunately happens > to not be a priority when evaluating solutions and will actually make my > job harder. I'm sad to see we can't come with an agreement on that one. > I feel like I failed to properly communicate my needs as an operator and > make them understood to others. FWIW, Ironic fully supports a standalone deployment, and will continue to do that for the foreseeable future. If it means we need a config that is inconsistent with the rest of OpenStack, that's what we'll be doing. // jim __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
On 2015-09-22 4:52 PM, Sean Dague wrote: > On 09/22/2015 03:16 PM, Mathieu Gagné wrote: >> >> 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. > > I do get there are specific edge cases here, but I don't think that in > the general case we should be pushing a mode where Keystone is optional. > It is a bedrock of our system. > I understand that Keystone is "a bedrock of our system". This however does not make it THE solution when simpler proven existing ones exist. I fail to understand why other solutions can't be considered. I opened a dialog with the community to express my concerns about the lack of universal support for SSL termination proxy so we can find a solution together which will cover ALL use cases. I proposed using an existing solution (oslo_middleware.ssl) (that I didn't know of until now) which takes little to no time to implement and cover a lot of use cases and special edge cases. Operators encounters and *HAVE* to handle a lot of edge cases. We are trying *very hard* to open up a dialog with the developer community so they can be heard, understood and addressed by sharing our real world use cases. In that specific case, my impression is that they unfortunately happens to not be a priority when evaluating solutions and will actually make my job harder. I'm sad to see we can't come with an agreement on that one. I feel like I failed to properly communicate my needs as an operator and make them understood to others. -- 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
On 09/22/2015 03:16 PM, Mathieu Gagné wrote: > 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. I do get there are specific edge cases here, but I don't think that in the general case we should be pushing a mode where Keystone is optional. It is a bedrock of our system. -Sean -- Sean Dague http://dague.net __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
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 __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
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 __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
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 -- 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
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. __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
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 -- Sean Dague http://dague.net __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
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. -Ben On 09/17/2015 07:38 PM, 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? > > [1] https://bugs.launchpad.net/python-novaclient/+bug/1491579 > [2] https://bugs.launchpad.net/python-novaclient/+bug/1491579/comments/15 > [3] https://bugs.launchpad.net/python-novaclient/+bug/1491579/comments/17 > [4] https://review.openstack.org/#/c/206479/ > [5] https://bugs.launchpad.net/glance/+bug/1384379 > __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
+1 From: Mathieu Gagné [mga...@internap.com] Sent: Thursday, September 17, 2015 5:38 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services 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? [1] https://bugs.launchpad.net/python-novaclient/+bug/1491579 [2] https://bugs.launchpad.net/python-novaclient/+bug/1491579/comments/15 [3] https://bugs.launchpad.net/python-novaclient/+bug/1491579/comments/17 [4] https://review.openstack.org/#/c/206479/ [5] https://bugs.launchpad.net/glance/+bug/1384379 -- 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 __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
On 18 Sep 2015 05:13, "Jim Rollenhagen" wrote: > 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. This seems like the most sensible arrangement and the one if be happy meeting for cinder. If the originator would like to file a bug against cinder for the missing proto header support then I don't expect any resistance to it being fixed. Is there anybody with the time to start analysing different project's config files and documenting the likely cross-project ones? I know glance had a bunch of ssl related ones that were richer than most projects, for example. __ 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
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
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 __ 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
[openstack-dev] [all] Consistent support for SSL termination proxies across all API services
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? [1] https://bugs.launchpad.net/python-novaclient/+bug/1491579 [2] https://bugs.launchpad.net/python-novaclient/+bug/1491579/comments/15 [3] https://bugs.launchpad.net/python-novaclient/+bug/1491579/comments/17 [4] https://review.openstack.org/#/c/206479/ [5] https://bugs.launchpad.net/glance/+bug/1384379 -- 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
