Jump to: navigation, search

SecureSharedStorage

Revision as of 23:59, 26 June 2013 by James Penick (talk | contribs)

Secure Shared Storage for instances

Shared storage between hypervisors is excellent for migrations and resilient clouds. However we always operate under the assumption that a given compute node can be compromised. If that happens the attacker gains access to all of the VMs on that hypervisor as well as all disk images on the shared storage device. This could be thousands of VMs. Best practices for security and threat response would dictate that all compromised vms be destroyed and recreated. Thus a single compromised compute node would necessitate the destruction and recreation of all VMs in a cloud.

That would suck.

QEMU supports AES 128 encrypted disk images with the qcow2 disk image format. If all disk images were each encrypted with a unique key, and that key managed by Nova,only instances on the compute node would be compromised.

Changes required:

  1. After selecting a hypervisor, nova-scheduler should generate a 16 character key to include in the message destined for the queue. This key should be stored in the DB.
  2. Nova-compute will store that key and encrypt the disk image of the new VM with it.
  3. Live migrations will need to take this key into account

Risks:

  • Disk IO may be slowed some by encryption. However modern intel CPUs have hardware AES support, so this might not be too bad.
  • If the key is passed across the queue in such a fashion that any compute node can read it, then any attacker would have access to any instance created or migrated after that point. The key should either be encrypted specific to the compute node (implies key architecture) or passed to the compute node outside of the queue.