Open Stack

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.


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)

I am thinking it would be a good idea to attach with a domain/project/user a preferred encryption preference,
So one would need to traverse up the user to domain to determine the most specific preference for that user while encrypting a volume, and likewise a preference for objects etc.

The algorithm would also be attached as meta data to the volume based on the results of the above discovery process during encryption.

The defaults are the strongest known at the time we deploy.

Further, I am thinking in the UI, should the domain/project/user creator desire to set them, these should be retrieved from openssl or other implementation for object, from dm-crypt for volume etc.

A problem that could arise .. the compute node on which a volume is attached might have an older version of dum-crypt than the node that hosted the horizon user interface .. but I am guessing in the immediate future that may not be an issue. If it becomes one, then we would need to specify a filter instance for the same and that would need to be factored in while determining where to host the volume.

Regards
malini

2) Support clone with same key.  This should be easy to implement as well.  We could use the metadata key-id and set it to the same value for the clone.  The drawback to this is that the key has multiple uses, and it could be used to decrypt many different volumes.  I don't like the idea of that.  If the key is compromised then what do you do?
There are similar issues for snapshots, but I am not as opposed to option 2 for snapshots.  Any thoughts on this?

-Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130223/5f098408/attachment.html>