[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