Clarification on diskEncryptionConfiguration.targets behavior for Azure Batch pools (Linux vs Windows)

Marisa GG 20 Reputation points

We are implementing Azure Policy compliance checks for Azure Batch pool disk encryption using the property:

Microsoft.Batch/batchAccounts/pools/deploymentConfiguration.virtualMachineConfiguration.diskEncryptionConfiguration.targets

According to the documentation:

  • On Linux pools, only "TemporaryDisk" is supported
  • On Windows pools, "OsDisk" and "TemporaryDisk" must be specified

However, we have observed some confusion in real deployments and would like clarification on the following points:

  1. What is the minimum required configuration for targets to be considered compliant for Linux and Windows pools respectively?
  2. For Linux pools, is "OsDisk":
    • not supported at all,
      • ignored if provided, or
        • considered invalid configuration?
        1. In Linux pools where only "TemporaryDisk" is valid, how is OS disk encryption expected to be handled (since OS disk still exists logically)?
        2. Is diskEncryptionConfiguration.targets intended to represent:
          • actual disk encryption state, or
            • only the scope of encryption intent configured at pool level?
            1. Are there any scenarios where Linux pools should explicitly include "OsDisk" in targets, or is this strictly Windows-only?

We want to ensure our Azure Policy implementation does not generate false positives due to OS-specific differences in how targets is interpreted.

0 comments No comments
Sign in to comment

Answer accepted by question author

Himanshu Shekhar 6,710 Reputation points • Microsoft External Staff • Moderator

Hey Marisa GG

  1. Minimum-required targets for compliance • Linux pools – you must specify exactly ["TemporaryDisk"]. • Windows pools – you must specify both ["OsDisk","TemporaryDisk"].
  2. What happens if you include "OsDisk" on a Linux pool? It isn’t supported on Linux. If you send it in the API request, Batch will reject it as invalid (you’ll get a validation error). It’s not silently ignored.
  3. How does OS-disk encryption work on Linux pools? – Batch pools always use platform-managed server-side encryption (encryption at host or PMK) for the OS disk on Linux. You don’t control that via diskEncryptionConfiguration.targets. That property is purely your intent for which disks Batch should apply its Disk Encryption Extension or host-based encryption on in Linux’s case the temporary disk only.
  4. Is targets a reflection of actual encryption state or just the intent? It’s strictly the intent configured at pool creation. Batch picks the best supported encryption method under the covers (ADE, SSE+PMK or Encryption-at-Host) to honor that intent. To see the real state, you’d have to inspect the VM’s encryption status after the pool is up.
  5. Any scenario where Linux needs "OsDisk" in targets? No. “OsDisk” is Windows-only in the Batch-pool context.

Reference list

0 comments No comments
Sign in to comment

1 additional answer

  1. AI answer

    1. Minimum required configuration for targets

    From the documented behavior of diskEncryptionConfiguration.targets:

    • If targets is omitted, no disks on the compute nodes in the pool will be encrypted.
    • On Linux pools, only "TemporaryDisk" is supported.
    • On Windows pools, "OsDisk" and "TemporaryDisk" must be specified.

    Therefore, for policy compliance based purely on the documented contract of targets:

    • Linux pools (when using disk encryption configuration):
      • Minimum compliant targets: an array containing only "TemporaryDisk".
      • Any other value (including "OsDisk") is outside the documented support.
    • Windows pools:
      • Minimum compliant targets: an array containing both "OsDisk" and "TemporaryDisk".
      • A configuration that omits either one is non-compliant with the documented requirement.
    1. Behavior of "OsDisk" on Linux pools

    The documentation states for Linux pools:

    On Linux pool, only "TemporaryDisk" is supported

    and for the .NET and management SDKs:

    On Linux pool, only "TemporaryDisk" is supported; on Windows pool, "OsDisk" and "TemporaryDisk" must be specified.

    This implies for Linux pools:

    • "OsDisk" is not a supported target value.
    • The supported set for Linux is effectively { "TemporaryDisk" }.

    The documentation does not describe a special “ignored” behavior for unsupported values; it only defines what is supported. For policy purposes, any targets that contains values outside the supported set should be treated as invalid/non-compliant configuration for Linux pools.

    1. How OS disk encryption is handled on Linux pools

    The disk encryption configuration is described as:

    The disk encryption configuration applied on compute nodes in the pool. Disk encryption configuration is not supported on Linux pool created with Virtual Machine Image or Azure Compute Gallery Image.

    and for DiskEncryptionConfiguration in the ARM/Bicep/TF templates:

    customerManagedKey will encrypt OS Disk by EncryptionAtRest, and by default we will encrypt the data disk as well. It can be used only when the pool is configured with an identity and OsDisk is set as one of the targets of DiskEncryption.

    Combined with the Linux restriction:

    • For Linux pools, only "TemporaryDisk" can be specified in targets.
    • The note about customerManagedKey requiring OsDisk as a target applies where OsDisk is allowed (i.e., Windows pools). For Linux, the supported target set prevents specifying OsDisk, so OS disk encryption via this pool-level targets mechanism is not described as supported.

    For policy design, this means:

    • Do not infer that OS disk encryption is controlled via targets on Linux pools in the same way as on Windows.
    • Treat Linux targets as governing encryption of TemporaryDisk only, per the documented restriction.
    1. Intent vs actual encryption state

    The .NET API documentation for Targets states:

    Gets the list of disk targets Batch Service will encrypt on the compute node.

    and the management model:

    Gets or sets the list of disk targets Batch Service will encrypt on the compute node.

    This describes targets as the configuration of which disks the Batch service will encrypt on the node, i.e., the scope of encryption intent at the pool level. It does not claim to be a runtime status indicator.

    For policy purposes:

    • diskEncryptionConfiguration.targets should be treated as desired configuration / intent, not as a guarantee of current encryption state.
    • Compliance checks based solely on targets should be framed as “configured to encrypt these disks,” not “verified that these disks are currently encrypted.”
    1. Whether Linux pools should ever include "OsDisk" in targets

    All provided documentation is consistent and explicit:

    • On Linux pools, only "TemporaryDisk" is supported.

    There is no documented scenario where Linux pools should include "OsDisk" in targets. The OsDisk requirement appears strictly tied to Windows pools in the documentation.

    For policy design, this leads to the following rules:

    • Linux pools:
      • Compliant targets set (when present): exactly {"TemporaryDisk"}.
      • Any occurrence of "OsDisk" in targets should be treated as non-compliant/invalid per the documented support.
    • Windows pools:
      • Compliant targets set must include both "OsDisk" and "TemporaryDisk".

    These rules avoid false positives by aligning with the OS-specific constraints described in the APIs and ARM/Bicep/TF schema.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer