More Info:
Verifies allowPrivilegeEscalation is false on every container. It defaults to true, letting a process gain more privileges than its parent.Risk Level
HighAddress
SecurityCompliance Standards
- Cloudanix Best Practice
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify the non-compliant Pod(s) (run on any machine with kubectl access):
-
For a Pod managed by a higher-level controller (Deployment/StatefulSet/DaemonSet, etc.), edit the controller manifest to set
allowPrivilegeEscalation: falseon every container (run on any machine with kubectl access; repeat per owning resource):In each.spec.template.spec.containers[]and.spec.template.spec.initContainers[]entry, ensure:IfsecurityContextexists, just addallowPrivilegeEscalation: falseunder it. -
For a standalone Pod (no controller owner listed in step 1 output), export, modify, and re-create it (run on any machine with kubectl access; replace NAMESPACE and POD_NAME):
Edit
/tmp/pod-POD_NAME.yamland, for every entry inspec.containers[]andspec.initContainers[], set:Then deletemetadata.resourceVersion,metadata.uid,metadata.creationTimestamp,metadata.managedFields, andstatussections from the file. Apply the fixed Pod: -
If your AKS cluster is managed via GitOps or IaC (e.g., manifests in a Git repo, Bicep/Terraform/ARM), update the source manifests instead of using
kubectl edit, ensuring all container and initContainer specs include:Commit and deploy according to your existing pipeline so changes persist. - Consider operational impact before saving each change: updating a Pod template in a controller triggers rollout of new Pods; standalone Pods will be deleted and recreated, briefly interrupting workloads.
-
Verify compliance (run on any machine with kubectl access):
Ensure the output is exactly
is_compliant=true.
Using kubectl
Using kubectl
On any machine with kubectl access:
- Identify non‑compliant Pods and their owners (for context only):
- Patch an existing Pod’s containers to set
allowPrivilegeEscalation: false(for Pods you manage directly, knowing this will recreate them via their controller, not edit live static Pods):
- Preferred: edit the owning workload manifest and re‑apply (Deployment, DaemonSet, StatefulSet, Job, etc.). Example for a Deployment (apply from any machine with kubectl):
- Verification (run on any machine with kubectl):
Automation
Automation

