Open Stack

Hello Paul and Caitlin!

I do think a Swift like storage backend is good for key management, it really is a dictionary, nothing fancy, with access controls, replication, horizontal scaling etc. The containers could be "cinder", "swift", "ceilometer", "logs" whatever, to partition the keys and regulate their access.
This is what I proposed in the original blueprint. I am glad Paul you independently think the same.

But I was thinking of a separate instance of a swift storage cluster to avoid the issue
of the key and the object ending up  on the same device (which Caitlin also pointed out in her response .. "how to steer them away from each other"). But coming to your point Paul of a swift based storage being complex, this would make it even more complex. The difference here is that
the storage for keys would be significantly less than regular swift object storage demands. Key strings and their ids would both be random.

Further, to protect the key-strings I was thinking of encrypting the key-strings with the public-key of their "owner" aka service-end-point, that is, Swift/Cinder/Ceilometer etc. This can get expensive.  But with keystone we have PKI and each service end-point has its own public-private key-pairs.

Another idea is once the key has been retrieved from the key manager, it can be saved at the service end-point in a lockbox. The lockbox key would be provided to the service host machine once it has established that it is trust-worthy, using the Trusted-Platform-Module (TPM). Currently OpenStack has support for establishing if compute node hosts are trust worthy. We can extend this to the other hosts. The encryption keys are then distributed to these end-points.

Were we to roll out this feature in phases, phase-1 could use the public-key for encryption, and thus be accessible to only the designated end-point consumer.

Regards
Malini


From: Caitlin Bestler [mailto:caitlin.bestler at nexenta.com]
Sent: Tuesday, February 26, 2013 9:43 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Volume Encryption

On 2/26/2013 9:00 AM, Paul Sarin-Pollet wrote:
Hi Malini,

Do you think that swift could be a good storage backend for a key manager instead of a database ?

It could provide the replication principles and a control over key and key owner.
A (big) negative point could be performances... and complexity.

There are three separate issues here:

* How the keys are physically stored and indexed.
* How the stored keys are secured.
* How to steer storage away from the same device.

A database is not necessarily better at providing an id-->value mapping than an object storage system.
As long as the Key ID is suitable for an Object Name (or a file name for that matter) indexing from an
Object Storage (or file) system should perform well. I cannot think of any scenarios where more general
queries that a database might support would make sense. Every retrieval is for a single key.

If the keys were all placed in a single container, the key needed to decrypt the specific objects could be
an attribute of the Container itself. Special logic would be required to handle this Container metadata,
an important design goal is for this data *not* to be available if someone steals an entire server.

The bigger issue is how to ensure that Swift objects are not stored on the same physical devices that
Cinder is trying to encrypt.  Storing the keys in Swift Objects would make it difficult to use the same
mechanism to support both Swift and Cinder encryption.

My proposal for per-storage-server lockboxes was presuming that they would be stored in a local
file system, most typically a *small* file system such as the persistent storage in a TPM. However,
the internal sturcture of a specific lockbox would actually be up to the storage server vendor.

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