Open Stack

Oleg, just the thought I had earlier in the day!

Suggested a session for key manager  at http://summit.openstack.org/.

To your list of blueprints, I added another one I found.



Nate, if your volume meta data included a key-id, it could pull the key-string from the key-manager  (as yet a fuzzy) entity.



The keystone token could also capture preferences for encryption algorithm (for Cinder/Glance/Swift) and these default to

strong versions like Caitlin suggests.



Regards,

Malini




From: Oleg Gelbukh [mailto:ogelbukh at mirantis.com]
Sent: Wednesday, February 13, 2013 12:52 PM
To: OpenStack Development Mailing List
Cc: Nate Reller
Subject: Re: [openstack-dev] Volume Encryption

Hello,

I believe that this discussion need actually be split into two parts: encryption algorithms and specific tools, and key management.

The implementation of actual encryption are specific for every project. We identified a number of blueprints which utilize encryption in one way or another:
https://blueprints.launchpad.net/keystone/+spec/access-key-authentication
https://blueprints.launchpad.net/nova/+spec/encrypt-ephemeral-volumes
https://blueprints.launchpad.net/swift/+spec/encrypted-objects
https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes

All these blueprints involve some key management, and it seems reasonable to implement it as a shared component. Where does it belongs is a discussion topic. Our understanding is that Keystone API could be extended with new resource keys/ to proxy keys operations with pluggable back-end drivers (much like Identity or Catalog).

Please, tell me if this sounds reasonable to you. Do you think this kind of discussion should take place at Summit?

--
Best regards,
Oleg

On Wed, Feb 13, 2013 at 12:32 PM, Caitlin Bestler <caitlin.bestler at nexenta.com<mailto:caitlin.bestler at nexenta.com>> wrote:
On 2/13/2013 9:46 AM, Nate Reller wrote:
Our intent was not to limit which encryption algorithms to use or to propose a minimum standard.  We needed to pick a default implementation to use for the Grizzly release.  We did not have enough time to make the algorithm configurable, so we needed to pick a default for the release.

In the future we would like to support many different algorithms and key sizes.  We are imagining the user inputting which algorithm and key size they would like to use via the dashboard.  The administrators of the cloud would be responsible for configuring the dashboard and other components to report which encryption algorithms are available.  This will depend upon their cloud, and the encryption algorithm and key sizes will likely be dictated by the features supported by the compute nodes.

-Nate

Something like this should always be pluggable, even if it requires editing configuration files.
Dashboard selection would also be nice, but would presume providing some text about what
the options were.

In any case, the general rule of thumb I have followed on security issues is to allow the user
a great deal of flexibility, but to default high. Users who do not know how to configure their
security settings probably need them to be set high.

_______________________________________________
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/20130213/7dcd9609/attachment.html>