<div dir="ltr">I would consider that to be something that spans further than just barbican and keystone. The ability to restrict a token to a single service/operation/resource is a super interesting problem especially when you start to consider operational dependencies between the services. If the approach spans multiple service (which in this case I think it would need to since it seems closely related to policy) communication gaps will only make achieving it harder. I think Sean nailed it with his comment about championing an effort across projects and closing communication gaps. We are currently doing this on a smaller scale with the horizon team to smooth out issues between horizon and keystone based on a set of things discussed in Barcelona [0]. It's seems to be proving successful for both teams.<div><br></div><div>I'd love to set aside some time to get a discussion rolling in Atlanta about this.<br><div><div><br></div><div><br></div><div>[0] <a href="http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting">http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting</a></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 17, 2017 at 10:55 AM, Fox, Kevin M <span dir="ltr"><<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div>
<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>
<div style="direction:ltr" id="m_-2672942498905832389divRpF818364"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Duncan Thomas [<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>]<br>
<b>Sent:</b> Tuesday, January 17, 2017 6:04 AM<span class=""><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
</span><span class=""><b>Subject:</b> Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?<br>
</span></font><br>
</div>
<div></div>
<div>
<div dir="ltr"><br><div><div class="h5">
<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="m_-2672942498905832389gmail_signature">
<div dir="ltr">
<div>-- <br>
Duncan Thomas</div>
</div>
</div>
</div>
</div></div></div>
</div>
</div>
</div>
</div>

<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>