Description of problem: Backport https://bugs.launchpad.net/cinder/+bug/1558683 When a project is deployed behind a SSL terminating proxy, the version endpoint returns the wrong URLs. The returned protocol in the reponse URLs is http:// instead of the expected https://. This is because the response built by versions.py git the host information only from the incoming req. If SSL has been terminated by a proxy, then the information in the req indicates http://. Other projects have addressed this by adding the config parameter secure_proxy_ssl_header = HTTP_X_FORWARDED_PROTO. This will tell the project to use the value in X-Forwarded-Proto (https or http) when building the URLs in the response. Nova and Keystone support this configuration option. One workaround is to set the public_endpoint parameter. However, the value set for public_endpoint, is also returned when the internal and admin version endpoints are queried, which breaks other things. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Manual fix for cinder - need a similar patch for OSP 8: Apply the following to /etc/cinder/api-paste.ini ~~~ [root@overcloud-controller-0 cinder]# diff -u api-paste.ini.old api-paste.ini --- api-paste.ini.old 2017-05-16 00:28:25.787259053 +0000 +++ api-paste.ini 2017-05-16 00:45:41.301148877 +0000 @@ -10,19 +10,22 @@ [composite:openstack_volume_api_v1] use = call:cinder.api.middleware.auth:pipeline_factory -noauth = request_id faultwrap sizelimit osprofiler noauth apiv1 -keystone = request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv1 -keystone_nolimit = request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv1 +noauth = http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler noauth apiv1 +keystone = http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv1 +keystone_nolimit = http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv1 [composite:openstack_volume_api_v2] use = call:cinder.api.middleware.auth:pipeline_factory -noauth = request_id faultwrap sizelimit osprofiler noauth apiv2 -keystone = request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv2 -keystone_nolimit = request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv2 +noauth = http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler noauth apiv2 +keystone = http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv2 +keystone_nolimit = http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv2 [filter:request_id] paste.filter_factory = oslo_middleware.request_id:RequestId.factory +[filter:http_proxy_to_wsgi] +paste.filter_factory = oslo_middleware.http_proxy_to_wsgi:HTTPProxyToWSGI.factory + [filter:faultwrap] paste.filter_factory = cinder.api.middleware.fault:FaultWrapper.factory @@ -44,7 +47,7 @@ paste.app_factory = cinder.api.v2.router:APIRouter.factory [pipeline:apiversions] -pipeline = faultwrap osvolumeversionapp +pipeline = http_proxy_to_wsgi faultwrap osvolumeversionapp [app:osvolumeversionapp] paste.app_factory = cinder.api.versions:Versions.factory ~~~
https://access.redhat.com/solutions/3034681
Eric, Let me know if below is sufficient as verification. Version: openstack-cinder-7.0.3-6.el7ost.noarch From comment #1 my /etc/cinder/api-paste.ini includes updates. On an SSL enabled Overcloud, curled Cinder API ssl endpoint, response returns href in https as expected. [root@controller-0 ~]# curl -k https://10.0.0.101:13776 {"versions": [{"status": "SUPPORTED", "updated": "2014-06-28T12:20:21Z", "id": "v1.0", "links": [{"href": "https://10.0.0.101:13776/v1/", "rel": "self"}]}, {"status": "CURRENT", "updated": "2012-11-21T11:33:21Z", "id": "v2.0", "links": [{"href": "https://10.0.0.101:13776/v2/", "rel": "self"}]}]}[root@controller-0 ~]# If checks_^_verify: then "I'll close bug as verified" else: "What more to test?"
(In reply to Tzach Shefi from comment #4) Looks good to me.
Verified See #4
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:1467