[openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

Ian Cordasco sigmavirus24 at gmail.com
Tue Jan 17 12:57:05 UTC 2017


On Mon, Jan 16, 2017 at 6:20 PM, Amrith Kumar <amrith.kumar at gmail.com> wrote:
> Ian,
>
> This is a fascinating conversation. Let me offer two observations.
>
> First, Trove has long debated the ideal solution for storing secrets. There
> have been many conversations, and Barbican has been considered many times.
> We sought input from people who were deploying and operating Trove at scale;
> customers of Tesora, self described users of the upstream Trove, and some of
> the (then) active contributors who were also operators.
>
> The consensus was that installing and deploying OpenStack was hard enough
> and requiring the installation of yet more services was problematic. This is
> not something which singles out Barbican in any way. For example, Trove uses
> Swift as the default object store where backups are stored, and in
> implementing replication we leveraged the backup capability. This means that
> to have replication, one needs to have Swift. Several deployers have
> objected to this since they don't have swift. But that is a dependency which
> we considered to be a hard dependency and offer no alternatives; you can
> have Ceph if you so desire but we still access it as a swift store.
> Similarly we needed some capabilities of job scheduling and opted to use
> mistral for this; we didn't reimplement all of these capabilities in Trove.
>
> However, when it comes to secret storage, the consensus of opinion is
> <eye-roll>Yet another service</eye-roll>.

So, what spurred this thread is that I'm currently working on Craton
which wants to store deployment secrets for operators and I've
recently received a lot of private mail about Glare and how one of its
goals is to replace Barbican (as well as Glance).

I'm quite happy that Trove has worked hard not to reimplement its
requirements that were already satisfied by OpenStack projects. That's
kind of what I'm hoping to help people do with Barbican in this
thread.

> Here is the second observation. This conversation reminds me of many
> conversations from years past "Why do you want to use a NoSQL database, we
> have a <name here> database already". I've sat in on heated arguments
> amongst architects who implemented "lightweight key-value storage based on
> <random NoSQL solution>" and didn't use the corporate standard RDBMS.

This I don't quite agree with this comparison. Surely when NoSQL came
out, people ridiculed it for not having the same properties as RDBMS,
but there's a large difference in people criticizing NoSQL databases
having not used them and me asking people to use software that's
already been audited for security and written by people who understand
the underlying technologies.

I'm sure if you said to your users and operators: "These N services
need to store secrets and each has implemented that in its own way
with no common configuration or storage location. None of them can
take advantage of HSMs you have present in your infrastructure, and
none of the people who really developed this are experts at storing
secrets, but they tried their best!" Those operators would start to
gnash their teeth and even maybe curse you under their breath. If you
said "These services all need to store secrets securely, and that
means we need to add Barbican which was written by people who took the
time to document their threat models, perform a security analysis, and
have worked with the larger security community to develop it." They'd
be happier. I do understand, however, that your customers aren't
deploying all the services that might use Barbican, and that's fine.

What I'm gleaning from this conversation is that most of us have
customers who only use 1 extra service that has a soft dependency on
Barbican but never more than one. I have customers using Octavia and
Magnum and a team that wants to use Craton, so it seems to me like we
would benefit from doing the hard work of deploying Barbican but that
situation is rare.

> Finally, it is my personal belief that making software pluggable such that
> "if it discovers Barbican, it uses it, if it discovers XYZ it uses it, if it
> discovers PQR it uses that ..." is a very expensive design paradigm.  Unless
> Barbican, PQR, XYZ and any other implementation provide such material value
> to the consumer, and there is significant deployment and usage of each, the
> cost of maintaining the transparent pluggability of these, the cost of
> testing, and development all add up very quickly.

I believe this is exactly what Castellan is designed to be. That
interface so that services that want to have a soft requirement on
Barbican can do so through Castellan.

> Which is why when some project wants to store a secret, it ciphers it using
> some one way hash and stuffs that in a database (if that's all it needs).

Sometimes you need to get that secret back out though and that one way
hash won't cut it. Also you have to balance what most people on this
list consider "normal" deployments of OpenStack against the increasing
demand to be able to deploy OpenStack on a FIPS compliant kernel, so
now we should all be designing our cryptographic based features in
ways that can satisfy both or have fallbacks in the case of FIPS.

Cheers
-- 
Ian Cordasco



More information about the OpenStack-dev mailing list