<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">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?<br>
<br>
Thanks,<br>
Kevin<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF818364"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Duncan Thomas [duncan.thomas@gmail.com]<br>
<b>Sent:</b> Tuesday, January 17, 2017 6:04 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?<br>
</font><br>
</div>
<div></div>
<div>
<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">
<div dir="ltr">
<div>-- <br>
Duncan Thomas</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>