Excerpts from Morgan Fainberg's message of 2017-01-18 15:33:00 -0800: > On Wed, Jan 18, 2017 at 11:23 AM, Brant Knudson <b...@acm.org> wrote: > > > > > > > On Wed, Jan 18, 2017 at 9:58 AM, Dave McCowan (dmccowan) < > > dmcco...@cisco.com> wrote: > > > >> > >> On Mon, Jan 16, 2017 at 7:35 AM, Ian Cordasco <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. > >> > >> > > 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]. > > > > [0] http://git.openstack.org/cgit/openstack/keystone/tree/ > > keystone/credential/backends/base.py#n26 > > > > - Brant > > > > > 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. > > 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. > > 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. > > 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.
Things like Barbican are there for the times where it's worth it to try and minimize exposure for something _ever_ leaking, so you can't do something like record all encrypted traffic and then compromise a key later, decrypt the traffic, and gain access to still-secret data. I'm not sure passwords would fall into that category. You'd be adding quite a bit of overhead for something that can be mitigated simply by rotating accounts and/or passwords. __________________________________________________________________________ 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