Open Stack

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>.

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.

One size doesn't fit all. And today, ten years on, it is clear that there
are legitimate situations where one would be silly to require an architect
to use a RDBMS; we talk of polyglot persistence as a matter of course.

The thing is this; Barbican may be a fine project with a ton of capabilities
that I don't even know of nor have the ability to comprehend. But there's a
minimum threshold of requirements that I need to have before the benefit of
the new dependency becomes valuable. From Trove's perspective, I don't
believe we have crossed that threshold (yet). If Barbican were a library not
a project, it may be a much easier sell for deployers.

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.

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).

My 2c is that requiring projects to use Barbican as the secret store is the
equivalent of requiring developers (10 years ago) to use an RDBMS. One size
doesn't fit all ... Barbican is a "one size" secret store, I don't need all
of the bells and whistles just as the guy who wants a key value store
doesn't mind eventual consistency, lost writes, but can't take the cost of a
traditional RDBMS.

Thanks,

-amrith



> -----Original Message-----
> From: Ian Cordasco [mailto:sigmavirus24 at gmail.com]
> Sent: Monday, January 16, 2017 8:36 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [all] [barbican] [security] Why are projects
trying to
> avoid Barbican, still?
> 
> Hi everyone,
> 
> I've seen a few nascent projects wanting to implement their own secret
> storage to either replace Barbican or avoid adding a dependency on it.
> When I've pressed the developers on this point, the only answer I've
> received is to make the operator's lives simpler.
> 
> I've been struggling to understand the reasoning behind this and I'm
> wondering if there are more people around who can help me understand.
> 
> To help others help me, let me provide my point of view. Barbican's been
> around for a few years already and has been deployed by several companies
> which have probably audited it for security purposes. Most of the
technology
> involved in Barbican is proven to be secure and the way the project has
> strung those pieces together has been analyzed by the OSSP (OpenStack's
> own security group). It doesn't have a requirement on a hardware TPM
> which means there's no hardware upgrade cost. Furthermore, several
> services already provide the option of using Barbican (but won't place a
hard
> requirement on it). It stands to reason (in my opinion) that if new
services
> have a need for secrets and other services already support using Barbican
as
> secret storage, then those new services should be using Barbican. It seems
a
> bit short-sighted of its developers to say that their users are definitely
not
> deploying Barbican when projects like Magnum have soft dependencies on
> it.
> 
> Is the problem perhaps that no one is aware of other projects using
> Barbican? Is the status on the project navigator alarming (it looks like
some of
> this information is potentially out of date)? Has Barbican been deemed too
> hard to deploy?
> 
> I really want to understand why so many projects feel the need to
> implement their own secrets storage. This seems a bit short-sighted and
> foolish. While these projects are making themselves easier to deploy, if
not
> done properly they are potentially endangering their users and that seems
> like a bigger problem than deploying Barbican to me.
> 
> --
> Ian Cordasco
> Glance, Hacking, Bandit, and Craton core reviewer
> 
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4815 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170116/6fdaeaa5/attachment.bin>