Guest Attestation extension should be installed on supported Linux virtual machines

What does the recommendation "Guest Attestation extension should be installed on supported Linux virtual machines" check?

Audits supported Linux VMs, those created with Trusted Launch and with both Secure Boot and vTPM enabled, that are missing the GuestAttestation extension (publisher Microsoft.Azure.Security.LinuxAttestation, type GuestAttestation). This is the AuditIfNotExists '[Preview]' policy from the Security Center category: it confirms the extension is present so the vTPM-measured boot chain can be remotely attested through the Azure Attestation endpoint. It checks installation only, not whether attestation currently passes; a separate 'Virtual machines guest attestation status should be healthy' recommendation covers the live result. It also does not apply to Windows VMs, to virtual machine scale sets (each has its own dedicated policy), or to Generation 1 and legacy-SKU VMs that cannot run Trusted Launch in the first place, so the scope is narrower than 'every Linux VM in the subscription'.

Why does "Guest Attestation extension should be installed on supported Linux virtual machines" matter?

Trusted Launch measures the UEFI firmware, boot loader and kernel into a vTPM, but without the Guest Attestation extension nobody reads those measurements back. The vTPM faithfully records a tampered boot chain and the signal is then simply discarded. A bootkit or rootkit that survives a reboot runs undetected, and Microsoft Defender for Cloud has no boot-integrity evidence to alert on, so the very class of persistent threat Trusted Launch was bought to stop slips through. Installing the extension turns the hardware-rooted measurements into a continuously verified signal: a compromised early boot stage surfaces as a Defender for Cloud alert rather than staying silent until the host is already owned. For a regulated estate, that attestation record is also the auditable proof that the control is operating, not merely configured, which matters when an assessor asks you to demonstrate boot integrity rather than assert it.

How do I fix "Guest Attestation extension should be installed on supported Linux virtual machines"?

1. On a Trusted Launch VM that already has Secure Boot and vTPM on, run 'az vm update --resource-group <rg> --name <vm> --enable-integrity-monitoring', which deploys the GuestAttestation extension and wires it to the Azure Attestation endpoint.
2. Add the same extension in your Bicep VM module as a Microsoft.Compute/virtualMachines/extensions resource with publisher 'Microsoft.Azure.Security.LinuxAttestation', type 'GuestAttestation' and enableAutomaticUpgrade set to true, so new builds ship attested.
3. If outbound traffic is filtered, allow the 'AzureAttestation' service tag on the VM's network security group and any Azure Firewall, otherwise the extension provisions but cannot reach the attestation endpoint.

# 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"