Microsoft Defender for Containers should be enabled

What does the recommendation "Microsoft Defender for Containers should be enabled" check?

Flags any subscription where the Defender for Containers plan is set to Free rather than Standard. The plan is a subscription-level toggle, so the check is about whether container threat detection is switched on at all, not about an individual cluster. With the plan on, Defender for Cloud discovers your Azure Kubernetes Service clusters, runs vulnerability assessment against images held in Azure Container Registry, and collects runtime signals from a node sensor plus the AKS control-plane audit logs. It does not on its own cover EKS or GKE clusters, which need a separate multicloud connector, and image scanning is scoped to ACR rather than arbitrary external registries.

Why does "Microsoft Defender for Containers should be enabled" matter?

Kubernetes is a high-value target: a single exploited image, an exposed kubelet or a leaked service-account token can let an attacker pivot from one pod into the whole cluster and the workloads it runs. Without Defender for Containers you have no runtime detection for crypto-mining, reverse shells or suspicious exec-into-pod activity, and no systematic vulnerability view of the images you are shipping. The business consequence is that a container compromise plays out silently until it surfaces as data theft or a ransomware event, at which point you are reconstructing the timeline from scratch. Turning the plan on gives you alerts at the moment of attack and a standing inventory of the CVEs you are exposed to.

How do I fix "Microsoft Defender for Containers should be enabled"?

1. In Defender for Cloud, open Environment settings, select the subscription, and switch the Containers plan from Off to On so the Defender sensor and agentless components roll out to discovered clusters.
2. From the CLI, run 'az security pricing create -n Containers --tier Standard' to enable the same plan, scoping it to a specific subscription with '--subscription <id>' when you manage several.
3. To keep new subscriptions covered, assign the built-in deploy policy by display name rather than a hardcoded GUID: pid=$(az policy definition list --query "[?displayName=='Configure Microsoft Defender for Containers to be enabled'].name" -o tsv); az policy assignment create --name enable-defender-containers --policy "$pid" --scope <management-group-or-subscription-scope> with a remediation identity so it self-corrects.

# 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