[openstack-dev] key manager proposal

Bhandaru, Malini K malini.k.bhandaru at intel.com
Thu Mar 21 06:59:30 UTC 2013


Thank you Caitlin for the compliment and the use cases below.
Apologies for the delayed reply, was out of town and did not want to mess up in a hurry.
My thoughts inline

From: Caitlin Bestler [mailto:Caitlin.Bestler at nexenta.com]
Sent: Thursday, March 07, 2013 10:37 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] key manager proposal


Excellent proposal.

One item not covered yet, is the possibility of running a key scope that is a collection
of encrypted items: for example the set of volumes and snapshots that are derived from
one master.

For shallow copies, such as for volume snapshots, we could preserve the same key, and same key-id.
This does not need additional support because with volumes, Cinder on volume creation first creates a key and
Puts it in the key-manager. Then it delegates the key to the Compute node for its retrieval.

We could support "clone-key" in case we want to make a copy of a key but save it under a fresh key-id.

So a snapshot could use the same key-string and key-id or
                                                    Same key-string and key-id-2.
In a sense a "slightly deeper copy", but no decrypt-re-crypt of the volume data.

The Swift replicas should they use volume encryption could be provided the same key-id or cloned-key-id.
The encryption key-id would be associated with the respective volume-ids.

A snapshot that used the same key-id as the volume it was a snapshot of would not
require any copying of content to take the snapshot. Similarly if a new volume was
cloned from the snapshot (especially if the volume storage system supported thin
encoding).

Swift partitions could also use the same key-id on every Swift Object Server,
allowing rsync replication without needing to re-key/re-encrypt/whatever.

Swift uses rsync, which is a file level protocol, (http://en.wikipedia.org/wiki/Rsync  rsync is a utility software<http://en.wikipedia.org/wiki/Utility_software> and network protocol<http://en.wikipedia.org/wiki/Network_protocol> for Unix-like<http://en.wikipedia.org/wiki/Unix-like> systems (with ports<http://en.wikipedia.org/wiki/Porting> to Windows<http://en.wikipedia.org/wiki/Windows>) that synchronizes files<http://en.wikipedia.org/wiki/File_synchronization> and directories<http://en.wikipedia.org/wiki/Directory_%28file_systems%29> from one location to another while minimizing data<http://en.wikipedia.org/wiki/Data> transfer by using delta encoding<http://en.wikipedia.org/wiki/Delta_encoding> when appropriate.)
So using the same volume encryption key may not buy anything.
Should Swift one day use a block level protocol then having the same key for volume encryption would be good.
At the file level, the encrypted object would be a bit string which would if unchanged, look exactly the same at each replication site.
However if one of the replicas was out of synch, it would be a full file transfer because any block chaining encryption mechanism, even
With the exact same initialization vector would have a ripple effect beyond the point of change. With a new initialization vector, it would be a full
copy.


The critical idea here is that the scope of a key should be motivated by the need
for efficient replication, snapshotting and cloning.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130321/20d6c149/attachment.html>


More information about the OpenStack-dev mailing list