Skip to main content
emnode
Sign up
Compliance High severity MCSB PV-2

Microsoft Defender for Cloud · Azure Kubernetes Service

Azure Kubernetes Service clusters should have the Azure Policy add-on for Kubernetes installed

Written and reviewed by Emnode · Last reviewed

What does the recommendation "Azure Kubernetes Service clusters should have the Azure Policy add-on for Kubernetes installed" check?

Flags any AKS cluster where the Azure Policy add-on is not installed and enabled. The add-on deploys Gatekeeper v3, the Open Policy Agent admission controller, into the cluster so that Azure Policy definitions can audit and enforce in-cluster configuration as pods are created. The check only confirms the add-on is present and running, set through 'addonProfiles.azurepolicy.enabled'. It does not check which policy definitions or initiatives you have assigned, nor whether any are set to deny rather than audit, so a cluster can pass this control while enforcing nothing.

Why does "Azure Kubernetes Service clusters should have the Azure Policy add-on for Kubernetes installed" matter?

Without the add-on, Azure Policy has no foothold inside the cluster, so platform-level guardrails such as blocking privileged containers, requiring read-only root filesystems, restricting host path mounts or enforcing approved registries simply do not apply. Workloads land exactly as their manifests request them, including the over-permissioned defaults that turn one compromised pod into a node or cluster takeover. A single 'privileged: true' container mounting the host filesystem is enough to read every other tenant's secrets on that node. For a regulated team this is also an audit gap: you cannot evidence that Kubernetes Pod Security Standards or your own baselines are enforced, so the cluster fails compliance review and any incident response has no admission-time control to point to. The add-on is the only supported way to push Azure Policy enforcement into the data plane, so the recommendation is effectively a prerequisite for any Kubernetes governance at all.

How do I fix "Azure Kubernetes Service clusters should have the Azure Policy add-on for Kubernetes installed"?

  1. Register the prerequisite resource provider once per subscription with 'az provider register --namespace Microsoft.PolicyInsights', then install the add-on on the cluster: 'az aks enable-addons --addons azure-policy --name <cluster> --resource-group <rg>'. In Bicep, set 'addonProfiles.azurepolicy.enabled' to true on the Microsoft.ContainerService/managedClusters resource so the cluster is created compliant.
  2. Confirm the components are healthy: the 'azure-policy' pod runs in the kube-system namespace and the gatekeeper controller in gatekeeper-system. Installing the add-on alone enforces nothing, so it must be paired with assigned policy.
  3. Assign a Kubernetes initiative to the cluster scope by exact display name rather than a hardcoded GUID, for example: pid=$(az policy set-definition list --query "[?displayName=='Kubernetes cluster pod security baseline standards for Linux-based workloads'].name" -o tsv); az policy assignment create --name aks-pod-baseline --policy-set-definition "$pid" --scope <cluster-resource-id>. Start in audit mode, review the compliance results, then move selected rules to deny.

Remediation script · bash

RG=prod-rg
CLUSTER=prod-payments
SUB=$(az account show --query id -o tsv)

# 1. Restrict the API server to known networks (office egress + CI runners).
#    Use a private cluster instead where the public endpoint is not needed.
az aks update --resource-group "$RG" --name "$CLUSTER" \
  --api-server-authorized-ip-ranges "203.0.113.0/24,198.51.100.10/32"

# 2. Install the policy engine so guardrails are actually enforced in-cluster.
az provider register --namespace Microsoft.PolicyInsights
az aks enable-addons --resource-group "$RG" --name "$CLUSTER" --addons azure-policy

# For an Azure Arc-connected cluster, install the extension instead of the add-on:
# az k8s-extension create --name azurepolicy --extension-type Microsoft.PolicyInsights \
#   --cluster-type connectedClusters --cluster-name <arc-cluster> --resource-group "$RG"

# 3. Ratchet it shut: audit any future cluster missing the policy add-on.
#    Look the built-in policy up by its EXACT display name (never hardcode the GUID).
pid=$(az policy definition list \
  --query "[?displayName=='Azure Policy Add-on for Kubernetes service (AKS) should be installed and enabled on your clusters'].name" -o tsv)
az policy assignment create --name audit-aks-policy-addon \
  --policy "$pid" --scope "/subscriptions/$SUB"

Full walkthrough (console steps, edge cases and verification) in the lesson Harden the AKS control plane.

Is "Azure Kubernetes Service clusters should have the Azure Policy add-on for Kubernetes installed" a false positive?

Short-lived, fully ephemeral clusters spun up by CI to run integration tests and torn down within the hour can be a deliberate exception: the Gatekeeper webhook adds pod-admission latency and the cluster never hosts real data or traffic. Exempt those clusters explicitly with a documented Azure Policy exemption scoped to them, so the gap is a recorded decision rather than a cluster that was simply never hardened.

Full lesson Harden the AKS control plane Step-by-step remediation with CLI, code and persona-specific context.
Defender for Cloud recommendations ↗ Check your own account →
Part of the learning path Harden Azure workloads

More Azure Kubernetes Service controls