Open Stack

Nate:

Supporting clone operations for encrypted volumes is logical. It is like any other volume but more secure.
Speed is of value.

There are a few layers of protection:

1)      Access control to the volumes via KeyStone.

So only someone with access to the volume would be able to clone it. Typically snapshot is for archival purposes

To return to a past working state.

2)      The key itself is in the key-manager, and only the key-id is associated with the volume as meta-data.

So the user would need to authenticate themselves with the system to unlock the volume.

3)      I am guessing your use case is handing off a clone to a third party via a url or other mechanism.

This is where a level of indirection could be provided that avoids full volume decrypt and re-encrypt.
               A primary and secondary key. The primary is used to encrypt the volume.
               The secondary key is used to encrypt the primary and the meta data will refer to both.
               It would be like distributing copies of the key.
               Access logs could capture which of the duplicate keys was used to unlock the volume.

                <encrypted-volume>, meta-data: {key-id: 1234, encrypted-primary-key: jsdphq89wty[14kjsdfj}

                    Or

               <encrypted-volume>, meta-data: {primary-key-id: pppp, secondary-key-id: ssss}

               Key-string(pppp) needs to be decrypted using key-string(ssss).

               Decrypt(key-string(pppp), key-string(ssss)) to get the encryption key of the volume.

               On creating a clone.

               <encrypted-volume>, meta-data: {primary-key-id: qqqq, secondary-key-id: rrrr}

               Decrypt(key-string(pppp), key-string(ssss))  == Decrypt(key-string(qqqq), key-string(rrrr))


Regards
Malini


From: Nate Reller [mailto:rellerreller at yahoo.com]
Sent: Thursday, February 14, 2013 8:24 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Volume Encryption

Malini, I was happy to learn about a key manager discussion at the summit.  Do you know what track this would be under?  I can't decide if this should be in Keystone or maybe a whole new service.  I like the idea of a whole new service myself because I think it helps to have the separation and prevent bloating of functionality for components.  On the other hand, I probably don't want a dozen services.

I like the idea of the key-id.  I think we may end up using that idea.  This will help us to support snapshot operations.

One item we have yet to tackle is cloning.  I think there are a few options for this.

1) Don't support clone operations for encrypted volumes.  This is easy to implement and prevents key reuse, but it limits functionality.
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?
3) Support clone with different key.  You could do this by decrypting the bytes from the original volume and encrypting them with a new key.  If we are going to support cloning then I think I like this approach the best.  The drawback on this is time.

There are similar issues for snapshots, but I am not as opposed to option 2 for snapshots.  Any thoughts on this?

-Nate

________________________________
From: "Bhandaru, Malini K" <malini.k.bhandaru at intel.com<mailto:malini.k.bhandaru at intel.com>>
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Sent: Wednesday, February 13, 2013 4:32 PM
Subject: RE: [openstack-dev] Volume Encryption

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130214/568f882d/attachment.html>