Volume Encryption l CloudStack Feature Deep Dive

Introduction

Everyone would agree that data is the most important thing in the cloud today, and after so many breaches, encrypting data is increasingly popular among cloud service providers. Adding this additional security layer can make it even more difficult for unauthorized users to access your precious data.

In this article, I’d like to introduce a new feature that enables Apache CloudStack to work with encrypted Root and Data Volumes when using KVM hypervisor. This encryption is transparent to the guest OS, greatly simplifying the operator experience, and removing the need to handle encryption keys, maintain key server infrastructure, and rely on network connectivity for guest booting.

Architecture

This feature consists of two parts – the control plane and the storage driver. It depends on the Linux distribution / version, and in all tested versions the XTS-AES 256 cipher was used for encryption, which is the leading industry standard.

API Changes

The following API calls were changed to support Volume Encryption:

API call Changes
createDiskOffering Included ‘encrypt’ Boolean
createServiceOffering Included ‘encryptroot’ Boolean. The ‘root’ suffix is added here in case there is ever any other need to encrypt something related to the guest configuration, like the RAM of a VM. This has been refactored to deal with the new separation of service offering from disk offering internally.
listDiskOfferings shows encryption support on each offering and has an ‘encrypt’ boolean to choose to list only offerings that do or do not support encryption.
listServiceOfferings shows encryption support on each offering and has an ‘encryptroot’ boolean to choose to list only offerings that do or do not support encryption.
listHosts shows encryption support of each hypervisor host via an ‘encryptionsupported’ field.

Storage Drive

For the storage types supported by KVM, the encryption has been implemented in the QEMU itself using the built-in LUKS storage support. This means that the storage remains encrypted all the way to the Instance process and is decrypted before the block device is visible to the guest. For qcow2-based storage, qemu-img is used to set up a qcow2 file with LUKS encryption. However, for block-based storages (currently only ScaleIO), the cryptsetup utility is used to format the block device as LUKS for data disk but qemu-img and its LUKS support are used for template copy.

DB changes

A volume whose disk offering enables encryption will get a passphrase generated for it before its first use. This is stored in the new ‘passphrase’ table and is encrypted using the CloudStack installation’s standard configured DB encryption. A field has been added to the volumes table in the database, referencing this passphrase, and a foreign key added to ensure passphrases that are referenced can’t be removed from the database. The volumes table now also contains an encryption format field, which is set by the implementer of the encryption and used as it sees fit.

Limitations

Note that this is the first phase of the feature and thus it has some limitations. Even though it has been thoroughly tested, treat it as experimental and make sure you perform your own tests before using it in production. Currently, it supports only the KVM hypervisor and the following storage types: NFS, Local, Shared MountPoint and ScaleIO. For EL7, QEMU-EV v2.6+ is required. The used encryption is LUKS1.

KVM Host Setup

In order to enable Volume encryption, the following steps are needed when preparing KVM hosts:

1. Install qemu-ev (EL7, for newer EL8 and Ubuntu distributions, the stock version (non-ev) should work fine):
yum install -y qemu-kvm-common-ev-2.10.0 qemu-kvm-ev-2.10.0 qemu-img-ev-2.10.0 qemu-kvm-tools-ev-2.10.0
2. Install cryptsetup:
yum install cryptsetup
3. Optionally, use rngd (EL) or rng-tools (Ubuntu) – for better entropy.
4. Restart the agent.
systemctl restart cloudstack-agent

5. In the CloudStack UI, verify if the host is properly configured:

Creating Service and Disk Offering

To take full advantage of volume encryption features and protect sensitive data, the following steps must be completed to enable volume encryption for new Instances:

1. Add a new Service Offering, making sure that the “Encrypt” option is enabled:

2. Also, add a new Disk Offering making sure that the “Encrypt” option is enabled:

Volume Encryption Support Matrix

Operation Is it supported?
Start/Stop Instance Yes
Reboot Instance Yes
Reinstall Instance Yes
Expunge/recover Instance Yes
Change Instance Service Offering Yes
Migrate running Instance to another host Yes
Instance Snapshot No
Volume snapshot (Running Instance) No
Recurring snapshot No
Attach/detach encrypted volume Yes
Volume snapshot (stopped Instance) Yes
Revert to snapshot Yes
Resize Volume Yes
Delete Volume Yes
Download Volume No
Migrate Volume to another Primary Storage Yes
Recurring Volume Snapshots No
Create Template from encrypted Volume Snapshot No
Create Volume from encrypted Volume Snapshot No

Conclusion

In summary, while this level of encryption might not be enough for some use cases (as the keys are accessible by the cloud provider) this new feature is an important security improvement in Apache CloudStack 4.18 and can significantly reduce the risks of data theft in many cases. Using well-known and proven open-source implementation makes it a robust, high-performance solution for one of the most common security concerns – keeping your data safe.

Related Posts:

Apache CloudStack enables existing VMware users and gives an easy way for service providers to migrate to a fully open-source solution and eliminate vendor dependency.