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 pods (run on any machine with kubectl access):
  2. 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 containers or initContainers entry:
    • Remove the line:
      or, if securityContext has multiple fields, remove only:
    • If the workload truly needs some low‑level access, add only the required capabilities instead:
  3. 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, remove privileged: true as in step 2, optionally replacing it with minimal capabilities.add entries if required. Save and exit to apply.
  4. 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: true or replace with minimal securityContext.capabilities.add as in step 2.
    • Re‑apply if you manage manifests manually:
  5. 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 without privileged enabled in their spec.
  6. Verify remediation (run on any machine with kubectl access):
    Ensure the output is is_compliant=true and no line shows privileged=true is_compliant=false for non‑system namespaces.
On any machine with kubectl access to the cluster:
  1. 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.
  2. 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 remove privileged entirely:
    or, if specific capabilities are required, replace with:
    (Adjust capability names to the minimal set actually needed, or remove capabilities entirely if none are required.) Then apply:
  3. 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, and status sections.
    • Under each affected container/initContainer, change/remove securityContext.privileged: true as described above.
    Then delete and recreate:
  4. Verification (on any machine with kubectl access):
    Ensure no line shows privileged=true and overall output is is_compliant=true.