Open Stack

> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
> Sent: 02 July 2013 02:04
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] Move keypair management out of Nova and into
> Keystone?
> 
> On 07/01/2013 07:49 PM, Jamie Lennox wrote:
> > On Mon, 2013-07-01 at 14:09 -0700, Nachi Ueno wrote:
> >> Hi folks
> >>
> >> I'm interested in it too.
> >> I'm working on VPN support for Neutron.
> >> Public key authentication is one of feature milestone in the IPsec
> >> implementation.
> >> But I believe key-pair management api and the implementation will be
> >> quite similar in Key for IPsec and Nova.
> >>
> >> so I'm +1 for moving key management for Keystone.
> >>
> >> Best
> >> Nachi
> >
> > I don't know how nova's keypair management works but i assume we are
> > talking about keys for ssh-ing into new virtual machines rather than
> > keys for authentication against nova.
> >
> > Keystone's v3 api has credentials storage (see
> > https://github.com/openstack/identity-api/blob/master/openstack-identity-
> api/src/markdown/identity-api-v3.md ), is this sufficient on behalf of keystone?
> There is some support in the current master of keystoneclient for working with
> these credentials.
> >
> > Otherwise would the upcoming barbican be a more appropriate place?
> >
> > If i've got this wrong and we are using these keys to actually
> > authenticate against nova then if someone can point me to the code
> > i'll see how hard it is to transfer to keystone.
> 
> Actually, no, I think you have it right (though the correct link is
> https://github.com/openstack/identity-api/blob/master/openstack-identity-
> api/v3/src/markdown/identity-api-v3.md)
> 
> I think the main work, though, has to be in removing/replacing the Nova API
> /keypairs stuff with calls to Keystone's v3/credentials API.
> 
> Would the appropriate way to do this be to add an API shim into Nova's API that
> simply calls out to the Keystone v3/credentials API IFF Keystone's v3 API is
> enabled in the deployment? Then, deprecate the old code and when Keystone
> v2 API is sunsetted, then remove the old Nova keypairs API codepaths?
> 
> Best,
> -jay
> 

Yep - following the pattern set by things like the floating IP and SecGroups APIs as these moved to Quantum would defiantly be the way to go.

Beyond just the Nova API shim we'd need to change the logic in the server creation to get the key value from Keystone rather than the Nova DB.
There is a KeypairAPI in compute/api.py but not everything is abstracted to use it at the moment.   If we tidy that up then that would provide the redirection point to Keystone. 
  

It would also be really good if there was a migration tool developed at the same time to migrate existing keys from Nova to Quantum.

Phil

> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev