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.
--Adam https://keybase.io/rm_you On 9/24/14 5:02 PM, "Eichberger, German" <german.eichber...@hp.com> 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... > >Thanks, >German > >-----Original Message----- >From: Adam Harwell [mailto:adam.harw...@rackspace.com] >Sent: Thursday, September 18, 2014 3:16 PM >To: OpenStack Development Mailing List (not for usage questions) >Cc: sbaluk...@bluebox.net; Doug Wiegley; Eichberger, German; Adam Young; >Balle, Susanne; Douglas Mendizabal >Subject: [openstack-dev] [Neutron][LBaaS] Interaction with Barbican and >Keystone > >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: > >http://i.imgur.com/VQcbGJS.png (I use the term "hijack" purposefully) > > >And here is a more detailed flow, including each and every operation: > >http://goo.gl/Wc8oIj > >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. >https://github.com/cloudkeep/postern > >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 > > >https://keybase.io/rm_you > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev