More Info:
Verifies no container sets securityContext.privileged=true. A privileged container can compromise the node and every other pod scheduled on it.Risk Level
CriticalAddress
SecurityCompliance Standards
- Cloudanix Best Practice
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify all privileged pods (run on any machine with kubectl access):
-
For each affected pod that is part of a higher‑level controller (Deployment, DaemonSet, StatefulSet, Job, CronJob), edit the controller manifest to remove privileged mode (run on any machine with kubectl access, replace KIND/NS/NAME accordingly):
In the opened spec, under each affected
containersorinitContainersentry:- Remove the line:
or, if
securityContexthas multiple fields, remove only: - If the workload truly needs some low‑level access, add only the required capabilities instead:
- Remove the line:
-
For affected standalone Pods without an owning controller, edit the Pod spec directly (run on any machine with kubectl access):
In each affected container’s
securityContext, removeprivileged: trueas in step 2, optionally replacing it with minimalcapabilities.addentries if required. Save and exit to apply. -
If any privileged setting comes from a shared Pod template (e.g., Helm chart or GitOps manifest), locate and update that source manifest so changes persist (run where your manifests live):
- Open the manifest defining the controller (e.g.,
deployment.yaml,daemonset.yaml). - Edit the container spec to remove
securityContext.privileged: trueor replace with minimalsecurityContext.capabilities.addas in step 2. - Re‑apply if you manage manifests manually:
- Open the manifest defining the controller (e.g.,
-
Wait for non‑privileged replacements to be running and old pods terminated (run on any machine with kubectl access):
Confirm newly created pods for each modified workload are in
Running(or expected) state withoutprivilegedenabled in their spec. -
Verify remediation (run on any machine with kubectl access):
Ensure the output is
is_compliant=trueand no line showsprivileged=true is_compliant=falsefor non‑system namespaces.
Using kubectl
Using kubectl
On any machine with kubectl access to the cluster:
-
Identify the owning controller (from the audit output’s
owner=field). If the pod is controlled by a Deployment/DaemonSet/StatefulSet/etc., you must edit that controller, not the pod. -
Edit the controller manifest to remove privileged mode and (optionally) add only required capabilities.
Example for a Deployment (replace values as needed):
In
/tmp/my-app-deploy.yaml, under each affected container (and/or initContainer), change:to either removeprivilegedentirely:or, if specific capabilities are required, replace with:(Adjust capability names to the minimal set actually needed, or removecapabilitiesentirely if none are required.) Then apply: -
If the pod is not controlled by any higher-level object (
owner=is empty), edit the pod spec directly and recreate it:Edit/tmp/my-pod.yaml:- Remove
metadata.resourceVersion,metadata.uid,metadata.creationTimestamp,metadata.managedFields,metadata.ownerReferences, andstatussections. - Under each affected container/initContainer, change/remove
securityContext.privileged: trueas described above.
- Remove
-
Verification (on any machine with kubectl access):
Ensure no line shows
privileged=trueand overall output isis_compliant=true.
Automation
Automation

