On Wed, Jan 18, 2017 at 5:18 PM, Clint Byrum <cl...@fewbar.com> wrote:
> 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. 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. __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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