Privileged containers should be avoided

What does the recommendation "Privileged containers should be avoided" check?

Flags Azure Kubernetes Service clusters that admit pods running a privileged container, meaning a container whose 'securityContext.privileged' field is set to true. A privileged container runs with all Linux capabilities and effectively shares the host node's kernel namespaces, so it can reach host devices and the underlying VM. The check is evaluated by the Azure Policy add-on for AKS, which uses a Gatekeeper admission webhook to inspect every pod spec. It does not cover privilege escalation via 'allowPrivilegeEscalation', host path mounts, host networking or added capabilities such as NET_ADMIN: those are separate hardening recommendations. It also only reports on clusters that actually have the Azure Policy add-on installed; a cluster without the add-on is invisible to this control and shows up under a different recommendation instead.

Why does "Privileged containers should be avoided" matter?

A privileged container is close to a root shell on the node. Because it can mount host filesystems and load kernel modules, a single compromised privileged pod lets an attacker break out of the container, read secrets and service-account tokens belonging to other tenants on the same node, and pivot across the cluster. On a shared AKS cluster that turns one vulnerable web workload into a full node, and potentially subscription, compromise. The business consequence is the loss of the isolation boundary you are paying for: regulated data processed by other namespaces is no longer protected, and an incident becomes a cluster-wide breach rather than a contained one. Most application workloads never need privileged mode, so allowing it is pure downside risk.

How do I fix "Privileged containers should be avoided"?

1. Install the Azure Policy add-on so the cluster can be assessed and enforced: 'az aks enable-addons --addons azure-policy --name <cluster> --resource-group <rg>'. Defender for Cloud's Fix action does the same thing.
2. Assign the built-in policy by its display name rather than a hardcoded id, setting the effect to Deny so non-compliant pods are rejected at admission: pid=$(az policy definition list --query "[?displayName=='Kubernetes cluster should not allow privileged containers'].name" -o tsv); az policy assignment create --name no-privileged-containers --policy "$pid" --scope <cluster-resource-id> --params '{"effect":{"value":"Deny"}}'.
3. Fix the offending workloads by removing 'privileged: true' from each container's securityContext in the Deployment or Helm chart, and grant only the specific Linux capabilities the workload genuinely requires. For infrastructure pods that legitimately need elevation, add their namespace to the policy's 'excludedNamespaces' parameter rather than weakening the effect.

# 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