Yeah, I was hoping for something like that... Essentially, Horizon would
need to detect that particular response and be prepared to make a simple
Yes/No dialog pop up to create that Trust, then continue with the original
operation again automatically afterwards. That said, I have not looked at
programming Horizon interfaces at all yet, so I don't know how feasible
that is.


On 9/24/14 5:02 PM, "Eichberger, German" <> wrote:

>Hi Adam,
>For me the thing needs to be user friendly. So my main question is how do
>things look in Horizon? Will there just be a popup saying "Establish
>Trust (Y/N)". I am wondering as you how other teams are handling that...
>-----Original Message-----
>From: Adam Harwell []
>Sent: Thursday, September 18, 2014 3:16 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Cc:; Doug Wiegley; Eichberger, German; Adam Young;
>Balle, Susanne; Douglas Mendizabal
>Subject: [openstack-dev] [Neutron][LBaaS] Interaction with Barbican and
>I've made an attempt at mapping out exactly how Neutron Advanced Services
>will communicate with Barbican to retrieve Certificate/Key info for TLS
>purposes. This is far from solidified, since there are some issues that
>I'll go over momentarily. First, here is a *high level* diagram of the
>process flow:
> (I use the term "hijack" purposefully)
>And here is a more detailed flow, including each and every operation:
>There are some valid concerns about this workflow, and at least one issue
>that may be a blocker.
>Following are the two main issues that I've run into:
>1) Possible blocker: Keystone won't allow Trust creation using a Trust
>Token. Example: A user creates a Trust for Heat, and gives Heat their
>TrustID. The user configures Heat to spin up Load Balancers. Heat
>contacts LBaaS on behalf of the user with a Trust Token. LBaaS contacts
>Keystone to create a Trust using the token received from Heat. LBaaS
>would be unable to create a Trust because the Token we're trying to use
>doesn't have the ability to create Trusts, and our operation would fail.
>2) Security concern: If the Neutron/LBaaS config contains a Service
>Account's user/pass and Database URI/user/pass, then anyone with access
>to the config file would be able to connect to the DB, pull out TrustIDs,
>and use the Neutron Service Account to execute them. Essentially, the
>only difference between storing private keys directly in the database and
>storing them in Barbican is that there's one additional (trivial) step to
>get the key data (contact the Barbican API).
>The keystone folks I talked to (primarily Adam Young) suggested that the
>solution to issue #1 is to require the user to create the Trust
>beforehand in Keystone, then pass the TrustID to Neutron/LBaaS along with
>the ContainerID. This could originally be based on a "template" we
>provide to the user, probably in the form of a suggested JSON body and
>keystone URI.
>Eventually, there could/should/might be a system in place to allow
>services to pre-define a Trust with Keystone and the user would just need
>to tell Keystone that they accept that Trust. Either way, this would
>require action by the user before they could create a TLS Terminated LB.
>I don't particularly LIKE that option, but if 90% of our users come
>through Horizon anyway, it should be as simple as having Horizon pop up a
>Yes/No box prompting to enable the Trust when the user creates their
>first TLS LB.
>As for issue #2, I don't really have a solution to propose. There was
>some talk about the Postern project, but there isn't really any usable
>code yet, or even solid specs from what I can tell -- it looks like the
>project was proposed and never went past the PoC stage.
>I know there are some other teams looking into very similar issues, so I
>have a bit of research to do on that front, but in the meantime, what are
>people's thoughts? I've cc'd a few of the people who were already in the
>IRC version of this discussion (I may have missed anyone who wasn't
>already in my address book, sorry), but I'd love to hear from anyone who
>has ideas on the subject.
>       --Adam

OpenStack-dev mailing list

Reply via email to