Microsoft Defender for Cloud · Virtual Machine Scale Sets
Guest Attestation extension should be installed on supported Linux virtual machine scale sets
Written and reviewed by Emnode · Last reviewed
What does the recommendation "Guest Attestation extension should be installed on supported Linux virtual machine scale sets" check?
Flags any Trusted Launch or Confidential Linux virtual machine scale set that already has Secure Boot and a virtual TPM enabled but is missing the Guest Attestation extension (publisher Microsoft.Azure.Security.LinuxAttestation, type GuestAttestation). The extension is what lets Microsoft Defender for Cloud remotely attest the boot chain, so without it the platform cannot confirm the scale set booted a trusted measured boot. The check only applies to scale sets whose securityProfile already declares securityType TrustedLaunch or ConfidentialVM with secureBootEnabled and vTpmEnabled set to true. It does NOT enable Trusted Launch, Secure Boot or vTPM for you, does NOT cover standalone virtual machines (a separate recommendation handles those), does NOT apply to Windows scale sets, and does NOT validate that attestation is currently passing, only that the extension is present.
Why does "Guest Attestation extension should be installed on supported Linux virtual machine scale sets" matter?
Secure Boot and a vTPM measure the boot chain, but those measurements are worthless if nothing reads them. Without the Guest Attestation extension the scale set boots in the dark: a rootkit or tampered kernel module that loads before the OS leaves no signal you can act on, and Defender for Cloud cannot raise a boot-integrity alert. For a horizontally scaled workload that constant churn of instances multiplies the blind spot across every node. The business consequence is a compromised image silently propagating as the scale set grows, plus a gap in the evidence trail when an auditor or incident responder asks you to prove the fleet booted clean. Installing the extension turns the hardware measurements into a monitored, attestable signal.
How do I fix "Guest Attestation extension should be installed on supported Linux virtual machine scale sets"?
- Confirm the scale set already has Trusted Launch prerequisites in place, since the extension fails to install without them: check that securityProfile.securityType is TrustedLaunch (or ConfidentialVM) and that uefiSettings.secureBootEnabled and uefiSettings.vTpmEnabled are both true. These cannot be added to an existing scale set that was created without them, so a non-compliant legacy scale set must be rebuilt from a Trusted Launch image.
- Install the extension across the fleet with: az vmss extension set --resource-group <rg> --vmss-name <vmss> --name GuestAttestation --publisher Microsoft.Azure.Security.LinuxAttestation --version 1.0 --enable-auto-upgrade true, then run az vmss update-instances to roll it out to running instances (or rely on your automatic OS upgrade policy).
- To enforce this at scale, assign the built-in audit policy by looking up its definition ID rather than pasting a GUID: pid=$(az policy definition list --query "[?displayName=='[Preview]: Guest Attestation extension should be installed on supported Linux virtual machines scale sets'].name" -o tsv); az policy assignment create --name guest-attest-linux-vmss --policy "$pid" --scope <scope>. To remediate automatically instead of only auditing, assign the matching deployIfNotExists policy '[Preview]: Configure supported Linux virtual machine scale sets to automatically install the Guest Attestation extension'.
Remediation script · bash
# Upgrade one VM in place to a verified boot chain.
# Secure Boot + vTPM is a security-profile change, so the VM must be deallocated first.
RG="workloads-rg"
VM="payments-api-prod"
az vm deallocate --resource-group "$RG" --name "$VM"
az vm update --resource-group "$RG" --name "$VM" \
--security-type TrustedLaunch \
--enable-secure-boot true \
--enable-vtpm true
az vm start --resource-group "$RG" --name "$VM"
# Install the guest attestation extension so Defender can read the boot remotely.
# Publisher is Microsoft.Azure.Security.LinuxAttestation for Linux,
# Microsoft.Azure.Security.WindowsAttestation for Windows.
az vm extension set \
--resource-group "$RG" --vm-name "$VM" \
--name GuestAttestation \
--publisher Microsoft.Azure.Security.LinuxAttestation \
--enable-auto-upgrade true
# Ratchet it shut: audit any future machine that lacks Secure Boot.
# Look the built-in policy up by its exact display name; never paste a guessed GUID.
pid=$(az policy definition list \
--query "[?displayName=='Secure Boot should be enabled on supported Windows virtual machines'].name" -o tsv)
az policy assignment create \
--name audit-secure-boot \
--policy "$pid" \
--scope "/subscriptions/00000000-0000-0000-0000-000000000000"Full walkthrough (console steps, edge cases and verification) in the lesson Enable secure boot and attestation.
Is "Guest Attestation extension should be installed on supported Linux virtual machine scale sets" a false positive?
A scale set running an image that deliberately does not enable Secure Boot, for example a custom Linux image that loads unsigned out-of-tree kernel modules a signed boot chain would reject, is a legitimate exception. Because attestation cannot pass with Secure Boot disabled, installing the extension there would only generate noise, so excluding that scale set from the assignment scope is the correct call rather than forcing the extension on. Document the deviation, since you are knowingly forgoing boot-integrity monitoring for that workload.