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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
