It is also possible to use oslo_middleware ssl filter in your API paste file with cinder like:
[filter:ssl] paste.filter_factory = oslo_middleware.ssl:SSLMiddleware.factory [pipeline:apiversions] pipeline = ssl faultwrap osvolumeversionapp On Wed, Feb 22, 2017 at 2:54 PM Mathieu Gagné <[email protected]> wrote: > Hi, > > I attended to write a blog post about that subject more than a year > ago but never completed it. > > Here is the text in a GitHub Gist: > https://gist.github.com/mgagne/f298c151b61d44cb5fea > > Information might be outdated for latest versions but can still give > you a clue about what to look for. > > -- > Mathieu > > > On Wed, Feb 22, 2017 at 3:37 PM, Mohammed Naser <[email protected]> > wrote: > > I would appreciate it if you can let us know which one it is for Cinder, > as > > it looks like there is no SSL middleware for Cinder which allows doing > this. > > > > Thanks > > > > On Feb 22, 2017, at 1:43 PM, Chris Suttles <[email protected]> wrote: > > > > 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 > > > > > > > > _______________________________________________ > > 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
