Upgrade Azure Kubernetes Service to remove vulnerabilities from AKS system pods (Preview)

What does the recommendation "Upgrade Azure Kubernetes Service to remove vulnerabilities from AKS system pods (Preview)" check?

Flags AKS clusters whose Microsoft-managed system pods, the kube-system workloads such as coredns, konnectivity-agent, metrics-server and the CSI drivers, carry known vulnerabilities that a cluster or node image upgrade would resolve. Defender for Cloud scans the images backing these system components and matches them against published CVEs, then surfaces the finding when a newer AKS version or node image ships the fix. It scopes only to AKS-owned system pods on the data plane: it does not assess your own application container images, registry images, the Kubernetes API server posture, or workloads you deploy into other namespaces, which are covered by separate container recommendations.

Why does "Upgrade Azure Kubernetes Service to remove vulnerabilities from AKS system pods (Preview)" matter?

System pods run with elevated cluster privileges and sit on the network path for DNS, metrics and node-to-control-plane traffic, so a vulnerability here is not a contained application bug: a flaw in coredns or a CSI driver can be leveraged for lateral movement, privilege escalation or cluster-wide denial of service. Because these images are managed by Azure, teams often assume they are patched automatically and never notice they are running an outdated AKS version that Microsoft has already issued a fix for. The business consequence is a high-severity, exploitable component running unpatched in your most privileged namespace, widening the blast radius of any container breakout and undermining compliance attestations that depend on timely remediation.

How do I fix "Upgrade Azure Kubernetes Service to remove vulnerabilities from AKS system pods (Preview)"?

1. Confirm the current and available versions with 'az aks get-upgrades --resource-group <rg> --name <cluster> --output table', then upgrade the cluster to a patched version using 'az aks upgrade --resource-group <rg> --name <cluster> --kubernetes-version <version>', which rolls the control plane and reschedules the system pods onto patched images.
2. If the finding is resolved by a newer node OS image rather than a Kubernetes version bump, refresh nodes in place with 'az aks upgrade --resource-group <rg> --name <cluster> --node-image-only --yes' so the system pods land on updated host images.
3. Make this self-healing by enabling automatic upgrades: set 'az aks update --resource-group <rg> --name <cluster> --auto-upgrade-channel patch' for Kubernetes patches and 'az aks update --resource-group <rg> --name <cluster> --node-os-upgrade-channel SecurityPatch' for node OS updates, both paired with a configured maintenance window so future fixes apply without manual action.

# Bring machines into Azure Update Manager: switch on periodic assessment
# and platform-orchestrated patching, then deploy the audit agent.
for vm in $(az vm list -g rg-workloads --query "[].name" -o tsv); do
  az vm update -g rg-workloads -n "$vm" \
    --set osProfile.windowsConfiguration.patchSettings.assessmentMode=AutomaticByPlatform \
    --set osProfile.windowsConfiguration.patchSettings.patchMode=AutomaticByPlatform
  # Guest Configuration extension requires a system-assigned identity.
  az vm identity assign -g rg-workloads -n "$vm"
  az vm extension set -g rg-workloads --vm-name "$vm" \
    --name AzurePolicyforWindows \
    --publisher Microsoft.GuestConfiguration
  echo "$vm: periodic assessment on, auto-patch on, config extension deployed"
done

# Ratchet it shut: assign the built-in policy that enables periodic
# assessment on every machine in the subscription.
az policy assignment create \
  --name enable-periodic-assessment \
  --policy 59efceea-0c96-497e-a4a1-4eb2290dac15 \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000" \
  --location uksouth --mi-system-assigned