Defender for Kubernetes Not Enabled: Why It Matters and How to Fix It

Kubernetes clusters are noisy, fast-moving, and full of attack surface. A misconfigured RBAC binding, an exposed dashboard, or a container running as root can all turn into a foothold for an attacker. Microsoft Defender for Containers is Azure's answer to watching that surface in real time, but it only works if it is switched on. This check catches the case where it is not.

---

What this check detects

The check inspects the Microsoft Defender for Cloud pricing configuration on the subscription and looks at the Containers plan. Defender plans have two pricing tiers:

• Free — basic Cloud Security Posture Management (CSPM) recommendations only. No active threat protection.
• Standard — full runtime threat detection, agentless and agent-based vulnerability scanning, control plane audit log monitoring, and Kubernetes-aware alerts.

When the Containers plan is set to Free (or has never been configured), the check fails. In practical terms, your AKS clusters in that subscription have no Defender runtime protection.

---

Why it matters

A Kubernetes cluster without runtime threat detection is a blind spot. The control plane API, kubelet, container runtime, and workloads all generate signals that map cleanly to known attack techniques, and none of those signals get analyzed when Defender is off.

Here are the concrete things you lose:

• Control plane threat detection. Defender ingests AKS audit logs and alerts on suspicious API activity, like a new high-privilege ClusterRoleBinding, exec into a pod from an unusual identity, or a service account token being requested in a strange pattern.
• Runtime detection on nodes. The Defender sensor watches for behavior such as a crypto miner spawning, a reverse shell, or a container breaking out to access the host filesystem.
• Vulnerability scanning. Images in your registry and running on your nodes get scanned against known CVEs, so you find the vulnerable log4j or openssl before someone else does.
• Posture recommendations with teeth. Misconfigurations like privileged containers, host network access, and missing network policies surface as actionable findings.

A common real-world chain: an attacker compromises a public-facing pod through an unpatched dependency, reads the mounted service account token, and uses it to list secrets across namespaces. With Defender off, the first time you hear about it is when your data shows up for sale. With Defender on, the exec and the token abuse both fire alerts within minutes.

There is also a compliance angle. Frameworks like CIS Azure, PCI DSS, and SOC 2 expect monitoring and threat detection on container workloads. An unprotected cluster is a finding waiting to happen during an audit.

---

How to fix it

You enable the standard tier of the Containers plan at the subscription level. This covers every AKS cluster in that subscription.

Option 1: Azure CLI

# Make sure you are pointed at the right subscription
az account set --subscription "<subscription-id>"

# Enable the standard tier for the Containers plan
az security pricing create \
  --name Containers \
  --tier Standard

Verify it took effect:

az security pricing show --name Containers --query "pricingTier" -o tsv
# Expected output: Standard

Option 2: Azure Portal

1. Open Microsoft Defender for Cloud.
2. Go to Environment settings and select your subscription.
3. Find the Containers plan in the list and toggle it to On.
4. Click Settings next to the plan to confirm the sub-components (Defender sensor, agentless discovery, registry scanning) are enabled.
5. Click Save.

After enabling, Defender needs the sensor deployed to your AKS clusters. Azure can do this automatically through a security policy, or you can confirm the agent on existing clusters.

Option 3: Terraform

resource "azurerm_security_center_subscription_pricing" "containers" {
  tier          = "Standard"
  resource_type = "Containers"
}

Option 4: Bicep

resource containersPricing 'Microsoft.Security/pricings@2023-01-01' = {
  name: 'Containers'
  properties: {
    pricingTier: 'Standard'
  }
}

---

How to prevent it from happening again

Manually enabling a setting on each subscription does not scale and drifts the moment someone creates a new subscription. Bake it into policy.

Use Azure Policy with deployIfNotExists

Microsoft ships a built-in policy that configures Defender for Containers. Assign it at the management group level so every current and future subscription is covered:

# Built-in policy: "Configure Microsoft Defender for Containers to be enabled"
az policy assignment create \
  --name "enable-defender-containers" \
  --display-name "Enable Defender for Containers" \
  --scope "/providers/Microsoft.Management/managementGroups/<mg-id>" \
  --policy "c9ddb292-b203-4738-aead-18e2716e858f" \
  --location eastus \
  --mi-system-assigned \
  --role "Owner"

Because this is a deployIfNotExists policy, it needs a managed identity with permission to remediate. After assignment, kick off a remediation task to bring existing non-compliant subscriptions into line.

Gate it in CI/CD

If your subscriptions are provisioned through IaC, add a check to the pipeline that fails when the Containers pricing tier is not standard. A simple post-apply gate:

tier=$(az security pricing show --name Containers --query "pricingTier" -o tsv)
if [ "$tier" != "Standard" ]; then
  echo "Defender for Containers is not enabled on this subscription"
  exit 1
fi

For policy-as-code shops, write the equivalent assertion in Checkov, OPA/Conftest, or Sentinel so it runs on every Terraform plan rather than after the fact.

---

Best practices

• Enable Defender across all subscriptions, not just the ones with clusters today. New AKS clusters get created in unexpected places. Covering every subscription means you are never caught out.
• Send AKS audit logs to Defender. Control plane detections depend on diagnostic settings forwarding audit logs. Confirm those are configured on each cluster.
• Act on the recommendations, not just the alerts. Defender's posture findings (privileged containers, host path mounts, missing network policies) are how you shrink the attack surface before an alert ever fires.
• Wire alerts into your response workflow. Route Defender alerts to your SIEM or ticketing system so a runtime detection at 3am reaches an on-call human, not a dashboard nobody watches.
• Pair it with image scanning in the pipeline. Defender scans registry images, but catching CVEs at build time is cheaper than catching them in production.
• Review the cost monthly. The Containers plan bills on usage. Track the spend so a cluster scale-up does not produce a surprise bill, and right-size environments where full runtime protection is overkill.

Enabling Defender for Containers is a one-line change with an outsized payoff. It turns your AKS clusters from a silent blind spot into a monitored surface where the techniques attackers actually use throw alerts the moment they happen. Turn it on, enforce it with policy, and move on to the next gap.