How to fix AKS Defender error in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 6, 2025· 104 views

AKS Defender errors occur when Microsoft Defender for Containers fails to deploy, authenticate, or send security data to Azure. Common causes include disabled feature flags, network connectivity issues, cgroup v2 incompatibility, and invalid cluster configurations.

Quick fix

Fixes AKS Defender error

# Register the feature (requires Owner role on subscription)
az feature register --namespace Microsoft.ContainerService --name AKS-AzureDefender

# Wait for it to show as "Registered"
az feature list --output table --query "[?contains(name, 'AKS-AzureDefender')]"

# Once Registered, refresh provider
az provider register --namespace Microsoft.ContainerService
  1. Enable Defender for Containers feature on subscription
  2. Enable Defender on existing AKS cluster
  3. Verify Defender pods are running
  4. Check for cgroup v2 incompatibility (older Defender versions)
kubernetes — error
# Register the feature (requires Owner role on subscription)
az feature register --namespace Microsoft.ContainerService --name AKS-AzureDefender
# Wait for it to show as "Registered"
az feature list --output table --query "[?contains(name, 'AKS-AzureDefender')]"
# Once Registered, refresh provider
az provider register --namespace Microsoft.ContainerService
AKS Defender error

What this error means

Microsoft Defender for Containers is a cloud-native Kubernetes security service that provides workload protection, vulnerability scanning, and runtime threat detection for Azure Kubernetes Service (AKS) clusters. When an "AKS Defender error" occurs, it indicates the Defender agent or sensor components cannot initialize, authenticate with Azure, or communicate with the Defender for Cloud backend. This error blocks security monitoring and prevents Defender from scanning for vulnerabilities or detecting runtime threats. Defender errors can manifest in multiple ways: feature enablement failures on cluster creation, daemonset pod failures after cluster is running, connectivity timeouts in private clusters, or compatibility issues with specific Kubernetes versions. Each requires a different troubleshooting approach.

Typical symptoms

  • Error message: "AzureDefender installation is not allowed since feature 'Microsoft.ContainerService/AKS-AzureDefender' is not enabled"
  • Microsoft Defender agent pods in Running state but reporting "Failed to register certificate with TLS12" errors
  • Defender pods crash-looping with "open /sys/fs/cgroup/memory/memory.usage_in_bytes: no such file or directory" (cgroup v2 issue)
  • Defender publisher daemonset fails to deploy via Azure Policy with "invalid orchestratorProfile.OrchestratorVersion"
  • No Defender pods appear in kube-system namespace despite enabling Defender on cluster
  • Azure Policy shows compliance failures for Defender profile configuration
  • Private AKS cluster shows Defender pods in Pending state with networking errors
  • Cluster security dashboard reports "unable to collect data" despite Defender being enabled
  • Cloud Shell or portal shows "Failed to enable Defender for Containers" during cluster updates

Common causes

  1. Defender feature flag not enabled on Azure subscription (most common)
  2. Cluster API version or orchestrator version incompatible with Defender
  3. cgroup v2 (systemd) incompatibility—Defender collector expects cgroup v1 file paths
  4. Private AKS cluster lacks outbound access to Defender service endpoints (*.oms.opinsights.azure.com)
  5. Network security group (NSG) or firewall blocks required Azure service FQDNs
  6. AKS-managed Log Analytics workspace deleted or disconnected
  7. Invalid or expired TLS certificates for Defender publisher communication
  8. Cluster RBAC or pod security policies prevent Defender daemonset from running
  9. Orchestrator version (Kubernetes) version too old for current Defender release

How to fix "AKS Defender error"

1Enable Defender for Containers feature on subscription

The most common cause is the Defender preview feature not being enabled:

bash
# Register the feature (requires Owner role on subscription)
az feature register --namespace Microsoft.ContainerService --name AKS-AzureDefender

# Wait for it to show as "Registered"
az feature list --output table --query "[?contains(name, 'AKS-AzureDefender')]"

# Once Registered, refresh provider
az provider register --namespace Microsoft.ContainerService

Wait 5-10 minutes for propagation. If still seeing errors, your subscription may not have preview access—contact Azure support.

2Enable Defender on existing AKS cluster

Once the feature is registered, enable Defender on your cluster:

bash
# Update cluster with Defender enabled
az aks update \
  --resource-group <resource-group-name> \
  --name <cluster-name> \
  --enable-defender

# Verify it was applied
az aks show \
  --resource-group <resource-group-name> \
  --name <cluster-name> \
  --query "securityProfile.defender"

The cluster control plane will update (takes 5-10 minutes). Monitor with az aks show to see when it completes.

3Verify Defender pods are running

Check that Defender components deployed successfully:

bash
# Get kubeconfig
az aks get-credentials \
  --resource-group <resource-group-name> \
  --name <cluster-name>

# Check Defender pods
kubectl get pods -n kube-system | grep microsoft-defender
kubectl get pods -n kube-system | grep defender

# All pods should be in Running state
kubectl get pods -n kube-system -l app=microsoft-defender-publisher
kubectl get pods -n kube-system -l k8s-app=microsoft-defender

If pods are in Pending or CrashLoopBackOff, check logs:

bash
kubectl logs -n kube-system -l app=microsoft-defender-publisher --tail=100
kubectl describe pod -n kube-system <pod-name>  # Check events
4Check for cgroup v2 incompatibility (older Defender versions)

Newer AKS clusters use cgroup v2 (systemd). Older Defender versions expect cgroup v1 file paths:

bash
# Check cgroup version on cluster nodes
kubectl debug node/<node-name> -it --image=ubuntu
# Inside container:
ls /sys/fs/cgroup/memory/memory.usage_in_bytes
# If not found, you're on cgroup v2

Solution: Update AKS to latest patch version:

bash
az aks upgrade \
  --resource-group <resource-group-name> \
  --name <cluster-name> \
  --kubernetes-version <latest-version>

Or disable Defender until your version supports cgroup v2.

5Verify outbound connectivity (private clusters)

For private AKS clusters, ensure outbound access to Defender endpoints:

bash
# From a pod in the cluster, test connectivity:
kubectl run -it debug --image=curlimages/curl --restart=Never -- /bin/sh

# Test required endpoints
curl -I https://dc.services.visualstudio.com  # Application Insights
curl -I https://scadvisorcontent.blob.core.windows.net  # Container images
curl -I https://prod.oms.opinsights.azure.com  # Log Analytics
kubectl delete pod debug

If connections fail, add a NAT Gateway to your cluster subnet:

bash
# Create NAT Gateway (if not already created)
az network public-ip create \
  --resource-group <resource-group-name> \
  --name <pip-name>

az network nat gateway create \
  --resource-group <resource-group-name> \
  --name <nat-gateway-name> \
  --public-ip-address-ids <pip-id>

# Associate with subnet
az network vnet subnet update \
  --resource-group <resource-group-name> \
  --vnet-name <vnet-name> \
  --name <subnet-name> \
  --nat-gateway <nat-gateway-name>
6Fix certificate and TLS errors

If Defender pods report "Failed to register certificate with TLS12":

bash
# Check Defender pod logs
kubectl logs -n kube-system -l app=microsoft-defender-publisher | grep -i certificate

For private clusters with DNS issues:

bash
# Verify DNS resolution from cluster
kubectl run -it debug --image=ubuntu --restart=Never -- /bin/bash
apt-get update && apt-get install -y dnsutils
nslookup dc.services.visualstudio.com
exit
kubectl delete pod debug

If DNS fails, configure custom DNS in cluster subnet or add DNS servers to node VMs:

bash
az aks update \
  --resource-group <resource-group-name> \
  --name <cluster-name> \
  --dns-service-ip <custom-dns-ip>
7Check Log Analytics workspace health

Defender needs a working Log Analytics workspace to function:

bash
# Get cluster's workspace ID
az aks show \
  --resource-group <resource-group-name> \
  --name <cluster-name> \
  --query "addonProfiles.omsagent.config.logAnalyticsWorkspaceResourceId"

# Verify workspace exists and has permissions
az monitor log-analytics workspace show \
  --resource-id <workspace-resource-id>

# Check if workspace was deleted
az monitor log-analytics workspace list \
  --resource-group <resource-group-name>

If workspace was deleted, enable monitoring with a new workspace:

bash
az aks enable-addons \
  --resource-group <resource-group-name> \
  --name <cluster-name> \
  --addons monitoring
8Disable and re-enable Defender

If all else fails, reset Defender by disabling and re-enabling:

bash
# Disable Defender
az aks update \
  --resource-group <resource-group-name> \
  --name <cluster-name> \
  --disable-defender

# Wait 2-3 minutes for cleanup
sleep 180

# Re-enable Defender
az aks update \
  --resource-group <resource-group-name> \
  --name <cluster-name> \
  --enable-defender

# Verify
kubectl get pods -n kube-system | grep defender

This forces a fresh deployment of all Defender components, often resolving lingering pod state issues.

Advanced notes

Defender for Containers is a paid feature—verify your subscription includes the "Microsoft Defender for Cloud" plan. In multi-cluster scenarios, you can enable Defender per-cluster; there is no cluster-wide toggle. For GitOps deployments (ArgoCD, Flux), Defender cannot be managed declaratively; always use Azure CLI or portal. In CI/CD pipelines, the service principal must have "Contributor" role on the resource group to enable Defender. Windows nodes in AKS also require Defender enablement (same commands apply). Defender relies on system-critical pods (microsoft-defender-publisher, microsoft-defender-collector) running in kube-system—do not delete or modify these pods manually. For compliance/audit purposes, monitor Defender alerts in Azure Security Center dashboard under "Container registries" and "Kubernetes clusters". If you need to exclude specific workloads from Defender scanning, use Kubernetes namespace labels and Azure Policy exemptions rather than disabling Defender entirely. Consider using Azure Policy to enforce Defender enablement across all AKS clusters in your organization.

Frequently asked questions

What does "AKS Defender error" mean?
Microsoft Defender for Containers is a cloud-native Kubernetes security service that provides workload protection, vulnerability scanning, and runtime threat detection for Azure Kubernetes Service (AKS) clusters. When an "AKS Defender error" occurs, it indicates the Defender agent or sensor components cannot initialize, authenticate with Azure, or communicate with the Defender for Cloud backend. This error blocks security monitoring and prevents Defender from scanning for vulnerabilities or detecting runtime threats.
How do I fix "AKS Defender error"?
AKS Defender errors occur when Microsoft Defender for Containers fails to deploy, authenticate, or send security data to Azure. Common causes include disabled feature flags, network connectivity issues, cgroup v2 incompatibility, and invalid cluster configurations.
What causes "AKS Defender error"?
Defender feature flag not enabled on Azure subscription (most common) Cluster API version or orchestrator version incompatible with Defender cgroup v2 (systemd) incompatibility—Defender collector expects cgroup v1 file paths
Is the "AKS Defender error" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading