[openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

Duncan Thomas duncan.thomas at gmail.com
Tue Jan 17 14:04:03 UTC 2017


On 17 January 2017 at 13:41, Dave McCowan (dmccowan) <dmccowan at cisco.com>
wrote:

>
> I don't know everything that was proposed in the Juno timeframe, or
> before, but the Nova and Cinder integration has been done now.  The
> documentation is at [1].  A cinder user can create an encryption key
> through Barbican when creating a volume, then the same user (or a user with
> permissions granted by that user), as a nova user, can retrieve that key
> when mounting the encrypted volume.
>

Sure, cinder can add a secret and nova can retrieve it. But glance can
*also* retrieve it. So can trove. And any other service that gets a normal
keystone token from the user (i.e. just about all of them). This is, for
some threat models, far worse that the secret being nice and safe int he
cinder DB and only ever given out to nova via a trusted API path. The
original design vision I saw for barbican was intended to have much better
controls than this, but they never showed up AFAIK. And that's just the
problem - people think 'Oh, barbican is storing the cinder volume secrets,
great, we're secure' when actually barbican has made the security situation
worse not better. It's a pretty terrible secrets-as-a-service product at
the moment. Fixing it is not trivial.

-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170117/58e494c6/attachment.html>


More information about the OpenStack-dev mailing list