VolumeEncryption
- Launchpad Entry: Grizzly
- Created: 29 Nov 2012
- Contributors: Bruce Benjamin, Joel Coffman, Laura Glendenning, Nate Reller
Introduction
The volumes for a virtual machine (VM) are currently not being encrypted. This makes the platforms hosting volumes for VMs high value targets because an attacker can break into a volume-hosting platform and read the data for many different VMs. This type of data breach could be addressed with encryption.
The aim of this blueprint is to provide encryption of the VM's data before it is written to disk. The idea is similar to how self-encrypting drives work. Our goal is to present the VM a normal block storage device, but we will encrypt the bytes in the virtualization host before writing them to the disk.
Existing tools such as dm-crypt [1] and eCryptFS [2] enable data encryption but require manual configuration by cloud users. Transparently encrypting the data removes the potential risks posed by relying on end-users' manual configuration of the encryption.
Cinder volumes currently provide little security – iSCSI in particular proffers no protection when data is transmitted. (iSCSI stands for Internet Small Computer System Interface and is the protocol used by Cinder to read and write data.) To address this, we plan to do the encryption before the iSCSI commands are invoked. This has the additional benefit of essentially encrypting the data that goes over the wire to the remote Cinder server.
System Architecture
The diagram below illustrates the system architecture for our proposed solution. The process for setting up the encryption begins with a call to Nova's attach volume command, and Nova will continue to map the device as a block device in the virtualization host. This is the same as in the previous release.
After the volume is mounted in the virtualization host, Nova will begin work to setup the encryption using a "Block Device Encryptor" (we can call this whatever). A Block Device Encryptor is responsible for setting up the encryption for a block device. The reference implementation will be a Dm-Crypt Block Device Encryptor.
The Block Device Encryptor will be invoked to encrypt the block device. The Block Device Encryptor must then find the appropriate key to encrypt the drive. The Block Device Encryptor does this by making a call to a Key Manager. The Key Manager is responsible for retrieving appropriate keys. Our eventual goal will be to use the OASIS Key Management Interoperability Protocol (KMIP) [3], which defines an industry-wide standard for key management. However, our initial reference implementation may use a configuration file or something simple.
The Key Manager will return the key to the Block Device Encryptor that will then setup the block device for encryption. In the case of the Dm-Crypt Block Device Encryptor this will entail setting up a loop back device on the mounted volume and setting up dm-crypt using the encryption key for the loop back device.
The Block Device Encryptor will then return the device name to Nova, and Nova will use that device to map into the VM. This is the same as in previous releases.
For future work, a similar architecture will be used to encrypt the disk image that contains the operating system for the VM, also known as "ephemeral storage". This architecture will also be used to support encrypting local volumes done through the Nova API extension nova2ools ![4]. This specification will be updated to account for any changes needed to support these features.
System Design
The Nova architecture will be enhanced slightly to account for block encryption. The new main interface will BlockDeviceEncryptor. BlockDeviceEncryptor is responsible for encrypting block devices. Nova will need to be modified to directly call this interface. We would like to make this feature an optional plugin, so if encryption is not desired then Nova will simply operate normally. The UML class diagram shows the new interface.
The BlockDeviceEncryptor will likely interact with a KeyManager. A KeyManager is responsible for returning keys to the BlockDeviceEncryptor.
There are still some unknowns with the design. It is not yet known what information should be provided to the KeyManager to be able to find the correct key. This information must be passed to the BlockDeviceEncryptor that will then use it to call the KeyManager. The interfaces will be updated when that information is known.
File:VolumeEncryption$NovaAttach.gif
There are some additional unknowns about how the encrypted device will interact with other OpenStack features. For example, features such as exporting/snapshotting volumes and live migration will need to be investigated.
Schedule
[TODO]
[This section will have a table showing some internal milestones. The last milestone will match the grizzly-3 milestone from OpenStack. The purpose of the section is to show to the community the progress that is being made on the blueprint as it is implemented.]
Testing
[TODO]
[This section will describe our testing strategy. This may include results from OpenStack unit tests and performance test suites. It will also contain instructions on how developers could try out our code for themselves once it is publicly available in a branch.]
References
[1] http://www.saout.de/misc/dm-crypt/
[3] https://www.oasis-open.org/committees/kmip/
[4] http://openstackgd.wordpress.com/2012/03/15/add-support-for-local-volumes-in-openstack/
