Microsoft Defender for Cloud · Azure Arc-enabled Kubernetes
Azure Arc-enabled Kubernetes clusters should have the Azure Policy extension installed
Written and reviewed by Emnode · Last reviewed
What does the recommendation "Azure Arc-enabled Kubernetes clusters should have the Azure Policy extension installed" check?
Flags any Arc-enabled (connectedClusters) Kubernetes cluster that does not have the Azure Policy extension of type Microsoft.PolicyInsights installed and reporting a healthy state. That extension runs Gatekeeper and the add-on that pulls your policy assignments down to the cluster and evaluates pods, containers and other components against them, so the recommendation is really checking whether the cluster can be governed at all. The control only confirms the extension is present on Arc clusters; it does not look at AKS clusters, where the same capability ships as a managed add-on rather than an Arc extension. It also does not tell you whether any Kubernetes policy initiatives are actually assigned to the cluster, and it does not judge whether the constraints already in place are passing or failing. A cluster can satisfy this control and still have zero guardrails assigned, so treat it as the prerequisite rather than the finish line.
Why does "Azure Arc-enabled Kubernetes clusters should have the Azure Policy extension installed" matter?
Without the extension, Azure Policy has no agent inside the cluster, so every Kubernetes guardrail you assigned in the portal silently does nothing: privileged containers, hostPath mounts, images from untrusted registries and pods running as root all deploy unchecked. You lose both the audit signal and any deny enforcement, which means a compliance dashboard that looks green while the cluster quietly drifts out of policy. Because Arc clusters often run in branch offices, factories or other estates outside the central security team's direct line of sight, that blind spot tends to persist for months. For a regulated workload the gap can turn into a failed audit when an assessor asks to see admission control evidence, or into an unconstrained container becoming a foothold for lateral movement across the node and the wider hybrid fabric.
How do I fix "Azure Arc-enabled Kubernetes clusters should have the Azure Policy extension installed"?
- Register the resource provider once per subscription with 'az provider register --namespace Microsoft.PolicyInsights', which the extension depends on.
- Install the extension on each cluster: 'az k8s-extension create --cluster-type connectedClusters --cluster-name <cluster> --resource-group <rg> --extension-type Microsoft.PolicyInsights --name azurepolicy'. Allow roughly 15 minutes for assignments to sync and evaluate.
- To roll it out at scale, assign the built-in deploy policy by display name so a remediation task installs it on every Arc cluster automatically: pid=$(az policy definition list --query "[?displayName=='Configure Azure Arc enabled Kubernetes clusters to install the Azure Policy extension'].name" -o tsv); az policy assignment create --name deploy-arc-azurepolicy --policy "$pid" --scope <subscription-or-mg-scope> --location <region> --mi-system-assigned --role Contributor --identity-scope <scope>.
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 Arc-enabled Kubernetes clusters should have the Azure Policy extension installed" a false positive?
A short-lived edge or lab cluster you connected to Arc only for inventory, with no intention of governing its workloads, will still flag because the extension is absent. If that cluster genuinely sits outside your policy scope, exempt it with an Azure Policy exemption rather than installing an extension you will not use, and record why so the exception survives the next review.