When working with Azure Compute Gallery, one of its strongest features is the ability to replicate image versions across regions to standardize VM deployments at scale. However, when it comes to disk encryption, things can get tricky especially if you are using Customer-Managed Keys (CMK).
In this article, I’ll walk you through the problem, why it exists, and the available solutions/workarounds.
Table of Contents
The Problem: CMK and Cross-Subscription Usage
Azure Compute Gallery is designed to simplify image lifecycle management by allowing you to distribute image versions across regions and consume them from multiple subscriptions. This works seamlessly when disks are encrypted with platform-managed keys (PMK).
The challenge arises when using Customer-Managed Keys (CMK), as image versions cannot be used across subscriptions. These limitations are documented in Microsoft’s official guidance.
The reason is that CMK encryption for managed disks requires a Disk Encryption Set (DES), and a DES is scoped to a single subscription (and region). When an image version that depends on a DES is published in the gallery, it cannot be used in another subscription because that subscription does not have access to the same Disk Encryption Set.
In a recent project, the strategy was to host a shared subscription dedicated to central services such as the Azure Compute Gallery. This approach promised several benefits:
- Simplified golden image management and versioning.
- Consistent image availability from a single gallery across all workloads globally.
- Reduced operational overhead and cost by avoiding duplicate image builds.
But due to the subscription-scoped nature of the Disk Encryption Set, this architecture could not be realized as planned.
Example Scenario
- You create a golden image in Subscription A.
- The OS disk is encrypted with a Customer-Managed Key (CMK) via a Disk Encryption Set (DES) in Subscription A.
- You publish the image as a version in your Azure Compute Gallery, which is also hosted in Subscription A.
- You try to use that image version in Subscription B to deploy a VM.
- The deployment fails because the Disk Encryption Set is tied to Subscription A and cannot be referenced from Subscription B.
⚠️ The issue isn’t just about Key Vault access across subscriptions, Azure Compute Gallery simply can’t use encryption keys outside the subscription they belong to.
Why This Matters
For many organizations, centralized image management is a cornerstone of their VM provisioning strategy. A common pattern is to maintain a shared services subscription that hosts the Azure Compute Gallery, so golden images can be created once and consumed everywhere. This reduces duplication, ensures governance, and cuts operational costs.
However, when Customer-Managed Keys (CMK) are used, this approach breaks down. The dependency on a Disk Encryption Set (DES) which is always tied to a single subscription prevents image versions from being used across subscriptions.
This means:
- You cannot maintain one gallery for all subscriptions if CMK is required.
- Each subscription would need its own DES, and therefore its own set of images.
- This adds complexity, operational overhead, and cost the opposite of what a shared gallery is supposed to achieve.
Solutions and Workarounds
Use Platform-Managed Keys (PMK)
If regulatory requirements allow, stick with PMK for disk encryption.
- Fully supported across regions and subscriptions.
- Keeps image replication simple and cost-effective.
- Still uses FIPS 140-2 compliant encryption at rest.
👉 For most enterprises, PMK already meets compliance requirements. Consider what data your image actually contains and whether it truly justifies the added complexity of CMK.
✅ This doesn’t mean that your VMs running the workloads cannot or should not be CMK-encrypted!
Per-Subscription Disk Encryption Sets (if CMK is mandatory)
If CMK is a must-have, you need to design with subscription-local Disk Encryption Set in mind:
- Each subscription must host its own Disk Encryption Set.
- Images must be created or re-encrypted against the local DES before deployment.
- This means building or replicating image versions separately per subscription.
To minimize manual overhead, the key to a scalable solution is automating image builds (e.g. HashiCorp Packer) combined with a clean CI/CD workflow that includes:
- Automate image builds per subscription.
- Apply the subscription’s local DES configuration for CMK encryption.
- Publish image versions into a gallery within the same subscription and local DES.
⚡ This approach ensures compliance and reduces repetitive work, though it still adds complexity and operational overhead compared to Platform-Managed Keys.
Summary
When planning your Azure Compute Gallery strategy, it’s important to carefully evaluate the need for Customer-Managed Keys (CMK) versus Platform-Managed Keys (PMK):
Engage with security and governance teams to confirm whether CMK is truly required. If it’s only for “control” rather than regulatory compliance, PMK is often the more pragmatic choice. Avoid introducing unnecessary complexity unless mandated by auditors or regulations.
Platform-Managed Keys (PMK)
- Centralized and subscription-agnostic
- Simple to manage
- Scales easily across regions and subscriptions
Customer-Managed Keys (CMK)
- Subscription-scoped due to Disk Encryption Sets
- Adds operational complexity
- Requires automation to maintain compliance and consistency