Why not use Barbican? It stores credentials after encrypting them. > -----Original Message----- > From: Jay Pipes [mailto:[email protected]] > Sent: Tuesday, March 25, 2014 9:50 AM > To: [email protected] > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
