Azure Compute Gallery – The Challenge of Encryption with Customer-Managed Keys across Subscriptions

Reading Time: 4 minutes

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.

Update (02/25/2026)

  • The user “Some Guy” reported that the limitation no longer exists and that he was able to use a Compute Gallery image version encrypted with a CMK across subscriptions. I retested this scenario and can confirm that it works.
  • During my tests with Azure Compute Gallery last year, I incorrectly assumed that the managed identity of a virtual machine provisioned in Subscription B would need access to the same disk encryption set or at least to the encryption key from Subscription A (which hosts the Compute Gallery resource). This assumption turned out to be incorrect.
  • In reality, no access to the encryption key or disk encryption set is required. The only permission needed is Reader access to the Compute Gallery in Subscription A. No additional access is necessary.

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

  1. You create a golden image in Subscription A.
  2. The OS disk is encrypted with a Customer-Managed Key (CMK) via a Disk Encryption Set (DES) in Subscription A.
  3. You publish the image as a version in your Azure Compute Gallery, which is also hosted in Subscription A.
  4. You try to use that image version in Subscription B to deploy a VM.
  5. 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

2 comments

  1. I’m not sure if it changed recently but I’m afraid this isn’t correct.
    I tested manually and I was able to deploy a VM in Subscription B from a Compute Gallery Image using CMKs in Subscription A.
    Just putting this here as I needed to do this for my organization and found this article first which made me doubt it was possible

    1. Hi, thanks a lot for the response. I tested it again and it’s working now.
      I’ll update the post accordingly. Thanks for letting me know.

Leave a Reply to citrixguyblog Cancel reply

Your email address will not be published. Required fields are marked *