Jump to: navigation, search


  • Launchpad Entry: Grizzly
  • Created: 29 Nov 2012
  • Updated: 5 Feb 2013
  • Contributors: Bruce Benjamin, Joel Coffman, Laura Glendenning, Nate Reller


OpenStack currently provides no support to encrypt block storage automatically. 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. Another issue is that the physical storage medium could be stolen, remounted, and accessed from a different machine. This blueprint addresses both of these vulnerabilities.

The aim of this blueprint is to provide encryption of the VM's data before it is written to disk. This will allow the privacy of data to be maintained while residing on the storage device. The idea is similar to how self-encrypting drives work. This new feature presents a normal block storage device to the VM but will encrypt the bytes in the virtualization host before writing them to the disk. Note that the necessary design changes are only made in the virtualization host and the key management entity. The block server operates exactly as it does when reading and writing unencrypted blocks. No modifications to the storage device are needed.

Existing tools allow a user to encrypt data inside the VM, but these solutions require manual configuration. Transparently encrypting the data removes the potential risks posed by relying on end-users' manual configuration of the encryption. Cinder volumes currently provides little security, and iSCSI [1] does not inherently provide data-in-transit protection, although external networking security can be added. To address these issues, the encryption provided by this new feature will occur before the iSCSI commands are invoked. The data that goes over the wire to the remote Cinder server is encrypted, and it stays encrypted on the disk.

System Architecture

The diagram below illustrates the system architecture for the block encryption capability. The process for setting up the encryption begins when a user selects an encrypted volume on the dashboard. The next step of the process is a call to Nova's attach_volume command. Nova will map the device as a block device in the virtualization host. This mapping is the same as in the previous OpenStack release.

After the volume is mounted in the virtualization host, Nova will setup the encryption using what we call a Volume Encryptor. The Volume Encryptor is responsible for setting up the encryption for a block device. The reference implementation will be a Dm-Crypt Volume Encryptor, but an abstraction layer allows other choices.

The Volume Encryptor will be invoked to encrypt the block device, and to do this it must have the appropriate key to encrypt the drive. Volume Encryptor gets this by a call to a Key Manager, which is responsible for retrieving appropriate keys. Our eventual goal will be to use a key manager server that implements the OASIS Key Management Interoperability Protocol (KMIP) [2], which defines an industry-wide standard for key management. However, our initial reference implementation uses the Nova database to store the keys.

The Key Manager will return the key to the Volume Encryptor that will then set up the block device for encryption. When dm-crypt [3] is used as the Volume 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 Volume Encryptor will then return the device name to Nova, and Nova will use that device to map into the VM. This last step is the same as in previous releases.

Block Encryption Blueprint v0.82.jpg

An extension of this architecture is planned which addresses another storage target. It will encrypt the disk image called “ephemeral storage,” which contains the operating system and other additional local storage for the VM.

System Design

The Nova architecture only requires a slight modification to provide support for the block encryption feature. The new main interface will be VolumeEncryptor, which is responsible for encrypting block devices. Nova has been modified to directly call this interface. This feature is an option in Nova, so if encryption is not desired, then Nova will simply operate normally. The UML class diagram shows this new interface.

VolumeEncryptor interacts with a KeyManager, which returns keys to VolumeEncryptor.

KeyManager is an interface that allows different types of key managers to be used. The initial interface only defines a method for retrieving keys (get_key), but future revisions will contain more methods for creating, updating, and deleting keys (via KMIPKeyManager, or equiv.). Since this present version doesn’t include a method for creating keys, if KeyManager doesn’t have a key available when this method is called, the current implementation of DBKeyManager will create a random key. This feature is provided for ease of testing, and will not likely remain in the production implementation.

NovaAttach 0.82.jpg

There are some additional unknowns about how the encrypted device will interact with other OpenStack features. For example, exporting/snapshotting volumes and live migration will need to be investigated.

The configuration file key manager in this design is included only as a reference implementation and should only be used for testing purposes. Similarly, the database key manager should not be used in a production environment. A planned feature for the future is to expand the pull-down menu on Horizon to support several encryption mode choices that can be used for volume encryption.


This first release, aimed at Grizzly, is essentially a proof of concept of the encryption capabilities. It has a simple key management capability and is intended for testing the proof-of-concept implementation. This initial version will rely on OpenStack’s existing authentication mechanisms, API calls, and database access, which may limit the security.

A later version is planned that will be based on some basic key management capabilities that will be compatible with the Key Management Interoperability Protocol (KMIP). The plan is to offload the complexity of implementing key management by using a KMIP server. This will talk with the virtualization host to provide a secure link that will deliver the proper keys when needed. The KMIP server would also need to rely on Keystone to provide the authorization credentials, validating that the correct user is accessing the block storage device, and validating that the correct key is being accessed. When PKI is fully implemented in Keystone, this will enhance the security of this key management capability.


Note that most changes supporting this specification are in the libvirt driver of Nova. If a different virtualization driver is being used, the capabilities in this specification will not work. Note that modifying other drivers might be relatively easy to do to allow this capability to be used. In the libvirt driver, only two additional lines of code in the attach statement and one additional line of code in the detach statement were modified.


[1]http://www.ietf.org/rfc/rfc3720.txt (Internet Small Computer Systems Interface - iSCSI)

[2]https://www.oasis-open.org/committees/kmip/ an specifications http://docs.oasis-open.org/kmip/spec/v1.0/cs01/kmip-spec-1.0-cs-01.pdf


[4]http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf (NIST SP800-38E)