Open Stack

Malini,

Sorry for the long reply, but I have a lot of thoughts on this. I like the 
proposal overall, but I have some concerns and suggestions. 

*** Master Key and Access for Compute Hosts *** 

My biggest concerns are with regards to the master key and preventing access to 
the compute hosts. In our proposal, encrypt-cinder-volumes, the compute host is 
encrypting the cinder volume data after it leaves the VM and before it is sent 
to the cinder host. Clearly we would like for compute hosts to have access to 
the Key Manager to allow them to encrypt the data. 

My other concern is with the master key idea. The compute hosts will be 
responsible for encrypting and decrypting the data for cinder volumes. If the 
keys for doing this are encrypted by a master key then the master key must be 
shared by all compute hosts that will use the cinder volume. That would require 
copying the master key to multiple platforms and that makes me nervous. This is 
my biggest concern with master keys encrypting other keys. It forces the master 
key to be shared with all entities that will use the key. 

I propose changing the interface to operate on generic Key objects. Then we can 
have classes of Key objects for different types of keys. One Key class may be a 
SymmetricKey class for storing AES keys and the like. Another Key class may be 
an EncryptedSymmetricKey class that stores a symmetric key that is encrypted by 
a master key. This way the interface can support the use cases for master keys 
and plain old symmetric keys. It would also support split keys. I can send a 
UML diagram or two with my thoughts if you like. Let me know. 

*** Authroization Token *** 

I like that your API takes in an authorization token. Do you have more details 
on what that would be? Our prototype right now takes in the context of the 
caller (i.e. the user). I would like to extend that to have the interface take 
in a security context that not only provides an authorization token from the 
user, but it may include other information as well. I am thinking about 
information specific to the platform. For instance, I may want to have the 
compute host provide a signed TPM quote, so the Key Manager can verify that the 
caller is from a particular platform. I would be interested in brainstorming 
more ideas on this.  I'm also not sure what the Keystone group is working on in 
this area. I also think it would be cool to integrate TNC into this, but I'm 
not sure how to do that.

*** Miscellaneous Thoughts *** 

I would like to see the Key Manager as its own service. I think many different 
services have a need for a Key Manager and making it its own service would be 
useful. 

TPM could be used to encrypt all keys on Key Manager platform. Then you could
lock the keys down unless the platform is in a specific state.

I don't think we should limit key scope. I imagine there will be many different
use cases for keys, and the key scope will be different for each one. It may
also be different per deployment.

This topic is of interest to the OpenStack Security Group (OSSG). You may want
to join the meetings on Thursdays.

Link to encrypt-cinder-volumes blueprint:
https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes

-Nate

> When you get a chance we checkout https://wiki.openstack.org/wiki/KeyManager > 
> I hope I have captured ideas and addressed concerns we have discussed on this mailing list.