There's a similar option in heat.conf: secure_proxy_ssl_header = X-Forwarded-Proto
Pretty sure that's needed for most services; I will scrub my configs and check. We are running a pretty simple install of Newton, and doing haproxy for SSL termination of all API endpoints. On Wed, Feb 22, 2017 at 9:58 AM, Chris Apsey <[email protected]> wrote: > Mathieu, > > That did the trick - thank you. On a related note, heat is exhibiting the > same behavior on some of the API calls (stack list works fine, stack show > does not because a http URL is returned in the 302 response field, etc.). > > I attempted the combination of 'oslo_middleware/enable_proxy_headers_parsing' > and 'oslo_middleware/secure_proxy_ssl_header' referenced here > https://docs.openstack.org/newton/config-reference/orchestration/api.html > along with the appropriate haproxy configuration suggested by Mike, but no > dice. The URL doesn't change. Beyond that, it looks like that option is > deprecated anyway (at least in heat), although I have not found any > indication about what is supposed to 'replace' those options going forward. > > Ideas? > > Thanks so much, > > --- > v/r > > Chris Apsey > [email protected] > https://www.bitskrieg.net > > On 2017-02-21 21:46, Mathieu Gagné wrote: > >> Hi, >> >> The problem is that Keystone doesn't know about HAProxy terminating >> the SSL connection and therefore doesn't know it needs to generate >> URLs with https:// protocol. >> >> You can override the "auto-detected" URLs with those configurations: >> - [DEFAULT]/public_endpoint >> - [DEFAULT]/admin_endpoint >> >> See documentation for a bit more explanation about those >> configurations: >> https://docs.openstack.org/draft/config-reference/identity/api.html >> -- >> Mathieu >> >> >> On Tue, Feb 21, 2017 at 8:56 PM, Chris Apsey <[email protected]> >> wrote: >> >>> I'm having a strange issue with keystone after migrating all public >>> endpoints to https (haproxy terminates the SSL connection for each >>> service): >>> >>> openstack endpoint list >>> >>> +----------------------------------+-----------+------------ >>> --+----------------+---------+-----------+------------------ >>> -------------------------------+ >>> | ID | Region | Service Name | Service >>> Type >>> | Enabled | Interface | URL | >>> +----------------------------------+-----------+------------ >>> --+----------------+---------+-----------+------------------ >>> -------------------------------+ >>> ... >>> | 99d302d00ab3461cb9362236c865a430 | RegionOne | keystone | identity >>> | True | public | https://some.domain.place:5000/v3 >>> | >>> ... >>> >>> I have also updated my rc files appropriately. Whenever I try and use >>> the >>> CLI against the public endpoints in debug mode, everything starts out >>> looking good: >>> >>> REQ: curl -g -i -X GET https://some.domain.place:5000/v3 -H "Accept: >>> application/json" -H "User-Agent: osc-lib keystoneauth1/2.12.1 >>> python-requests/2.11.1 CPython/2.7.9" >>> >>> But then, the response body gives a non-https URL: >>> >>> RESP BODY: {"version": {"status": "stable", "updated": >>> "2016-10-06T00:00:00Z", "media-types": [{"base": "application/json", >>> "type": >>> "application/vnd.openstack.identity-v3+json"}], "id": "v3.7", "links": >>> [{"href": "http://some.domain.place:5000/v3/", "rel": "self"}]}} >>> >>> and then the attempt to authenticate fails: >>> >>> Making authentication request to >>> http://some.domain.place:5000/v3/auth/tokens >>> Starting new HTTP connection (1): some.domain.place >>> Unable to establish connection to >>> http://some.domain.place:5000/v3/auth/tokens >>> >>> I've restarted apache2 on my keystone hosts and I have scoured the >>> database >>> for any reference to a non-https public endpoint for keystone; I cannot >>> find >>> one. >>> >>> Does anyone know why my response body is giving the wrong URL? Horizon >>> works perfectly fine with the https endpoints; it's just the command line >>> clients that are having issues. >>> >>> Thanks in advance, >>> >>> -- >>> v/r >>> >>> Chris Apsey >>> [email protected] >>> https://www.bitskrieg.net >>> >>> _______________________________________________ >>> OpenStack-operators mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >> > _______________________________________________ > OpenStack-operators mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
