SecureSharedStorage
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:
- 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.
- When building a new VM nova-compute will request the key for that instance ID and encrypt the disk image with it.
- The destination host in a live migration will also need to take this key into account.
- Nova-API should only serve the key up to either the host on which the VM has been provisioned, or the destination host in a live migration.
Risks:
- Disk IO may be slowed some by encryption. However modern intel CPUs have hardware AES support, so this might not be too bad. (eg, this should be tested)
- 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 in such a way that another host can't easily intercept the message.
