Open Stack

On 01/16/2017 08:35 AM, Ian Cordasco wrote:
> 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.

I don't pretend to have all the answers, but when doing some exploration
around the question of barbican as a default service during the late
summer, there were some community disconnects as well.

For instance, the barbican devstack plugin was just setting up barbican.
It wasn't actually configuring any existing services to use barbican, so
there wasn't any simple way to experiment with development with it (this
looks to have been fixed in Sept), or to understand gate reliability so
that it could be made less optional.

There was also a real concern about testability. For testing purposes
fixed key managers make a ton of sense, because you can crack them open
when things go wrong very easily to see what was going on. The barbican
team was pushing back on maintaining one of those on their side, because
it is inherently not secure. That moved the key manager plug point back
into the projects instead of a hard dependency on barbican, with a
testing mode that could be run. Joel and I had a long conversation about
this at the Nova midcycle in Portland. I'm not entirely sure where this
all landed.

There were also previous concerns about the stability of the API, where
version 2 -> 3 changes were made without a deprecation path or
guarantees. Only the fact that no one was deploying it saved people from
a pretty major upgrade breakage.

I think there is also a very real concern about how secure the secrets
are given how open ended the tokens are for users. Duncan raised this in
another part of the thread. From the outside it feels like Keystone and
Barbican need to be much closer integrated given that token security
implications directly impact on the security of the secrets in question.
If those things don't get solved coherently together, there are lots of
exposures there.

I definitely think that Barbican would be a good project to get elevated
to required component. Encrypting disks at rest by default with sane
keys should be standard behavior for an IaaS as it massively decreases
the data exposure of rogue VMs. (``dd if=/dev/vda | strings`` can turn
up interesting data in shared environments that aren't encrypted).

Doing so basically is going to require someone to champion project
managing this whole process, and discovering and bridging the existing
communication gaps that are there. There doesn't seem to be a ton of
natural overlap between contributors to barbican and the base IaaS
services today, which means plenty of communication gaps.

	-Sean

-- 
Sean Dague
http://dague.net