Open Stack

Excerpts from Adam Harwell's message of 2014-06-10 12:04:41 -0700:
> So, it looks like any sort of validation on Deletes in Barbican is going
> to be a no-go. I'd like to propose a third option, which might be the
> safest route to take for LBaaS while still providing some of the
> convenience of using Barbican as a central certificate store. Here is a
> diagram of the interaction sequence to create a loadbalancer:
> http://bit.ly/1pgAC7G
> 
> Summary: Pass the Barbican "TLS Container ID" to the LBaaS create call,
> get the container from Barbican, and store a "shadow-copy" of the
> container again in Barbican, this time on the LBaaS service account.
> The secret will now be duplicated (it still exists on the original tenant,
> but also exists on the LBaaS tenant), but we're not talking about a huge
> amount of data here -- just a few kilobytes. With this approach, we retain
> most of the advantages we wanted to get from using Barbican -- we don't
> need to worry about taking secret data through the LBaaS API (we still
> just take a barbicanID from the user), and the user can still use a single
> barbicanID (the original one they created -- the copies are invisible to
> them) when passing their TLS info to other services. We gain the
> additional advantage that it no longer matters what happens to the
> original TLS container -- it could be deleted and it would not impact our
> service.
> 
> What do you guys think of that option?

A user hands LBaaS an ID, and then deletes it, and expects that LBaaS
can continue working indefinitely? How is that user's reckless action
LBaaS's problem?

Do one thing: Be a good load balancer. Let users orchestrate your APIs
according to their use case and tools.