Open Stack

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é <mgagne at calavera.ca> 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 <mnaser at vexxhost.com>
> 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 <suttles at gmail.com> 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 <bitskrieg at bitskrieg.net>
> > 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
> >> bitskrieg at bitskrieg.net
> >> 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 <bitskrieg at bitskrieg.net>
> >>> 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
> >>>> bitskrieg at bitskrieg.net
> >>>> https://www.bitskrieg.net
> >>>>
> >>>> _______________________________________________
> >>>> OpenStack-operators mailing list
> >>>> OpenStack-operators at lists.openstack.org
> >>>>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>
> >>
> >> _______________________________________________
> >> OpenStack-operators mailing list
> >> OpenStack-operators at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170223/9234fb42/attachment.html>