Linux virtual machines should enforce kernel module signature validation

What does the recommendation "Linux virtual machines should enforce kernel module signature validation" check?

Flags Linux VMs whose running kernel does not enforce signature validation on loadable kernel modules, so an unsigned or untrusted module could be inserted and run in kernel mode. Defender for Cloud reads this in-guest, which means it only assesses Linux machines that already have the Azure Monitor Agent installed and reporting; VMs without that agent are simply not evaluated rather than passed. It checks the running enforcement state, not whether Secure Boot or Trusted Launch is on, and it does not verify the bootloader or kernel image itself: signed boot components are a separate recommendation.

Why does "Linux virtual machines should enforce kernel module signature validation" matter?

A kernel module runs with full ring-0 privilege, so an attacker who can load one bypasses every user-space control and most endpoint tooling. Loadable-module abuse is the classic foothold for Linux rootkits that hide processes, files and network connections, and for persistence that survives reboots. Without enforced signature validation, anyone with root, or anything that escalates to it, can insert arbitrary code into the kernel undetected. Enforcement closes that path: the kernel refuses to load any module it cannot verify against a trusted key, which sharply limits what a compromise can do and keeps your detection tooling trustworthy. For regulated workloads it is also part of demonstrating host integrity.

How do I fix "Linux virtual machines should enforce kernel module signature validation"?

1. Confirm the gap on the VM: check whether enforcement is active with 'cat /sys/module/module/parameters/sig_enforce' (Y means enforced) and review 'dmesg | grep -i "module signing"'. Note that enforcement requires a kernel built with CONFIG_MODULE_SIG, which most current distribution kernels ship.
2. Turn on enforcement persistently by adding 'module.sig_enforce=1' to the kernel command line in GRUB (edit GRUB_CMDLINE_LINUX in /etc/default/grub, run 'update-grub' or 'grub2-mkconfig -o /boot/grub2/grub.cfg', then reboot). Make sure every module you actually need, including third-party or DKMS-built drivers, is signed by a key the kernel trusts before you reboot, or the VM may lose required functionality.
3. Bake it into the image rather than fixing VMs one at a time: set the enforcement parameter in your golden image or cloud-init/Bicep customData, sign any custom modules in the build pipeline, and re-image so new VMs come up enforced. There is no backing Azure Policy definition for this recommendation, so it is remediated in-guest, not by assigning a built-in policy.

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