Open Stack

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