<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2/26/2013 9:00 AM, Paul Sarin-Pollet
wrote:<br>
</div>
<blockquote cite="mid:20130226170031.162550@gmx.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<span style="font-family:Verdana"><span style="font-size:12px"><span
style="font-family: Verdana;"><span style="font-size: 12px;">Hi
Malini,<br>
<br>
Do you think that swift could be a good storage backend
for a key manager instead of a database ?<br>
It could provide the replication principles and a control
over key and key owner.<br>
A (big) negative point could be performances... and
complexity.<br>
</span></span><br>
</span></span></blockquote>
<br>
There are three separate issues here:<br>
<br>
* How the keys are physically stored and indexed.<br>
* How the stored keys are secured.<br>
* How to steer storage away from the same device.<br>
<br>
A database is not necessarily better at providing an id-->value
mapping than an object storage system.<br>
As long as the Key ID is suitable for an Object Name (or a file name
for that matter) indexing from an<br>
Object Storage (or file) system should perform well. I cannot think
of any scenarios where more general<br>
queries that a database might support would make sense. Every
retrieval is for a single key.<br>
<br>
If the keys were all placed in a single container, the key needed to
decrypt the specific objects could be<br>
an attribute of the Container itself. Special logic would be
required to handle this Container metadata,<br>
an important design goal is for this data *not* to be available if
someone steals an entire server.<br>
<br>
The bigger issue is how to ensure that Swift objects are not stored
on the same physical devices that<br>
Cinder is trying to encrypt. Storing the keys in Swift Objects
would make it difficult to use the same<br>
mechanism to support both Swift and Cinder encryption.<br>
<br>
My proposal for per-storage-server lockboxes was presuming that they
would be stored in a local<br>
file system, most typically a *small* file system such as the
persistent storage in a TPM. However,<br>
the internal sturcture of a specific lockbox would actually be up to
the storage server vendor.<br>
<br>
<br>
</body>
</html>