Open Stack

-----Original Message-----
From: Jay Pipes <jaypipes at gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
Date: January 17, 2017 at 12:31:21
To: openstack-dev at lists.openstack.org <openstack-dev at 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