Compliance

Enforce AKS pod security

One capability across every workload in an AKS cluster: make sure no pod runs more privileged than it needs, no container pulls from a registry you do not trust, and no deployment can quietly grant itself root, host access or a writable filesystem, unless you genuinely intend it.

15 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-aks-avoid-default-namespace azure-aks-avoid-privilege-escalation azure-aks-avoid-privileged-containers azure-aks-avoid-running-as-root azure-aks-avoid-sensitive-host-namespaces azure-aks-container-cpu-memory-limits azure-aks-disable-automount-api-credentials azure-aks-immutable-root-filesystem azure-aks-least-privileged-linux-capabilities azure-aks-trusted-registries-only

Enforcing pod security: the basics

What does an over-privileged AKS workload actually look like?

An Azure Kubernetes Service cluster runs whatever pod specifications your teams hand it, and a pod can ask for far more than it needs in a handful of distinct ways. A container can run privileged, which gives it every root capability of the underlying node. It can run as the root user, so a compromise inside the container is root on the host. It can allow privilege escalation, share the host's process or IPC namespace, keep a writable root filesystem, or hold Linux capabilities it never uses. It can pull an image from any registry on the internet rather than a trusted one. It can sit in the default namespace, automount the cluster's API credentials, or run with no CPU or memory limit at all. Each of these is its own Microsoft Defender for Cloud recommendation, but the underlying risk is the same: a workload that can reach further into the node, the cluster or the supply chain than you meant it to.

Defender for Cloud turns each of these into its own data plane hardening recommendation, which is why one busy cluster can fail eight or ten container checks at once. 'Privileged containers should be avoided', 'Running containers as root user should be avoided' and 'Container with privilege escalation should be avoided' close the widest doors into the node. They pair with 'Immutable (read-only) root filesystem should be enforced for containers', 'Least privileged Linux capabilities should be enforced for containers' and 'Containers sharing sensitive host namespaces should be avoided' to shrink what a compromised container can do, with 'Container images should be deployed from trusted registries only' to control what runs in the first place, and with 'Kubernetes clusters should disable automounting API credentials', 'Kubernetes clusters should not use the default namespace' and 'Container CPU and memory limits should be enforced' to tidy up the blast radius. They read as ten separate problems on the report, but they are one job: stop workloads being more privileged than they need to be.

Most of this is drift, not intent. A base image that defaults to root, a Helm chart copied from a sample that left privileged set to true, a deployment in the default namespace because nobody created one, a container with no resource limits because the author never added them. All of it is enforced through a single mechanism: the Azure Policy add-on for AKS, which installs OPA Gatekeeper as an admission controller and evaluates every pod against the policies you assign. The work is to turn that add-on on, see which workloads are over-privileged, fix the specifications, and then set the policies to deny so the cluster refuses the next over-privileged pod at admission.

In this lesson you will learn how an AKS workload expresses privilege and trust, how the Azure Policy add-on and Gatekeeper evaluate every pod, how to find every over-privileged workload in a cluster, and how to lock the cluster down without blocking the deployments you depend on. The Controls this lesson covers section lists every Defender for Cloud data plane recommendation in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The container that was the whole host

A privileged container is not really sandboxed at all. With the privileged flag set, the container shares the node's kernel with almost no restrictions, so escaping it to the host can be as simple as mounting the host's filesystem from inside the pod. Security researchers have demonstrated full node takeover from a single privileged pod in seconds, which is exactly why the Kubernetes Pod Security Standards put 'no privileged containers', 'no running as root' and 'read-only root filesystem' at the centre of the restricted profile. AKS removed the old PodSecurityPolicy feature entirely, so on a modern cluster the Azure Policy add-on with Gatekeeper is the supported way to enforce these standards.

Finding over-privileged workloads across a cluster

Priya is the platform lead at a scale-up preparing for its first SOC 2 audit. Defender for Cloud shows container findings spread across several deployments in a cluster that started as a quick proof of concept and grew into production.

Rather than work the findings one by one, Priya first confirms the Azure Policy add-on is installed so Gatekeeper is actually evaluating pods, then lists which workloads still run privileged or as root, so the genuine exceptions can be separated from drift before any policy is set to deny.

First confirm the Azure Policy add-on is enabled, then ask the cluster which running pods are privileged or root. These are the widest-open doors into the node.

$ az aks show -g rg-prod -n aks-prod --query addonProfiles.azurepolicy.enabled -o tsv && kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{" priv="}{.spec.containers[*].securityContext.privileged}{" user="}{.spec.containers[*].securityContext.runAsUser}{"\n"}{end}'

true

default/legacy-agent priv=true user=0

payments/api-7d9c priv=<none> user=1000

# legacy-agent runs privileged, as root, in the default namespace. Fix it first.

The add-on is on (true), so Gatekeeper is auditing. A pod that is privileged AND root AND in the default namespace trips several recommendations at once and is the highest-value target in this group.

How Defender for Cloud decides an AKS workload is over-privilegeddeep dive

These recommendations are not evaluated by reading the AKS resource in Azure Resource Manager. They are evaluated inside the cluster by the Azure Policy add-on, which extends OPA Gatekeeper v3, an admission controller webhook. When you assign a Kubernetes policy, Azure Policy translates it into a Gatekeeper constraint template and constraint, and Gatekeeper checks every pod admission request against it in real time, as well as scanning the whole cluster for existing violations every 15 minutes. Almost all of these checks resolve to a field in the pod's securityContext: 'privileged' true, 'runAsUser' 0 or 'runAsNonRoot' false, 'allowPrivilegeEscalation' true, 'readOnlyRootFilesystem' false, an over-broad capabilities list, or hostPID and hostIPC set. The trusted-registries and resource-limits checks read the container image reference and the resources block instead.

Because this runs in-cluster, two things follow. First, the add-on must be installed for any of these recommendations to report at all: a cluster without it shows the parent recommendation 'Azure Kubernetes Service clusters should have the Azure Policy add-on for Kubernetes installed' and none of the data plane findings underneath. Second, after you remediate, the posture catches up on the next assessment cycle, which can take up to 30 minutes, rather than flipping to Healthy the instant you redeploy a pod.

Every Kubernetes policy supports the effects audit, deny and disabled. By default these policies run in audit: Gatekeeper records violations and reports them to Defender for Cloud but admits the pod anyway. Setting the effect to deny is what turns the report into enforcement, so Gatekeeper rejects a non-compliant admission request outright. Two details matter when you switch to deny. A pod that already exists keeps running, but the moment it is rescheduled onto another node Gatekeeper blocks its recreation, so enforcement bites on the next rollout. And system namespaces such as kube-system, gatekeeper-system and azure-arc should be excluded from evaluation, which is why a couple of policies require a namespace-exclusion parameter and others, like trusted registries and resource limits, require you to supply the list of allowed registries or the limit values before they can report anything but unhealthy.

What is the impact of leaving AKS workloads over-privileged?

The direct impact is container escape. A privileged or root container shares the node's kernel with almost no isolation, so a single remote-code-execution bug in that workload becomes root on the host, and from the host an attacker can read the secrets, identities and traffic of every other pod on that node. Allowing privilege escalation, sharing the host process or IPC namespace, or keeping a writable root filesystem each widen that path. The overwhelming majority of these are accidents: a base image that runs as root, a sample chart that set privileged, a capability nobody dropped.

The second-order impact is supply chain and blast radius. 'Container images should be deployed from trusted registries only' is the control that decides what is allowed to run at all, so without it a compromised or typosquatted public image can land straight into production. 'Kubernetes clusters should disable automounting API credentials' stops a compromised pod from using the cluster's own API to spread, the default-namespace control keeps workloads from colliding in a space with no boundaries, and resource limits stop one workload starving the rest of a node in a denial-of-service. Together they shrink what a single compromise can reach.

On the compliance side, every modern framework, ISO 27001, SOC 2, the CIS Azure Kubernetes Service Benchmark, PCI DSS and the UK and EU data-protection regimes, expects evidence that container workloads run with least privilege and from controlled sources. A passing set of data plane hardening recommendations across every cluster, backed by policies in deny mode, is the cheapest and most defensible artefact you can hand an auditor.

How do you lock an AKS cluster down safely?

Work the capability as one loop rather than chasing individual findings. The order matters: get the add-on auditing and see every violation before you set anything to deny, so you do not block a deployment your business depends on.

1. Install the add-on so Gatekeeper can audit

Register the Microsoft.PolicyInsights resource provider and enable the azure-policy add-on on the cluster. Until it is installed, Gatekeeper is not running and none of the data plane recommendations report. Confirm the azure-policy and gatekeeper pods are running before you go further.

2. Assign the pod security standards in audit mode

Assign the built-in initiative 'Kubernetes cluster pod security baseline standards for Linux-based workloads', or the stricter restricted standards if your workloads can meet them, with effect audit. Exclude kube-system, gatekeeper-system and azure-arc from evaluation. Audit mode reports every violation without blocking anything, so you get a true picture before enforcing.

3. Fix the workloads, highest blast radius first

In each pod specification, set privileged false, runAsNonRoot true with a non-root runAsUser, allowPrivilegeEscalation false and readOnlyRootFilesystem true, drop all Linux capabilities and add back only what is needed, and remove hostPID and hostIPC. Add CPU and memory limits, move workloads out of the default namespace, and point image references at your trusted registry. Prioritise the workloads that are internet-facing or hold data over internal batch jobs.

4. Switch to deny so the cluster refuses the next bad pod

Once audit shows only the exceptions you have decided to keep, set the policy effect to deny. Configure 'Container images should be deployed from trusted registries only' with your allowed registry list and the resource-limit policy with your maximum values. Now Gatekeeper rejects a privileged, root or untrusted-image pod at admission, and each documented exception is an explicit, owned decision rather than drift.

# 1. Turn on the Azure Policy add-on so Gatekeeper starts auditing the cluster.
az provider register --namespace Microsoft.PolicyInsights
az aks enable-addons --addons azure-policy \
  --resource-group rg-prod --name aks-prod
# Confirm the policy and gatekeeper pods are running.
kubectl get pods -n kube-system -l app=azure-policy
kubectl get pods -n gatekeeper-system

# 2. Assign the built-in pod security baseline initiative in AUDIT first.
# Look the initiative up by its exact display name, never paste a GUID.
SCOPE=$(az aks show -g rg-prod -n aks-prod --query id -o tsv)
SETID=$(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 "$SETID" \
  --scope "$SCOPE" \
  --params '{"effect":{"value":"audit"},"excludedNamespaces":{"value":["kube-system","gatekeeper-system","azure-arc"]}}'

# 3. Fix the workloads (in each pod spec, securityContext):
#   privileged: false | runAsNonRoot: true | runAsUser: 1000
#   allowPrivilegeEscalation: false | readOnlyRootFilesystem: true
#   capabilities: { drop: ["ALL"] }  and add back only what is needed.

# 4. Once audit is clean except for named exceptions, ENFORCE.
az policy assignment update --name aks-pod-baseline \
  --set parameters.effect.value=deny

Quick quiz

Question 1 of 5

Defender for Cloud shows findings across privileged containers, running as root, trusted registries and resource limits on one AKS cluster. What is the most efficient way to think about them?

Keep learning

Go deeper on how the Azure Policy add-on, Gatekeeper and the pod security standards enforce the settings in this capability.

You can now treat AKS pod security as one capability rather than a scatter of findings: install the Azure Policy add-on so Gatekeeper audits every pod, assign the pod security standards, fix the over-privileged workloads highest blast radius first, then switch the policies to deny so the cluster refuses the next privileged, root or untrusted-image pod at admission. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Enforcing pod security: the cost and risk view

A near-zero-cost capability that removes the largest class of AKS workload-compromise liability

Tightening pod security is almost entirely engineering time, not Azure spend. The Azure Policy add-on for AKS is free, Gatekeeper runs in the cluster you already pay for, and changing a pod specification to drop privilege, set a non-root user or add resource limits does not change your bill. The only place real money appears is indirect and usually downward: 'Container CPU and memory limits should be enforced' tends to improve bin-packing and stop a single noisy workload starving a node, which can let you run the same load on fewer or smaller nodes.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A privileged container running a public-facing service carries a far higher expected loss than a resource-limit finding on an internal batch job, yet both surface as a single red item. Map the failures to what the workload does and what it can reach, and prioritise by blast radius, not by recommendation count.

The insurance arithmetic is one-sided. The remediation is engineering time spent adjusting specifications and trusted-registry lists, plus a short audit period before you switch policies to deny so you do not block a live deployment. The downside of leaving it is the documented cost of a container-escape or supply-chain incident: a compromised pod that reaches the node, then the cluster, then the data behind it, with the forensics, notification and reputational cost that follows.

This lesson is for the finance partner who sees a cluster of container findings on the security report and wants to know what the right response is and what it costs. It covers why almost all of these controls are free to fix, why the resource-limit one can actually reduce spend, and how to turn a list of red findings into a risk-ordered remediation plan.

Fun fact

The container that was the whole host

How a finance partner frames the pod-security decision

Priya is the finance partner supporting the platform team's SOC 2 push. The security report lands with nine container findings spread across one production cluster. The instinct is not to wave through a remediation budget; it is to ask what is actually behind each red finding. The Azure Policy add-on is free, Gatekeeper runs on nodes the business already pays for, and editing a pod specification to drop privilege or set a non-root user changes nothing on the Azure bill, so the spend question is narrow and points the right way: the only finding with a real cost signal, 'Container CPU and memory limits should be enforced', tends to reduce spend by improving how tightly workloads pack onto nodes.

Priya asks the team to map each failing workload to what it does and what it can reach. One privileged container is a legacy monitoring agent that genuinely needs host access and will become a named exception in its own namespace, two are application pods that default to root only because their base image does, and the rest are missing resource limits. The list is reframed on the risk register: the application pods that run as root are high expected-loss items to fix today at zero Azure cost, the legacy agent is a documented, owned exception, and the resource-limit findings are a tidy-up that may shave node spend. The finance pack reads: 'Eight findings close at no incremental spend, one is a documented exception, and the only cost signal here points downward through better node packing, not upward.'

Why over-privileged workloads belong on the risk register

The cost model here is asymmetric in a way that is rare for security work. The Azure Policy add-on is free, Gatekeeper runs on capacity you already pay for, and fixing a pod specification is engineering time, so locking the cluster down costs nothing in Azure spend for the great majority of findings. One of them, enforcing CPU and memory limits, usually reduces spend by letting workloads pack more tightly onto nodes. Against that, leaving privilege open creates an unbounded tail risk: each over-privileged workload is a pod where a future compromise reaches the node and beyond.

The documented cost of a container-escape or malicious-image incident includes mandatory breach notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, and customer churn. Against that, the remediation is engineering time plus a short audit period before switching policies to deny. The finance role is to attach expected loss to each failing workload, weighted by what it does and what it can reach, so the work is prioritised by blast radius, not by the order the report lists it.

What finance can do about the pod-security gap

Finance cannot edit a pod specification, but it owns the framing that turns a scatter of red findings into a risk-ordered plan with no incremental Azure spend and a clearly bounded set of exceptions. Three levers.

1. Make clear this is engineering time, not spend

State plainly that the Azure Policy add-on is free, Gatekeeper runs on nodes the business already pays for, and fixing pod specifications does not move the bill. The one finding with a cost signal, enforcing CPU and memory limits, tends to reduce node spend by improving bin-packing. Budget the whole capability as engineering time so nobody can claim it is a spending decision held up by a budget.

2. Order the work by blast radius, not by finding count

A privileged, internet-facing container and a missing resource limit on an internal batch job both show up as a single red finding, but their expected loss differs by orders of magnitude. Ask the team to map each failing workload to what it does and what it can reach, and prioritise the high-blast-radius workloads first. The metric that belongs on the cost-and-security review is the count of container findings weighted by the exposure of the workload, not the raw total.

3. Require documented exceptions before deny is switched on

Some workloads genuinely need elevated rights: a node-level monitoring agent, a CSI driver. Each should carry a recorded, finance-visible reason, an owner and the narrow namespace it is allowed in, before the policies move to deny. The distinction between 'we reviewed this agent and granted it host access deliberately' and 'we never noticed this pod was privileged' 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 nine AKS container findings. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on how the Azure Policy add-on, Gatekeeper and the pod security standards enforce the settings in this capability.

You have finished the finance view of enforcing pod security. You know the cost model is one-sided: the add-on is free, fixing specifications is engineering time, and the one finding with a cost signal, enforcing resource limits, points downward through better node packing. The downside of leaving workloads over-privileged is the documented and unbounded cost of a container escape. Next time a cluster of container findings lands, you will order them by blast radius, ring-fence the genuine elevated workloads as owned exceptions, and ask for them on the record rather than asking how much remediation will cost.

Back to the library

Enforcing pod security: the headline

Whether a single compromised container in the cluster can reach the host and everything else on it

Containers share the kernel of the node they run on. A privileged or root container that is compromised is not contained to itself, it has a direct path to the host and, from there, to every other workload on that node. The report shows this as a scatter of separate findings, but it is one question: how far can one bad container get?

The leadership question is not 'are we compliant today?' It is 'if a deployment ships an over-privileged pod tomorrow, will the cluster accept it?' The defensible end state is that the Azure Policy add-on is installed, the pod security policies are set to deny, and the cluster refuses privileged, root and untrusted-image workloads at admission, with the handful of genuine exceptions named and owned.

None of this is a cost decision. The add-on is free and the fixes are engineering time. It is a governance decision about whether a container escape is prevented by design or only by every team remembering to write a careful pod specification.

A short read for the leader who needs to know what an over-privileged container can reach, why locking the cluster down is a governance decision rather than a budget one, and what a defensible end state looks like across every AKS cluster in the estate.

Fun fact

The container that was the whole host

What it looks like when a container escape is prevented by design, not luck

After a peer company disclosed a breach that started with a single compromised container reaching the underlying node, the CEO asked the obvious question at the next review: could one bad pod do that to us? The honest answer at the time was that it depended on what each team had written in their pod specifications, because privilege, root and image trust across the cluster were governed by convention rather than by anything that would stop a careless deployment.

The team's response was to stop treating container findings as a per-deployment cleanup and start treating them as a guardrail. They confirmed the Azure Policy add-on was installed so Gatekeeper was evaluating every pod, listed every workload that ran privileged, as root or from an untrusted registry, fixed the specifications, named the one legacy agent that genuinely needed host access as an owned exception, and then switched the pod security policies from audit to deny so the cluster itself refuses a privileged or untrusted-image pod at admission. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'no, the cluster rejects it at the door, and the one exception is documented.' That shift, from relying on every team writing a careful specification to making the over-privileged pod structurally impossible to admit, is the one-line confidence signal this capability delivers, and the add-on that enforces it is free.

Why this is a board-level risk

Many of the most damaging cloud breaches involving containers came back to the same root cause: a workload that could reach further than it needed to, a privileged pod, a root container or an image pulled from somewhere nobody vetted, was, because of an internal change. Enforcing pod security is the capability that makes that root cause structurally difficult, and Gatekeeper in deny mode makes admitting an over-privileged pod close to impossible.

The cost of getting this wrong is large and well documented, while the cost of fixing it is essentially engineering time on a free add-on. 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 pod security

The executive handle is not to approve each fix individually; it is to require that the cluster refuses an over-privileged pod by policy and that the small number of genuine exceptions are named, owned and namespace-scoped, on the record.

1. Set a deadline to reach an enforced end state

Ask for a date by which the Azure Policy add-on is installed on every cluster, the pod security standards are assigned, the workloads are fixed, and the policies are set to deny so no new privileged, root or untrusted-image pod can be admitted. A deny policy that no individual deployment can override is the difference between checking nothing is over-privileged today and guaranteeing nothing over-privileged can be admitted tomorrow.

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 data plane hardening recommendations across every cluster plus evidence the policies are assigned in deny mode. Because Defender for Cloud assesses on a periodic cycle and the add-on scans every 15 minutes, ask for that evidence with a little lead time before any audit deadline rather than the morning of.

3. Treat the genuinely elevated workloads as named, owned exceptions

A small number of workloads, a monitoring agent, a storage driver, genuinely need elevated rights, and that is fine. The leadership requirement is that each is a deliberate, documented decision with an owner and a narrow namespace, not an accident left privileged. The goal is not zero elevated workloads; it is zero unintended ones.

Quick quiz

Question 1 of 5

At a board review you ask whether a single compromised container could reach the host like a competitor's did. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how the Azure Policy add-on, Gatekeeper and the pod security standards enforce the settings in this capability.

Two takeaways. Pod security is the rare control where the risk of inaction is severe, a single container reaching the host, and the cost of action is essentially engineering time on a free add-on, so it is the trade you should be quickest to approve. And the defensible end state is not 'we checked the specifications and nothing is privileged today'; it is the Azure Policy add-on with policies in deny mode, so the cluster refuses an over-privileged pod at admission, with the few genuinely elevated workloads documented, owned and namespace-scoped.

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 Kubernetes Service

Part of the learning path Harden Azure workloads

Enforce AKS pod security

Enforcing pod security: the basics

The container that was the whole host

Finding over-privileged workloads across a cluster

How Defender for Cloud decides an AKS workload is over-privilegeddeep dive

What is the impact of leaving AKS workloads over-privileged?

How do you lock an AKS cluster down safely?

1. Install the add-on so Gatekeeper can audit

2. Assign the pod security standards in audit mode

3. Fix the workloads, highest blast radius first

4. Switch to deny so the cluster refuses the next bad pod

Quick quiz

Keep learning

Enforcing pod security: the cost and risk view

The container that was the whole host

How a finance partner frames the pod-security decision

Why over-privileged workloads belong on the risk register

What finance can do about the pod-security gap

1. Make clear this is engineering time, not spend

2. Order the work by blast radius, not by finding count

3. Require documented exceptions before deny is switched on

Quick quiz

Keep learning

Enforcing pod security: the headline

The container that was the whole host

What it looks like when a container escape is prevented by design, not luck

Why this is a board-level risk

The leadership move on pod security

1. Set a deadline to reach an enforced end state

2. Ask for proof, not assurance

3. Treat the genuinely elevated workloads as named, owned exceptions

Quick quiz

Keep learning

Controls this lesson covers

Azure Kubernetes Service

Related compliance lessons