[openstack-dev] Volume Encryption

Caitlin Bestler caitlin.bestler at nexenta.com
Mon Feb 25 16:29:58 UTC 2013


On 2/23/2013 12:36 AM, Bhandaru, Malini K wrote:
>
> Nate -- I vote for (2). Also wonder if you would like to not just make 
> a copy of the volume, but also make a copy of the key and save it, in 
> so doing it gets a new key-id and associate that key-id with the 
> snapshot in its meta data.
>
> An advantage of making a copy of the key is that if one were to delete 
> a volume, one may also delete its associated key without worrying 
> about rendering data inaccessible because of sharing or for fear of 
> loss, never reclaiming key space.
>

Yes, this is the same feature that makes the content secure from being 
stolen. But it is worth highlighting that virtually *all* drives eventually
leave a data center. Not having to erases the data or destroy the drive 
is a major saving, whether the drive leaves the data center legitimately
or not.

> I am reviewing your code .. without getting into where the key-manager 
> resides as a service ..
>
> Would like to propose keys as distinct from the algorithm that uses them.
>
> Keys would have properties such as public/private/symmetric, and 
> length in addition to your format (asn.1)
>

We could also just allow this key encoding to be either stored by 
keystone, or in various lockboxes under direction of keystone.
There should only be one encoding for the key id and the key value, no 
matter how it is transferred.

The key feature I am proposing is that transfers of keys be limited to 
transfers between authorized holders, which keystone
would definitely qualify as, and only when explicitly encrypted with the 
public key of the destination holder.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130225/289c9ddc/attachment.html>


More information about the OpenStack-dev mailing list