Open Stack

Greetings Simo, Jay, Bryan, Jarret, Dolph, Phil, Nachi, Jamie, Thierry, Arvind and others!



1)      The key manager, barbican, under development supports the blueprint we developed and discussed on this mailing list.

https://wiki.openstack.org/wiki/KeyManager#Key_Manager

2)      Its full featured version is to hold all things "key" related, including public keys and certificates, their renewal and supporting necessary KMIP interfaces.

3)      Only authenticated users/services can access the keys in barbican, barbican itself uses keystone for authentication and authorization like other OpenStack services.

4)      First use case to support is  volume encryption (John Hopkins Applied Physics Lab team)

https://review.openstack.org/30976

5)      Rackspace (Jarret and his team) and Intel have been working hard to meet Havana release milestones.



At the Portland summit we did discuss whether to keep the key management functionality as a separate entity or as a part of keystone.

Participants included Adam Young, Dolph, and several other keystone cores and the Rackspace and Intel folks.

    1) pro - if part of keystone, less of an incubation hurdle.

    2) cons - keystone is already feature rich and this is a separate piece of functionality. Should we want to later pull it out and float as a separate service a lot of work. (The need for a key manager has been felt as more of us seek to provide greater security for user data at rest (volumes, objects) )

    3) Key manager would be a pluggable module for folks who might want an HSM.

    4) We did mention at the summit that storing nova ssl keys to access instances could be shifted to the key manager given a broader scope as a

         repository of all things used to encrypt/decrypt data.

    5) Saving the users', OpenStack service endpoints', and instance pubic keys and/or certificate intersects with Keystone's identity credential storage.

         All things identity related are the prerogative of keystone.

         This is where Jarret's comment fits in about a pointer to the certificate or public key could be saved in keystone with the public key, certificate, even private key inside key manager. To meet compliance needs more audit logging will be present in the key manager. Certainly, wherever keys are stored more audit logging is feasible. This is just a logical divide of whether to build in the functionality.

    6) Today keystone provides a catalog of service endpoints (including the key manager), it is logical to extend this to include access to their certificates.  This would then serve as central point to determine how to securely communicate with the endpoint - assuming neither keystone nor barbican are compromised.











-----Original Message-----
From: Simo Sorce [mailto:simo at redhat.com]
Sent: Tuesday, July 02, 2013 10:43 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Move keypair management out of Nova and into Keystone?



On Tue, 2013-07-02 at 16:55 +0000, Tiwari, Arvind wrote:

> Hi Simo,

>

> I am lost.

>

> Does Barbican is product came out of https://wiki.openstack.org/wiki/KeyManager BP?



Yes Barbican is an implementation of this Blueprint afaik.



> If yes, then why it is deviating from the BP which says Key Manager will be separate service but not a part of Keystone.



Sorry I don't follow, Barbican is separated from Keystone.



> If no, then why we are thinking about new Key manager (which seems to me a subset of above BP)?



New ?



Simo.



--

Simo Sorce * Red Hat, Inc * New York





_______________________________________________

OpenStack-dev mailing list

OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130702/24dbda27/attachment.html>