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:sigmaviru...@gmail.com] > Sent: Monday, January 16, 2017 8:36 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@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- > requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
smime.p7s
Description: S/MIME cryptographic signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev