Open Stack

-----Original Message-----
From: Hayes, Graham <graham.hayes at hpe.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
Date: January 16, 2017 at 09:26:00
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
projects trying to avoid Barbican, still?

> On 16/01/2017 13:38, Ian Cordasco wrote:
> > 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 know that historically it was considered hard to do a HA deploy of
> Barbican. When we initially evaluated DNSSEC in Designate (many years
> ago now) it was one of the sticking points.
>
> This may have (and most likely has) changed, but we seem to have long
> memories.

I know Rackspace recently made Barbican available to its cloud
customers. I suspect it's easier now to perform an HA deploy.

> It could be a side effect of the Big Tent - there are so many projects
> doing so many different things that projects don't want deployers to
> have deploy everything.

Yeah, I completely understand that. The thing is that in one case,
there's a project that currently relies on Barbican and wants to
replace that with a completely brand new service that will be doing
other things and then wants to layer secrets on top of it. It seems to
me like a terrible case of both scope creep and not actually caring
about the security the users expect from services that have to
interact with secrets. N services (besides Barbican) implementing
their own secrets storage each in their own way seem like N different
services that will be dealing with vulnerabilities and security
releases for the next few years. Perhaps that's pessimistic, but
looking at that with my operator hat on, I'd rather have to update *1*
service (barbican) rather than N if there's some vulnerability that
comes up. It's the same argument when it comes down to packaging and
vendoring dependencies. Update once instead of N times for each
package that has a copy of the library bundled in it.

> > 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.
>
> +100 - One of the reasons we didn't just write our own signing was I
> am allergic to writing crypto code - I am not very good at it, and there
> is a project that people that either are, or know how to use the libs
> correctly.

I have the same allergy! This is why I've been pushing folks talking
about implementing their own secrets storage.

--
Ian Cordasco