<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 18, 2017 at 11:23 AM, Brant Knudson <span dir="ltr"><<a href="mailto:blk@acm.org" target="_blank">blk@acm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Jan 18, 2017 at 9:58 AM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:calibri,sans-serif"><div><div class="m_-7607987197061784269gmail-h5">
<span id="m_-7607987197061784269gmail-m_1882228533525021365OLK_SRC_BODY_SECTION">
<blockquote id="m_-7607987197061784269gmail-m_1882228533525021365MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Jan 16, 2017 at 7:35 AM, Ian Cordasco <span dir="ltr">
<<a href="mailto:sigmavirus24@gmail.com" target="_blank">sigmavirus24@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi everyone,<br>
<br>
I've seen a few nascent projects wanting to implement their own secret<br>
storage to either replace Barbican or avoid adding a dependency on it.<br>
When I've pressed the developers on this point, the only answer I've<br>
received is to make the operator's lives simpler.<br>
<br>
</blockquote>
<div><br>
</div>
<div>This is my opinion, but I'd like to see Keystone use Barbican for storing credentials. It hasn't happened yet because nobody's had the time or inclination (what we have works). If this happened, we could deprecate the current way of storing credentials
 and require Barbican in a couple of releases. Then Barbican would be a required service. The Barbican team might find this to be the easiest route towards convincing other projects to also use Barbican.</div>
<div><br>
</div>
<div>- Brant</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
</div></div><div>Can you provides some details on how you'd see this work?</div>
<div>Since Barbican typically uses Keystone to authenticate users before determining which secrets they have access to, this leads to a circular logic.</div>
<div><br>
</div>
<div>Barbican's main purpose is a secret manager.  It supports a variety of RBAC and ACL access control methods to determine if a request to read/write/delete a secret should be allowed or not.  For secret storage, Barbican itself needs a secure backend for
 storage.  There is a customizable plugin interface to access secure storage.  The current implementations can support a database with encryption, an HSM via KMIP, and Dogtag.</div>
<div><br></div></div></blockquote><div><br></div></div></div><div>I haven't thought about it much so don't have details figured out. Keystone stores many types of secrets for users, and maybe you're thinking about the user password being tricky. I'm thinking about the users' EC2 credentials (for example). I don't think this would be difficult and would involve creating a credentials backend for keystone that supports barbican. Maybe have a 'keystone' project for credentials keystone is storing? If you're familiar with the Barbican interface, compare with keystone's credential interface[0].</div><div><br></div><div>[0] <a href="http://git.openstack.org/cgit/openstack/keystone/tree/keystone/credential/backends/base.py#n26" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/keystone/tree/<wbr>keystone/credential/backends/<wbr>base.py#n26</a></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Brant<br><br></div></font></span></div>
</div></div>
</blockquote></div><br></div><div class="gmail_extra">The user passwords and the MFA tokens would be particularly difficult as they are to be used for authentication purposes. Anything tied to the main AuthN path would require something akin to a "service wide" secret store that could be accessed/controlled by keystone itself and not "on behalf of user" where the user still owns the data stored in barbican.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I can noodle over this a bit more and see if I can come up with a mechanism that (without too much pain) utilizes barbican for the AuthN paths in the current architecture.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think it is doable, but I hesitate to make Keystone's AuthN path rely on any external service so we don't run into a circular dependency of services causing headaches for users. Keystone has provided a fairly stable base for other projects including Barbican to be built on.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Now... If the underlying tech behind Barbican could be pushed into keystone as the credential driver (and possibly store for passwords?) without needing to lean on Barbican's Server APIs (restful), I think that is quite viable and could be of value since we could offload the credentials to a more secure store without needing a "restful service" that uses keystone as an AuthN/AuthZ source to determine who has access to what secret.</div><div class="gmail_extra"><br></div><div class="gmail_extra">--Morgan</div></div>