Microsoft Defender for Cloud · Azure Arc-enabled Kubernetes
Azure Arc-enabled Kubernetes clusters should have the Defender extension installed
Written and reviewed by Emnode · Last reviewed
What does the recommendation "Azure Arc-enabled Kubernetes clusters should have the Defender extension installed" check?
Flags any Arc-connected Kubernetes cluster that is missing the Microsoft Defender sensor extension (extension type 'microsoft.azuredefender.kubernetes'). That extension collects data from all control plane (master) nodes in the cluster and sends it to the Microsoft Defender for Containers backend in the cloud for further analysis and threat detection. The check looks only at on-premises and other-cloud clusters projected into Azure through Arc as connectedClusters resources. It does not inspect native AKS clusters, it does not verify the separate Azure Policy for Kubernetes add-on, and it says nothing about registry image scanning or agentless vulnerability assessment, which are distinct Defender for Containers capabilities. Presence of the extension is checked, not whether the Defender for Containers plan is switched on at the subscription, so a cluster can satisfy this control yet still produce no alerts until the plan is enabled.
Why does "Azure Arc-enabled Kubernetes clusters should have the Defender extension installed" matter?
Without the sensor, Defender for Cloud has no runtime visibility into the cluster: crypto-mining payloads, container escapes, suspicious exec into a pod, and reconnaissance against the Kubernetes API all go undetected because the audit-log and node telemetry never reach the analytics backend. Arc clusters are usually the ones running in branch sites, factories or another provider, exactly where a local breach can sit unnoticed for weeks. The business consequence is a blind spot in your hybrid estate that breaks the assumption behind any 'we monitor all production Kubernetes' compliance statement, and it removes the early-warning signal that would otherwise let you contain an incident before it reaches data or pivots into the wider network.
How do I fix "Azure Arc-enabled Kubernetes clusters should have the Defender extension installed"?
- Enable the Defender for Containers plan on the subscription first, otherwise the extension installs but generates no alerts: in Defender for Cloud, open Environment settings, select the subscription, and turn on the Containers plan.
- Install the sensor on each flagged cluster with the Azure CLI: 'az k8s-extension create --name microsoft.azuredefender.kubernetes --extension-type microsoft.azuredefender.kubernetes --cluster-type connectedClusters --cluster-name <cluster> --resource-group <rg> --release-train stable', or use the recommendation's built-in 'Fix' action in Defender for Cloud to remediate the affected clusters in bulk.
- To keep new Arc clusters covered automatically, assign the matching built-in DeployIfNotExists policy by exact display name rather than a hardcoded GUID: pid=$(az policy definition list --query "[?displayName=='[Preview]: Configure Azure Arc enabled Kubernetes clusters to install Microsoft Defender for Cloud extension'].name" -o tsv); az policy assignment create --name deploy-arc-defender --policy "$pid" --scope <scope> --location <region> --identity-scope <scope> --role Contributor.
Remediation script · bash
# Enable the three high-value Defender plans on the current subscription.
# Servers on Plan 2 (adds JIT access, FIM and vulnerability scanning).
az security pricing create --name VirtualMachines \
--tier Standard --subplan P2
# Storage on the current per-account plan.
az security pricing create --name StorageAccounts --tier Standard
# Azure SQL Database servers (VA + Advanced Threat Protection).
az security pricing create --name SqlServers --tier Standard
# Verify what is now active on this subscription.
az security pricing list \
--query "value[?pricingTier=='Standard'].name" -o tsv
# Ratchet it shut for the estate: assign the built-in DeployIfNotExists
# policies that turn each plan on for any subscription where it is missing.
# Servers (built-in 'Configure Azure Defender for servers to be enabled').
az policy assignment create \
--name enable-defender-servers \
--policy 8e86a5b6-b9bd-49d1-8e21-4bb8a0862222 \
--scope "/providers/Microsoft.Management/managementGroups/contoso-root"
# Look up the matching Storage and SQL policies by display name rather than
# hard-coding a GUID, then assign each the same way at the same scope.
az policy definition list \
--query "[?contains(displayName, 'Configure Microsoft Defender for Storage') || contains(displayName, 'Configure Azure Defender to be enabled on SQL servers')].{name:name, displayName:displayName}" \
-o table Full walkthrough (console steps, edge cases and verification) in the lesson Enable Microsoft Defender for Cloud plans.
Is "Azure Arc-enabled Kubernetes clusters should have the Defender extension installed" a false positive?
A short-lived or lab Arc cluster that is intentionally excluded from threat monitoring, for example a sandbox you connect to test an extension upgrade and then delete, will flag while it is connected even though leaving it unmonitored is the correct choice. Rather than installing the sensor everywhere to silence the finding, scope the Defender remediation and the DeployIfNotExists policy assignment to your production resource groups and create a documented exemption for the excluded cluster, so the control still catches the real production gaps you do care about.