Skip to main content

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

Critical

Address

Security

Compliance Standards

  • Cloudanix Best Practice

Triage and Remediation

Remediation

Manual Steps

  1. Identify all privileged containers (any machine with kubectl access)
  2. 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.
  3. 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 any initContainers):
    • Locate and remove or change:
    • If the workload needs specific kernel capabilities, replace with only those capabilities, for example:
    b) For a standalone Pod (not recommended for long-lived workloads but sometimes present):
    Edit /tmp/example-pod.yaml and, for each offending container, remove securityContext.privileged: true and optionally add minimal required capabilities as above. Then recreate (pods themselves are immutable):
  4. 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: true setting and replace with a minimal securityContext.capabilities.add block if needed:
  5. 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.add entries.
      • hostPath volumes with tight path and readOnly: true where possible.
      • runAsNonRoot: true, readOnlyRootFilesystem: true when compatible.
        Only retain privileged mode if a documented, risk-accepted exception is granted.
  6. Verify no remaining privileged containers (any machine with kubectl access)
    Confirm that either the output is exactly is_compliant=true or that all listed lines end with privileged=false is_compliant=true.
On any machine with kubectl access:
  1. Identify the offending pod and its controller
Use the audit output line for the failing pod to see the owner= field. Example:
If 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).
  1. Export the current manifest for the owner
Example for a Deployment:
(StatefulSet: get statefulset, DaemonSet: get daemonset, Job: get job, CronJob: get cronjob. For an unmanaged Pod: get pod.)
  1. Edit the manifest to remove privileged and, if needed, add fine-grained capabilities
Open the file and, for every affected container (including initContainers), remove the privileged: true setting under securityContext. Optionally add only the specific capabilities required.Example patch inside the Deployment spec:
Ensure there is no remaining privileged: true under any containers or initContainers.
  1. Apply the updated manifest
For an unmanaged Pod:
(Deleting and recreating is required because Pods are immutable.)
  1. Verification
After the controllers have recreated pods, re-run the audit from any machine with kubectl access:
Confirm that all listed containers show privileged=false and the final output is is_compliant=true.