Compliance

Harden the AKS control plane

One capability across Kubernetes: make sure the cluster's front door is not reachable from the whole internet, and that Azure Policy is installed so guardrails are evaluated and enforced inside every cluster rather than only hoped for.

15 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-aks-api-server-authorized-ip-ranges azure-aks-azure-policy-addon-installed azure-arc-k8s-azure-policy-extension azure-container-hosts-configured-securely

Hardening the AKS control plane: the basics

What does a soft Kubernetes control plane actually look like?

A Kubernetes cluster has two halves, and the control plane is the one that matters most for exposure. The API server is the single door through which every deployment, every kubectl command and every operator reaches the cluster, and by default on a public AKS cluster that door answers on a public endpoint that the whole internet can reach. Authentication still stands in front of it, but an internet-reachable API server is constant attack surface: it is probed, it is the target when a credential leaks, and it is the first thing an audit asks about. Defender for Cloud raises 'Kubernetes API server should be configured with restricted access' for exactly this, and the fix is to restrict that endpoint to known networks with authorised IP ranges or to make the cluster private.

The second half of the capability is whether the cluster can be governed at all. Azure Policy for Kubernetes installs an add-on on AKS (or an extension on Azure Arc-enabled clusters) that runs Gatekeeper, the Open Policy Agent admission controller, inside the cluster. Without it, the data-plane guardrails (no privileged containers, no host network, read-only root filesystems, approved registries) cannot be evaluated or enforced, so Defender raises 'Azure Kubernetes Service clusters should have the Azure Policy add-on for Kubernetes installed' and, for Arc clusters, 'Azure Arc-enabled Kubernetes clusters should have the Azure Policy extension installed'. The add-on is the enforcement engine the rest of your Kubernetes policy depends on.

The third leg is the host underneath. Where you run containers on plain Linux VMs rather than managed AKS nodes, Defender for Servers compares each Docker host against the CIS Docker Benchmark and raises 'Container hosts should be configured securely' when the daemon or the host configuration drifts from that baseline. These read as separate findings, but they are one job: shut the front door to known networks, install the engine that enforces guardrails inside the cluster, and keep the hosts beneath your containers configured to a baseline.

In this lesson you will learn how an AKS control plane is exposed, how to find every cluster whose API server is open to the internet or missing the policy engine, and how to lock them down without cutting off the pipelines and operators that legitimately need to reach the cluster. The Controls this lesson covers section lists every Defender for Cloud recommendation in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The dashboard that mined the coins

Some of the earliest large-scale Kubernetes compromises did not start with a clever exploit at all. They started with a control plane or dashboard left reachable from the internet with no access restriction, found by an automated scanner, and quietly turned into a cryptomining farm running on someone else's bill. The Tesla cloud cryptojacking incident in 2018 was exactly this shape: an exposed Kubernetes console with no password. The lesson stuck. Restricting who can even reach the API server, and installing a policy engine that refuses privileged or unapproved workloads, closes the door those campaigns walked through.

Finding control-plane exposure across a subscription

Sam is the platform lead at a scale-up preparing for its first SOC 2 audit. Defender for Cloud shows Kubernetes findings spread across several AKS clusters in two subscriptions that pre-date the team's current guardrails.

Rather than work the findings one by one, Sam starts by listing which clusters still expose the API server to the whole internet and which are missing the Azure Policy add-on, so the production clusters can be separated from throwaway dev ones before anything changes.

List every AKS cluster, showing whether authorised IP ranges are set on the API server and whether the Azure Policy add-on is enabled.

$ az aks list --query "[].{name:name, authIPs:apiServerAccessProfile.authorizedIpRanges, policy:addonProfiles.azurepolicy.enabled}" -o table

Name AuthIPs Policy

--------------- --------- -------

prod-payments False

dev-sandbox False

# prod-payments has an OPEN API server AND no policy engine. Fix it first.

An empty AuthIPs column means the API server answers the whole internet; a False Policy column means no guardrails are enforced inside the cluster. A production cluster with both is the highest-value target in this group.

How Defender for Cloud decides a control plane is exposeddeep dive

The API server finding resolves to the cluster's API server access profile. On a public AKS cluster, when 'authorizedIpRanges' is empty the public endpoint accepts connections from any address, and Defender raises 'Kubernetes API server should be configured with restricted access'. There are two clean ways to clear it: set authorised IP ranges so only your known networks (office egress, CI runners, a jumpbox) can reach the endpoint, or create the cluster as a private cluster so the API server is exposed only on a private endpoint inside your virtual network. Both map to the Microsoft Cloud Security Benchmark control for securing cloud services with network controls.

The policy-engine findings resolve to whether the add-on or extension is installed. The AKS recommendation checks 'addonProfiles.azurepolicy.enabled' on the cluster; the Arc recommendation checks for the 'Microsoft.PolicyInsights' cluster extension on the connected cluster. The add-on deploys Gatekeeper, the Open Policy Agent admission controller, which is what actually evaluates the data-plane policies (no privileged containers, approved registries, read-only root filesystems) against incoming workloads. Without it those policies have nowhere to run, which is why this control underpins the whole Kubernetes data-plane group.

The host finding sits in a different plane entirely. 'Container hosts should be configured securely' is a Defender for Servers recommendation that compares Linux machines running Docker against the CIS Docker Benchmark. It applies to Docker on your own virtual machines, not to AKS-managed nodes, where Microsoft operates and hardens the node image for you. Defender for Cloud evaluates all of these against the benchmark on a periodic cycle, so a fix does not flip the recommendation to Healthy instantly: the control-plane change is immediate, but the posture catches up on the next assessment, which matters when you are gathering audit evidence against a deadline.

What is the impact of leaving the control plane exposed?

The direct impact is a foothold on the most powerful surface you operate. An internet-reachable API server is probed continuously and is the target the moment a kubeconfig, service-account token or CI credential leaks. Once an attacker can talk to the control plane, the blast radius is the whole cluster: every secret it holds, every workload it schedules, and the cloud identities those workloads carry. The earliest mass Kubernetes incidents were not exotic exploits, they were open endpoints turned into cryptomining or data theft.

The second-order impact is that without the policy engine, the guardrails everyone assumes are enforced are not. A cluster with no Azure Policy add-on will happily schedule a privileged container, a pod on the host network, or an image from an unknown registry, because nothing is standing at admission to refuse it. Installing the engine shrinks the runtime to the workloads you actually allow, which are the ones you can reason about and defend.

On the compliance side, every modern framework, ISO 27001, SOC 2, the CIS Kubernetes and Azure benchmarks, PCI DSS and the UK and EU data-protection regimes, expects evidence that administrative interfaces are not openly reachable and that workload controls are enforced. A passing set of Kubernetes recommendations across every cluster is the cheapest and most defensible artefact you can hand an auditor.

How do you lock the control plane down safely?

Work the capability as one loop rather than chasing individual findings. The order matters: know which networks legitimately need to reach each API server before you start restricting it, so you do not lock your own pipelines out of the cluster.

1. Inventory every cluster by exposure

List every AKS and Arc-connected cluster, showing whether the API server has authorised IP ranges (or is private) and whether the Azure Policy add-on or extension is installed. Treat this inventory as the source of truth, not the Defender finding count, because one cluster can trigger several recommendations at once.

2. Decide restricted-IP versus fully private per cluster

For each cluster, decide the right end state. Authorised IP ranges keep the public endpoint but limit it to your office egress, CI runners and any jumpbox, and are a one-command change. A fully private cluster removes the public endpoint entirely but means pipelines and operators need a path into the virtual network, so plan that networking change before you flip it. Production and customer-facing clusters justify the stronger option.

3. Install the policy engine on every cluster

Register the Microsoft.PolicyInsights provider, then enable the Azure Policy add-on on each AKS cluster and the equivalent Microsoft.PolicyInsights extension on each Arc-connected cluster. This deploys Gatekeeper so the data-plane guardrails (no privileged containers, approved registries, read-only root filesystems) can actually be evaluated and enforced. Start the assigned policies in audit, then move the ones you trust to deny.

4. Ratchet it shut with Azure Policy, and baseline the hosts

Assign the built-in audit policies so any new cluster missing authorised IP ranges or the policy add-on is flagged automatically, and bring any self-managed Docker hosts up to the CIS Docker Benchmark that 'Container hosts should be configured securely' checks. The backstop is what turns a one-off cleanup into a guarantee that the next cluster is built safely.

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"

Quick quiz

Question 1 of 5

Defender for Cloud shows Kubernetes findings across API server access and a missing Azure Policy add-on on several clusters. What is the most efficient way to think about them?

Keep learning

Go deeper on how an AKS control plane expresses reachability and governance across the settings in this capability.

You can now treat the AKS control plane as one capability rather than a scatter of findings: inventory which clusters are reachable too widely or missing the policy engine, decide restricted-IP versus private per cluster, install Azure Policy so guardrails are enforced inside every cluster, and ratchet the estate shut with an audit policy plus a CIS baseline on any self-managed hosts. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Hardening the AKS control plane: the cost and risk view

A near-zero-cost capability that removes the widest Kubernetes attack surface and unlocks every downstream guardrail

Almost everything in this group is free in Azure spend. Restricting the API server to authorised IP ranges, installing the Azure Policy add-on, and bringing a Docker host up to the CIS baseline do not change the bill. The Azure Policy add-on runs as a small set of pods on nodes you already pay for. The only real cost sits in two places: converting a public cluster to a private cluster, which can mean adding a jumpbox or self-hosted CI agent inside the network so pipelines can still reach the API server, and the Defender plans themselves (Defender for Containers, Defender for Servers) that surface these findings in the first place.

Frame the API server finding by what the cluster runs. A production cluster serving customer traffic with an internet-reachable API server is a far higher expected loss than a throwaway dev cluster, yet both surface as one red item. Map each failing cluster to the workload behind it and prioritise the production and customer-facing clusters first.

The arithmetic is one-sided. The remediation is engineering time plus a bounded networking change for the clusters that go private. The downside of leaving it is the documented cost of a Kubernetes compromise: a foothold on the control plane can mean exfiltrated secrets, hijacked compute for cryptomining, and a breach that triggers regulatory notification, forensics and legal fees.

This lesson is for the finance partner who sees a cluster of Kubernetes findings on the security report and wants to know what the right response is and what it costs. It covers why most of these controls are free to fix, which exceptions (private clusters, Defender plans) carry a real cost, and how to turn a list of red findings into a risk-ordered remediation plan.

Fun fact

The dashboard that mined the coins

How a finance partner frames the Kubernetes decision

Sam is the finance partner supporting the platform team's SOC 2 push. The security report lands with several Kubernetes findings across a handful of clusters in two older subscriptions. The instinct is not to wave through a blanket remediation budget; it is to ask what is actually behind each red finding. Restricting the API server to authorised IP ranges or installing the Azure Policy add-on changes nothing on the Azure bill, so the spend question is narrow: only the clusters that need to become fully private carry a real cost, because pipelines and operators then need a path into the network, and the Defender for Containers and Defender for Servers plans that surface these findings carry their own per-resource charge.

Sam asks the team to map each failing cluster to the workload behind it. One is the production payments cluster with an open API server and no policy engine, one is a customer-facing API cluster missing only the add-on, and the rest are dev sandboxes with secure transfer to the control plane simply never tightened. The list is reframed on the risk register: the payments cluster is a high expected-loss item to close this week at near-zero Azure cost, the customer-facing cluster is a same-day add-on install, and the sandboxes are low-value drift to sweep up. The finance pack reads: 'Almost every finding closes at no incremental spend; only the clusters we move to private need a bounded networking change; the constraint is engineering time, not budget.'

Why control-plane exposure belongs on the risk register

The cost model here is asymmetric in a way that is rare for security work. Restricting the API server and installing the policy engine cost nothing in Azure spend for the great majority of clusters, and leaving them open creates an unbounded tail risk. Each failing cluster is one where a leaked credential or a probing scanner could reach the control plane, and while the probability per cluster is low, the probability across every cluster over years is not.

The documented cost of a Kubernetes compromise includes hijacked compute billed straight to you, exfiltrated secrets that often unlock further systems, mandatory breach notification within tight regulatory windows, and forensics and legal fees that routinely run into six and seven figures. Against that, the remediation is engineering time plus a bounded networking change for the clusters that go private and the Defender plan charges. The finance role is to attach expected loss to each failing cluster so the work is prioritised by risk, not by the order the report lists it.

What finance can do about the Kubernetes gap

Finance cannot restrict an API server or install an add-on, but it owns the framing that turns a scatter of red findings into a risk-ordered plan with almost no incremental Azure spend and a clearly bounded set of exceptions. Three levers.

1. Separate the zero-cost closures from the bounded exceptions

Make explicit that the overwhelming majority of Kubernetes control-plane findings cost nothing in Azure spend to fix: restricting the API server to authorised IP ranges or installing the Azure Policy add-on does not move the bill. The only real cost sits in the clusters that need to become fully private, which require a jumpbox or self-hosted CI path into the network, and the Defender for Containers and Defender for Servers plans that surface the findings. Budget those as discrete lines and treat everything else as engineering time, so nobody can claim the whole capability is a spending decision.

2. Order the work by expected loss, not by finding count

A production payments cluster with an open API server and an idle dev sandbox both show up as a single red finding, but their expected loss differs by orders of magnitude. Ask the team to map each failing cluster to the workload behind it and prioritise the production and customer-facing clusters first. The metric that belongs on the cost-and-security review is the count of Kubernetes findings weighted by the sensitivity of what the cluster runs, not the raw total.

3. Require documented exceptions for any cluster left openly reachable

If any cluster has to keep a broadly reachable API server for a genuine reason, that exception should carry a recorded, finance-visible justification and a compensating control such as strong workload identity and audit logging. The distinction between 'we reviewed this and accepted the residual risk deliberately' and 'we never noticed it was open' is exactly what makes the posture defensible at audit and in the aftermath of any incident.

Quick quiz

Question 1 of 5

A security report shows several Kubernetes control-plane findings. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on how an AKS control plane expresses reachability and governance across the settings in this capability.

You have finished the finance view of hardening the AKS control plane. You know the cost model is one-sided: restricting the API server and installing the policy add-on is free in Azure spend, only the clusters that go private and the Defender plans carry a bounded cost, and the downside of leaving exposure open is the documented and unbounded cost of a Kubernetes compromise. Next time a cluster of Kubernetes findings lands, you will order them by expected loss, ring-fence the real exceptions, and ask for them on the record rather than asking how much remediation will cost.

Back to the library

Hardening the AKS control plane: the headline

Whether the cluster that runs the product can be reached, and governed, only the way you intend

Kubernetes runs an increasing share of what the business ships, and its control plane is the highest-value single target in the estate. An API server reachable from the whole internet is one leaked credential away from an attacker on the inside, and a cluster with no policy engine installed is one where the guardrails everyone assumes are on simply are not.

The leadership question is not 'do we use Kubernetes safely?' It is 'if a cluster credential leaks tomorrow, who can reach the control plane, and are our container guardrails actually enforced or merely documented?' The defensible end state is that every cluster's API server is restricted to known networks or private, the Azure Policy engine is installed on every cluster, and the hosts beneath self-managed containers meet a baseline.

This is not a budget decision. Hardening the control plane is essentially free in Azure terms beyond the Defender plans you are likely already paying for. It is a governance decision about whether the most important runtime in the estate is locked down by design or only by everyone remembering to set the right flags.

A short read for the leader who needs to know what an exposed Kubernetes control plane reveals, why locking it down is a governance decision rather than a budget one, and what a defensible end state looks like across every cluster in the estate.

Fun fact

The dashboard that mined the coins

What it looks like when control-plane exposure is prevented by design, not luck

After reading about a competitor whose Kubernetes cluster was hijacked for cryptomining through an exposed control plane, the CEO asked the obvious question at the next review: could that happen to us? The honest answer at the time was that it depended on whether anyone had remembered to restrict the API server and install the policy engine when each cluster was built, because those choices were governed by habit rather than policy.

The team's response was to stop treating Kubernetes as a per-cluster cleanup and start treating it as a guardrail. They listed every cluster whose API server was open to the internet, restricted each to the office and CI ranges or moved it to a private cluster, installed the Azure Policy add-on on every AKS cluster and the equivalent extension on the Arc-connected ones, and then set an Azure Policy initiative that audits any new cluster missing those protections. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'no, the platform enforces it on every cluster, and the policy engine refuses privileged and unapproved workloads.' That shift, from relying on everyone remembering to set the right flags to making the unsafe state structurally hard, is the one-line confidence signal this capability delivers, and beyond the Defender plans it costs almost nothing in Azure spend.

Why this is a board-level risk

Kubernetes increasingly runs the product, and several of the most public cloud compromises traced back to the same root cause: a control plane reachable by more of the internet than intended, or a cluster with no enforcement standing between an attacker and a privileged workload. Locking the control plane down is the capability that makes those root causes structurally difficult, and an Azure Policy backstop across every cluster makes them close to impossible.

The cost of getting this wrong is large and well documented, while the cost of fixing it is essentially engineering time plus the Defender plans you are likely already running. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve.

The leadership move on the control plane

The executive handle is not to approve each cluster fix individually; it is to require that every cluster's API server is restricted or private, that the policy engine is installed everywhere, and that the small number of exceptions are documented, on the record.

1. Set a deadline to reach a backstopped end state

Ask for a date by which every cluster is inventoried, the production clusters are private or IP-restricted, the Azure Policy add-on is installed on every cluster, and an Azure Policy initiative audits any new cluster missing those protections. A backstop that flags every non-compliant cluster automatically is the difference between checking nothing is exposed today and catching the next unsafe cluster the moment it is built.

2. Ask for proof, not assurance

The proof that this is closed is not a verbal 'we are on it.' It is a passing set of Kubernetes recommendations across every cluster plus evidence that the audit policies are assigned. Because Defender for Cloud assesses on a periodic cycle, ask for that evidence with a little lead time before any audit deadline rather than the morning of.

3. Treat any openly reachable cluster as a named, owned exception

If a cluster must keep a broadly reachable control plane, that is a deliberate, documented decision with an owner and compensating controls, not an accident left open. The goal is not zero Kubernetes clusters; it is zero clusters whose control plane is reachable or ungoverned by oversight rather than by intent.

Quick quiz

Question 1 of 5

At a board review you ask whether a Kubernetes hijacking like a competitor's could happen to your estate. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how an AKS control plane expresses reachability and governance across the settings in this capability.

Two takeaways. Control-plane exposure is the rare control where the risk of inaction is severe and the cost of action is essentially engineering time plus Defender plans you likely already run, so it is the trade you should be quickest to approve. And the defensible end state is not 'we checked and nothing is open today'; it is every cluster restricted or private with the Azure Policy engine installed and an audit policy that catches the next unsafe cluster the moment it is built, with the few deliberate exceptions documented and owned.

Back to the library

Controls this lesson covers

One capability, many Microsoft Defender for Cloud recommendations. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

Azure Arc-enabled Kubernetes

Azure Arc-enabled Kubernetes clusters should have the Azure Policy extension installed High Without the Azure Policy extension you cannot audit or enforce security guardrails across Arc-connected clusters.

Azure Kubernetes Service

Containers

Vulnerabilities in container security configurations should be remediated High Misconfigured Docker hosts give attackers an easy path to break out of containers and compromise the underlying node.

Part of the learning path Harden Azure workloads

Harden the AKS control plane

Hardening the AKS control plane: the basics

The dashboard that mined the coins

Finding control-plane exposure across a subscription

How Defender for Cloud decides a control plane is exposeddeep dive

What is the impact of leaving the control plane exposed?

How do you lock the control plane down safely?

1. Inventory every cluster by exposure

2. Decide restricted-IP versus fully private per cluster

3. Install the policy engine on every cluster

4. Ratchet it shut with Azure Policy, and baseline the hosts

Quick quiz

Keep learning

Hardening the AKS control plane: the cost and risk view

The dashboard that mined the coins

How a finance partner frames the Kubernetes decision

Why control-plane exposure belongs on the risk register

What finance can do about the Kubernetes gap

1. Separate the zero-cost closures from the bounded exceptions

2. Order the work by expected loss, not by finding count

3. Require documented exceptions for any cluster left openly reachable

Quick quiz

Keep learning

Hardening the AKS control plane: the headline

The dashboard that mined the coins

What it looks like when control-plane exposure is prevented by design, not luck

Why this is a board-level risk

The leadership move on the control plane

1. Set a deadline to reach a backstopped end state

2. Ask for proof, not assurance

3. Treat any openly reachable cluster as a named, owned exception

Quick quiz

Keep learning

Controls this lesson covers

Azure Arc-enabled Kubernetes

Azure Kubernetes Service

Containers

Related compliance lessons