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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
