Open Stack

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 <blk at acm.org> wrote:
> 
> >
> >
> > On Wed, Jan 18, 2017 at 9:58 AM, Dave McCowan (dmccowan) <
> > dmccowan at cisco.com> wrote:
> >
> >>
> >> On Mon, Jan 16, 2017 at 7:35 AM, Ian Cordasco <sigmavirus24 at 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.