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

Reply via email to