Open Stack

I attached a diagram for KeyManager and the Key class hierarchy that I am 
envisioning. I think we are pretty similar on this.

> Volume = NateV
>
> Compute-node-host-A    Compute-node-host-B Compute-node-host-C
>
> Your VM should be technically able to run on the above A, B, or C and attach
> volume NateV.
>
> If master encryption key lives only on compute-node-host-A, then you can
> decrypt the volume only on A.
>
> Alternately if VM runs on compute-node-host-B, need to retrieve the master
> from compute-node-host-A or elsewhere.
>
> After retrieving master, then retrieve the volume specific key NateV-k.

I think what is missing for me is how compute-node-host-B knows where to find 
the master key and how does the master key get transferred from A to B.  Could
you please explain this to me?

For instance compute-node-host-B receives request to mount encrypted volume. It
can retrieve the key from the Key Manager, but at that point it would not know 
how to unwrap the encrypted key.  How would it know to retrieve the key from 
compute-node-host-A? What service must be running on compute-node-host-A to
allow compute-node-host-B to retrieve the key? 

I think we can support the master key concept, but I'm wondering if that should
come in a later phase. I think we could have a KeyManager that accepts generic
Key objects (i.e. plain old key objects and encrypted key objects) and support
both use cases. At first we could have simple keys that are not encrypted with 
master key, and then in a later phase implement master key concept. Thoughts?

-Nate
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ops-kmip.png
Type: image/png
Size: 16499 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130311/341d9a90/attachment.png>