Open Stack

Is this a Barbican problem or a Keystone one? The inability to restrict a token to go only to one service but instead any hacked service can be used to get tokens that can be used on any other service seems to to me to be a more general Keystone architectural problem to solve?

Thanks,
Kevin
________________________________
From: Duncan Thomas [duncan.thomas at gmail.com]
Sent: Tuesday, January 17, 2017 6:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?



On 17 January 2017 at 13:41, Dave McCowan (dmccowan) <dmccowan at cisco.com<mailto: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/5d078244/attachment.html>