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.
Vladimir is currently working as a software engineer in test at ShapeBlue. He has more than 20 years of experience in the IT field, starting as a system administrator and then moving to software testing. Working on the Apache CloudStack project aligns perfectly with his passion for open source projects and the ambition to learn more about the cloud technologies today. Making sure the software works as expected and the project gets better with each iteration is his best motivation. You can learn more about Vladimir and his background by reading his Meet The Team blog.