<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 18, 2017 at 5:18 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Morgan Fainberg's message of 2017-01-18 15:33:00 -0800:<br>
<div><div class="h5">> On Wed, Jan 18, 2017 at 11:23 AM, Brant Knudson <<a href="mailto:blk@acm.org">blk@acm.org</a>> wrote:<br>
><br>
> ><br>
> ><br>
> > On Wed, Jan 18, 2017 at 9:58 AM, Dave McCowan (dmccowan) <<br>
> > <a href="mailto:dmccowan@cisco.com">dmccowan@cisco.com</a>> wrote:<br>
> ><br>
> >><br>
> >> On Mon, Jan 16, 2017 at 7:35 AM, Ian Cordasco <<a href="mailto:sigmavirus24@gmail.com">sigmavirus24@gmail.com</a>><br>
> >> wrote:<br>
> >><br>
> >>> 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>
> >>><br>
> >> This is my opinion, but I'd like to see Keystone use Barbican for storing<br>
> >> credentials. It hasn't happened yet because nobody's had the time or<br>
> >> inclination (what we have works). If this happened, we could deprecate the<br>
> >> current way of storing credentials and require Barbican in a couple of<br>
> >> releases. Then Barbican would be a required service. The Barbican team<br>
> >> might find this to be the easiest route towards convincing other projects<br>
> >> to also use Barbican.<br>
> >><br>
> >> - Brant<br>
> >><br>
> >><br>
> >> Can you provides some details on how you'd see this work?<br>
> >> Since Barbican typically uses Keystone to authenticate users before<br>
> >> determining which secrets they have access to, this leads to a circular<br>
> >> logic.<br>
> >><br>
> >> Barbican's main purpose is a secret manager.  It supports a variety of<br>
> >> RBAC and ACL access control methods to determine if a request to<br>
> >> read/write/delete a secret should be allowed or not.  For secret storage,<br>
> >> Barbican itself needs a secure backend for storage.  There is a<br>
> >> customizable plugin interface to access secure storage.  The current<br>
> >> implementations can support a database with encryption, an HSM via KMIP,<br>
> >> and Dogtag.<br>
> >><br>
> >><br>
> > I haven't thought about it much so don't have details figured out.<br>
> > Keystone stores many types of secrets for users, and maybe you're thinking<br>
> > about the user password being tricky. I'm thinking about the users' EC2<br>
> > credentials (for example). I don't think this would be difficult and would<br>
> > involve creating a credentials backend for keystone that supports barbican.<br>
> > Maybe have a 'keystone' project for credentials keystone is storing? If<br>
> > you're familiar with the Barbican interface, compare with keystone's<br>
> > credential interface[0].<br>
> ><br>
> > [0] <a href="http://git.openstack.org/cgit/openstack/keystone/tree/" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/keystone/tree/</a><br>
> > keystone/credential/backends/<wbr>base.py#n26<br>
> ><br>
> > - Brant<br>
> ><br>
> ><br>
> The user passwords and the MFA tokens would be particularly difficult as<br>
> they are to be used for authentication purposes. Anything tied to the main<br>
> AuthN path would require something akin to a "service wide" secret store<br>
> that could be accessed/controlled by keystone itself and not "on behalf of<br>
> user" where the user still owns the data stored in barbican.<br>
><br>
> I can noodle over this a bit more and see if I can come up with a mechanism<br>
> that (without too much pain) utilizes barbican for the AuthN paths in the<br>
> current architecture.<br>
><br>
> I think it is doable, but I hesitate to make Keystone's AuthN path rely on<br>
> any external service so we don't run into a circular dependency of services<br>
> causing headaches for users. Keystone has provided a fairly stable base for<br>
> other projects including Barbican to be built on.<br>
><br>
> Now... If the underlying tech behind Barbican could be pushed into keystone<br>
> as the credential driver (and possibly store for passwords?) without<br>
> needing to lean on Barbican's Server APIs (restful), I think that is quite<br>
> viable and could be of value since we could offload the credentials to a<br>
> more secure store without needing a "restful service" that uses keystone as<br>
> an AuthN/AuthZ source to determine who has access to what secret.<br>
<br>
</div></div>Things like Barbican are there for the times where it's worth it to<br>
try and minimize exposure for something _ever_ leaking, so you can't do<br>
something like record all encrypted traffic and then compromise a key<br>
later, decrypt the traffic, and gain access to still-secret data.<br>
<br>
I'm not sure passwords would fall into that category. You'd be adding<br>
quite a bit of overhead for something that can be mitigated simply by<br>
rotating accounts and/or passwords.</blockquote><div><br></div><div>I totally agree. Most everything in Keystone falls into this category. We could use the same tech Barbican uses to be smarter about storing the data, but I don't think we can use the Rest APIa for the reasons you outlined.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
______________________________<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>
</div></div></blockquote></div><br></div></div>