Open Stack

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/20130226/ef988ca1/attachment.html>