-----Original Message----- From: Jay Pipes <jaypi...@gmail.com> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Date: January 17, 2017 at 12:31:21 To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?
> On 01/17/2017 07:57 AM, Ian Cordasco wrote: > > On Mon, Jan 16, 2017 at 6:20 PM, Amrith Kumar 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 > >> Yet another service. > > > > 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). > > Problem #1: private emails. Why? Encourage whomever is privately > emailing you to instead post to the mailing list, otherwise parties are > not acting in the Open[Stack] Way. That has come up with those people. > Problem #2: What does Glare have to do with secret storage? I can > understand someone saying that Glare might eventually replace Glance, > but I'm not aware of anyone ever building crypto use cases or > functionality into the design of Glare. Ever. This is exactly my understanding as well. Glare was meant to be an artifact service, not a secrets service. I guess a reductionist could claim all data is an artifact, but that's obviously a flawed argument. -- Ian Cordasco __________________________________________________________________________ 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