Barbican single host setting does not work with internal and public endpoints

[Arun Kant]

Currently barbican derives construction of its href in response using a single host config setting as mentioned in link below.

https://github.com/openstack/barbican/blob/master/etc/barbican/barbican.conf#L17

https://github.com/openstack/barbican/blob/master/barbican/common/utils.py#L58

With this current setting, a single barbican deployment cannot support public as well as internal endpoints .

In a typical deployment, openstack services (IaaS layer) can invoke internal endpoints and some of services running in developer platform can invoke public endpoints for the services running within IaaS stack (or as platform). These 2 endpoints are different.

Concern is around only public and internal endpoint. Public and internal endpoint are used by client depending from which network they are accessing the service. In a deployment, these different URL provides capability of having different network capabilities e.g. one can have TLS for public endpoint communication and for internal communication TLS may not be mandatory.

Having these URLs hard-coded (defined) in barbican configuration limits the usefulness of keystone service catalog (and service's versioned endpoint(s)) as now we are maintaining endpoints at 2 places and need to be kept in sync.

Currently implemented version controller code does not suffer this issue. We do see this issue only where hrefs are returned in response.

[Ian Cordasco (icordasc)]

Review: https://review.openstack.org/#/c/282581/

[Arun Kant (arukant)]

Addressing this issue in review: https://review.openstack.org/#/c/282581/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/282581
Committed: https://git.openstack.org/cgit/openstack/barbican/commit/?id=19f69ccee2695028d13f4cbc234c62fd87a1017b
Submitter: Jenkins
Branch: master

commit 19f69ccee2695028d13f4cbc234c62fd87a1017b
Author: Arun Kant <email address hidden>
Date: Tue Feb 16 16:17:12 2016 -0800

    Adding support for barbican host href to be derived from wsgi request

    Currently barbican provides hostname part of hrefs returned in response
    based on host_href value defined in barbican.conf.

    This approach would not work if barbican API needs to be accessed via
    public or internal endpoint as they can be different endpoints in
    control planes. The endpoint used by client depends on which network client
    is making the API request. For same reasons, keystone also allows different
    endpoint for a service to expose as public or internal interface in service
    catalog.

    To allow that kind of deployment model for barbican service, now enhancing
    its logic to derive this hostname (http_scheme+host+port) information from
    wsgi requests when host_href value is not set in barbican.conf. So deployment
    requiring this behavior can leave host_href blank in their barbican.conf. The
    host_href needs to be set empty as not setting it results in default.

    Generally in this kind of deployment, proxy (e.g. haproxy) will set
    appropriate host, http scheme header. Request url received at barbican side
    will have the client IP address and scheme inserted directly inside it.
    Reference: https://en.wikipedia.org/wiki/X-Forwarded-For

    Updated existing 'change host header' related functional test to skip when
    host_href is not set in barbican server side. Added new functional tests when
    hrefs are derived from wsgi request. New tests are skipped when host_href is
    set at server side.

    Added a flag in barbican-functional.conf to indicate barbican server setting
    Default is to use CONF.host_href value. Explicit flag is added as functional
    test setup may not always have barbican server conf available locally.

    Change-Id: Idb8e62867f6cbd457eb64ea31500e93e74d247ea
    Closes-Bug: 1541118

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/barbican 3.0.0.0b2 development milestone.