<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 17 January 2017 at 13:41, Dave McCowan (dmccowan) <span dir="ltr"><<a href="mailto:dmccowan@cisco.com" target="_blank">dmccowan@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div><br>
</div><div>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.</div></div></blockquote></div><br></div><div class="gmail_extra">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. <br></div><div class="gmail_extra"><br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br>Duncan Thomas</div></div></div>
</div></div>