Open Stack

Why not use Barbican? It stores credentials after encrypting them.

> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
> Sent: Tuesday, March 25, 2014 9:50 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to
> Keystone
> 
> On Tue, 2014-03-25 at 12:23 +0000, Lucas Alvares Gomes wrote:
> > Hi,
> >
> > Right now Ironic is being responsible for storing the credentials for
> > the IPMI and SSH drivers (and potentially other drivers in the
> > future), I wonder if we should delegate this task to Keystone. The
> > Keystone V3 API now has a /credentials endpoint which would allow us
> > to specify arbitrary types (not only ec2 anymore) and use it as a
> > credential store[1].
> >
> > That would avoid further fragmentation of credentials being stored in
> > different places in OpenStack, and make the management of the
> > credentials easier (Think about a situation where many nodes share the
> > same IPMI username/password and we need to update it, if this is
> > stored in Keystone it only needs to be updated there once cause nodes
> > will only hold a reference to it)
> >
> > It also was pointed to me that setting a hard dependency on Keystone
> > V3 might significantly raises the bar for integration with existing
> > clouds*. So perhaps we should make it optional? In the same way we can
> > specify a username/password or key_filename for the ssh driver we
> > could have a reference to a credential in Keystone V3?
> 
> I think the idea of using Keystone for keypair management in Nova is a good
> one. There is already precedent in Nova for doing this kind of thing ... it's
> already been done for images, volumes, and network.
> 
> One problem with the Keystone v3 credentials API, though, is that it does not
> have support for unique names of keypairs per project, as that is how the
> Nova API /keypairs resource endpoint works.
> 
> > What you guys think about the idea? What are the cloud
> > operators/sysadmins view on that?
> 
> As long as the functionality was enabled using the standard driver-based
> setup (as was done for glance, nova, cinder, and neutron integration), I don't
> see any issues for deployers. Of course, you'd need a migration script, but
> that's not a huge deal.
> 
> Best,
> -jay
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev