Container with privilege escalation should be avoided

What does the recommendation "Container with privilege escalation should be avoided" check?

Flags any container in an AKS pod spec that does not explicitly set 'securityContext.allowPrivilegeEscalation' to false. That field controls whether a process can gain more privileges than its parent, for example through a setuid binary or by acquiring new file capabilities during exec, so leaving it unset (the Kubernetes default of true) means a compromised process inside the container can elevate beyond the rights it started with. The check evaluates the static pod manifest as admitted to the API server: it does not inspect what the workload actually does at runtime, it does not detect escalation through a separate node-level exploit, and it is distinct from the related recommendations for privileged containers, host namespace sharing, host path mounts and added Linux capabilities, each of which is a separate control with its own setting. A container can therefore pass this check and still be flagged elsewhere if, say, it requests a dangerous capability.

Why does "Container with privilege escalation should be avoided" matter?

Privilege escalation is a standard step in container breakout chains. An attacker who lands code execution in a pod through an application vulnerability, an exposed dependency or a leaked secret will try to escalate within the container before pivoting to the node, the kubelet credentials or other tenants sharing the cluster. Setting allowPrivilegeEscalation to false closes the setuid and ambient-capability routes, so an initial foothold stays boxed in at the privilege level it began with and cannot bootstrap itself toward root. For a business that means one exploited web service is far less likely to become a full cluster compromise: the blast radius stays inside a single pod rather than reaching every workload on the node, the secrets they mount and the data they hold. That is the difference between an isolated incident your team contains quietly and a reportable breach that pulls in regulators, customers and your incident-response retainer.

How do I fix "Container with privilege escalation should be avoided"?

1. In each container's securityContext, set allowPrivilegeEscalation: false (pair it with runAsNonRoot: true and a dropped capability set), then redeploy. The restricted Pod Security Standard requires this field, so adopting it cluster-wide is the durable fix.
2. Enable the Azure Policy add-on for AKS with 'az aks enable-addons --addons azure-policy -g <rg> -n <cluster>' so the cluster is continuously evaluated against the Kubernetes Gatekeeper policies.
3. Assign the built-in policy by display name rather than a hardcoded GUID, starting in audit before moving to deny: pid=$(az policy definition list --query "[?displayName=='Kubernetes clusters should not allow container privilege escalation'].name" -o tsv); az policy assignment create --name no-privesc --policy "$pid" --scope <cluster-resource-id>

# 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