Open Stack

Hello Caitlin!

I have been pondering your comment .. and some issues pertaining to horizontal scaling for high availability. Please let me know if I am
missing something in your suggestion of storage nodes saving encryption keys.

Say on compute-node-1, we have a VM and a persistent volume encrypted with key k1, user is done, volume detached etc.
Later the VM may land on compute-node-2 and key K1 needs to be accessed.
A single copy of the key would mean danger of key loss. Also search for the key should the VM and volume host be different from the prior run (in this case compute-node-2 instead of compute-node-1).  Even snapshots may reside on different storage media and whether we use the same key-string-id or a copy of the key-string and new id.

If we elect to store the encryption keys on the storage servers themselves in secure lock boxes, we would need to replicate the keys on other peer storage servers to ensure access. Mirroring .. like Swift replicas.

This then becomes a swift like storage mechanism with the keys encrypted using the storage server's master key.

I can see a single master key being distributed to the members of the storage cluster, so that they can decrypt a key once they retrieve it from the
Key manager (thinking of it as a single entity even if the data is replicated in multiple places).

With the service endpoint, aka storage node (Cinder/Glance/Swift), being responsible for decrypting the key-string, which happens locally, the communication between key-manager and service-endpoint becomes a less valuable target, the data flying by less vulnerable.

TPM could be used to verify if a storage-endpoint is legitimate (identity and platform integrity) before it could access the master key.
We could have separate master keys for Cinder/Glance/Swift.

To get the protection of a double-key like a bank safe deposit locker, the actual encryption key could be a combination of the domain/account/user specific key and the per entity key. That key too would reside in key-manager. Either through delegation the service endpoint could access it (here I am having trouble with which key to use to encrypt it .. different services would be using the key). While stored it could be encrypted with the key-manager's master key or keystone's master key, but then it would have be passed along to the service after decryption (vulnerable while in transit).

Caching of keys, to reduce network traffic and latency possible, with lifetime equal to token lifetime and usual cache space reclamation policies.

Regards
Malini

From: Caitlin Bestler [mailto:caitlin.bestler at nexenta.com]
Sent: Thursday, February 14, 2013 9:38 AM
To: Nate Reller; OpenStack Development Mailing List
Subject: Re: [openstack-dev] Volume Encryption

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/20130222/d7419054/attachment.html>