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 containers (any machine with kubectl access)
-
Determine the owning workload for each offending pod (any machine with kubectl access)
For a specific pod from the list (replace placeholders with actual values from step 1):- If there is an ownerReference (Deployment, StatefulSet, DaemonSet, Job, etc.), plan to edit that controller.
- If there is no ownerReference, the pod is standalone; edit or recreate that Pod manifest.
-
Edit the controller or pod manifest to remove privileged and optionally add specific capabilities (any machine with kubectl access)
a) For a Deployment (similar for StatefulSet/DaemonSet/Job, adjust kind):In the opened manifest, for each affected container (including anyinitContainers):- Locate and remove or change:
- If the workload needs specific kernel capabilities, replace with only those capabilities, for example:
Edit/tmp/example-pod.yamland, for each offending container, removesecurityContext.privileged: trueand optionally add minimal required capabilities as above. Then recreate (pods themselves are immutable): - Locate and remove or change:
-
For Helm-managed workloads, update values instead of live-editing (any machine with kubectl and helm access)
- Identify Helm release and chart:
- Fetch current values, update to remove any
privileged: truesetting and replace with a minimalsecurityContext.capabilities.addblock if needed:
- Identify Helm release and chart:
-
For workloads that genuinely require broad host interaction, review design instead of defaulting to privileged (any machine with kubectl access)
- Inspect container permissions and behavior to see what it actually needs:
- Prefer combinations of:
- Specific
securityContext.capabilities.addentries. hostPathvolumes with tightpathandreadOnly: truewhere possible.runAsNonRoot: true,readOnlyRootFilesystem: truewhen compatible.
Only retain privileged mode if a documented, risk-accepted exception is granted.
- Specific
- Inspect container permissions and behavior to see what it actually needs:
-
Verify no remaining privileged containers (any machine with kubectl access)
Confirm that either the output is exactly
is_compliant=trueor that all listed lines end withprivileged=false is_compliant=true.
Using kubectl
Using kubectl
On any machine with kubectl access:If (StatefulSet: Ensure there is no remaining For an unmanaged Pod:(Deleting and recreating is required because Pods are immutable.)Confirm that all listed containers show
- Identify the offending pod and its controller
owner= field. Example:owner= is present, you must edit that owner (Deployment, StatefulSet, DaemonSet, Job, CronJob). If there is no owner, edit the Pod manifest directly (or the Git/IaC source that owns it).- Export the current manifest for the owner
get statefulset, DaemonSet: get daemonset, Job: get job, CronJob: get cronjob. For an unmanaged Pod: get pod.)- Edit the manifest to remove privileged and, if needed, add fine-grained capabilities
initContainers), remove the privileged: true setting under securityContext. Optionally add only the specific capabilities required.Example patch inside the Deployment spec:privileged: true under any containers or initContainers.- Apply the updated manifest
- Verification
privileged=false and the final output is is_compliant=true.Automation
Automation

