On Mon, Jan 16, 2017 at 7:35 AM, Ian Cordasco 
<sigmaviru...@gmail.com<mailto:sigmaviru...@gmail.com>> wrote:
Hi everyone,

I've seen a few nascent projects wanting to implement their own secret
storage to either replace Barbican or avoid adding a dependency on it.
When I've pressed the developers on this point, the only answer I've
received is to make the operator's lives simpler.


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.

- Brant

Can you provides some details on how you'd see this work?
Since Barbican typically uses Keystone to authenticate users before determining 
which secrets they have access to, this leads to a circular logic.

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.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to