Open Stack

On 2/14/2013 8:23 AM, Nate Reller wrote:
> 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
>
> ------------------------------------------------------------------------
>

Great outline, it zeroes in on the most critical issue.

Nexenta favors option 2, which shouldn't be surprising since we 
on-the-fly snapshotting and cloning
is one of the key strengths of ZFS.

When you have to decrypt and re-encrypt a volume the process is no 
longer a "snapshot", but something
that resembled Civil War era photography.

However, I do not see Keystone as being a key repository that is up to 
supporting distributed keys.
Any would-be attacker would immediately target the encryption of 
communicating with keystone
as being a far more vulnerable target than the encryption used on the 
volumes themselves.

I believe what we need is to allow the encryption keys to be stored by 
the storage servers themselves
in secure lock boxes, and the role of OpenStack should be to authorize 
secure transfers between those
lockboxes (which could be encrypted by far more than SSL).


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