I think it goes without saying that encrypting data is a crucial part of any cloud deployment. The most common method that VM disks in Azure are encrypted with leverages Azure Disk Encryption (ADE). However, there is a new(ish) method to encrypt data on VM hosts that is now available and meets the same requirements that I’d like to cover in this blog post.
For context, let’s review the three times that data may be encrypted:
Data In Use: Let’s get this term out of the way first. Most data needs to be decrypted before it can be used. If you truly need your data to be encrypted while you’re using it then you should use a service like confidential compute. True confidential computing dives into components like enclaves, full memory encryption, etc. but for the purposes of this post, we’ll assume that while you care about encryption, you also trust the VM environment.
Data In Transit: This term focuses on communication channels. Data in transit typically relies on an encrypted network connection and may include a hashing algorithm to ensure that your data was not altered in transit by a man-in-the-middle (MITM) attack. This is where web protocols such as SSL and TLS come into play.
Data at Rest: This final term focuses on how your data is protected when it’s not being used. For example, in Azure, the underlying Azure Storage service is always encrypted and decrypted transparently using 256-bit AES encryption and is FIPS 140-2 compliant and this cannot be disabled.
Now, let’s take a look at the different VM encryption acronyms in Azure:
| ADE Azure Disk Encryption | SSE Server-Side Encryption | SSE Storage Service Encryption |
| Encryption at the OS level that leverages BitLocker or DM-Crypt and requires CPU overhead. | OS-agnostic VM encryption handled by the underlying storage service. GA for Managed Disks was released in April 2020. | This became a confusing term after VM SSE was launched, but it’s just the default encryption for Azure Storage. |
From this point on, anytime you see SSE, I’m simply referring to server-side encryption.
All three of these encryption mechanisms can use Azure platform-managed keys (PMK) or customer-managed keys (CMK). I’m going to assume that if you’re still reading about host-based encryption at this point, you probably care enough to maintain control and rotation of your keys. That being the case, we’re going to look at this solution through the lens of server-side encryption with a customer-managed key, or SSE + CMK.
Quick Review: You’ll likely keep any customer-managed keys in Azure Key Vault. Key Vault is Azure’s “HSM-as-a-Service” that exists to centralize application secrets, certificates, and keys, while monitoring access and use. You can generate or import keys and there are HSM-backed premium offerings.
Azure Key Vault
The customer-managed key is actually a Key Encryption Key (KEK) to keep key rotation efficient and negate the need to fully decrypt and re-encrypt data. When you “rotate your keys” you are really just rotating a key that the data encryption key is wrapped with. This brings the benefit of efficiency without compromising security.
The first step of leveraging SSE + CMK is creating a Disk Encryption Set. This is a resource in Azure that needs to be created prior to creating any VMs. It is essentially just a container for Managed Disks and is linked to a key in Key Vault. An underlying Managed Identity is also created to give the Disk Encryption Set read access to the Key Vault.
The Disk Encryption Set encryption type must match the selection of the VM encryption type. For example, if you want to leverage “Double encryption with platform-managed and customer-managed keys” then your Disk Encryption Set also has to be created with this as the encryption type. You cannot mix and match these methods in the same Disk Encryption Set.
Once you have a Disk Encryption Set created and linked to a key in Key Vault, simply select the corresponding encryption type when you create your VM:
You’ll see that the ARM template looks slightly different and now includes a diskEncryptionSet property:
All encrypted VMs must use either traditional Azure Disk Encryption (ADE) or SSE, you cannot mix and match or have both enabled. However, you can create an OS disk that is encrypted with SSE + CMK and another that uses SSE with a platform-managed key. Simply put, the restriction is at the Managed Disk level, not the VM level.
Host-Based Encryption
You’ve read a lot about securing VM disks, but not about host-based encryption yet. That’s because SSE is a typically (but not required) prerequisite to host-based encryption. A host is the physical server that a VM runs on, and multiple VMs run on a single host:
When we compare ADE and SSE, remember that ADE happens at the OS level and is using VM resources. This has several documented limitations, but one that I often see is that Azure does not currently support encrypting custom Linux images.
When we turn on host-based encryption (aka encryption at host) the encryption happens on the physical server the VM is running on, not just on the way back to the underlying storage service:
The host takes the CPU hit, not your VM, and this means that temporary, ephemeral, cached, and un-managed disks are also encrypted.
Sounds great, right? Unfortunately there are quite a few limitations that the product teams are actively working through. For example, this only exists in certain regions on certain VM sizes, it doesn’t support ultra disks, and it isn’t even in the portal by default. Enabling host-based encryption in your subscription today requires an email to the Azure product team and using a magic link to access your portal. (magic = a feature flag in the URL…) Once it’s turned on, you’ll see a checkbox to enable host-based encryption when you create your VM’s disks and will also see it in the corresponding ARM template.
Next Steps
Read through the Microsoft documentation about these features. I’ve tried to provide a comprehensive overview here, but the product is always changing and that’s your best bet for up-to-date information on the service.
