Skip to main content

More Info:

Do not generally permit containers to be run with the hostPID flag set to true.

Risk Level

High

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. Identify pods using hostPID: true (any machine with kubectl access)
  2. Review and decide which workloads are allowed to use hostPID (any machine with kubectl access)
    For each non-compliant pod from step 1, inspect its purpose and manifests (Deployments, DaemonSets, etc.) and decide:
    • Is hostPID truly required (e.g., low-level node monitoring / debugging)?
    • If yes, explicitly document the exception (namespace, workload name, business owner, justification).
    • If no, plan to remove hostPID from the workload spec or replace it with a safer pattern.
  3. Remove hostPID: true from workloads that do not require it (any machine with kubectl access)
    For each non-exempt workload, edit the owning controller and remove hostPID: true from spec.template.spec:
    In the editor, delete the line:
    Save and exit to trigger a rollout without hostPID.
    For workloads managed via GitOps/IaC, make the same edit in the source manifests and re-apply:
  4. Define a restrictive policy for each user-workload namespace (PodSecurityPolicy alternative: Pod Security Admission / admission controller) (any machine with kubectl access)
    Since this control is MANUAL, you must choose and implement a policy mechanism appropriate for your cluster (e.g., built-in Pod Security Admission, Kyverno, OPA/Gatekeeper). Example using built-in Pod Security Admission labels to disallow hostPID (applies if your cluster supports Pod Security Admission):
    Then explicitly document exceptions (e.g., a dedicated namespace with a less restrictive policy) and ensure they are tightly controlled.
  5. Optionally create a dedicated namespace for justified hostPID workloads (any machine with kubectl access)
    If you must allow some hostPID workloads, isolate them:
    Apply a clearly documented, less restrictive policy only to this namespace (mechanism depends on your chosen admission controller) and ensure RBAC limits who can deploy there.
  6. Verification (any machine with kubectl access)
    Re-run the audit to confirm no unintended hostPID: true pods remain:
    Confirm that only explicitly approved exception workloads (if any) show is_pod_hostpid: true and are documented as such.
Create a baseline PodSecurity Baseline / restricted combo that disallows hostPID everywhere (except where you explicitly override it later):
In practice you do not recreate namespaces; you label existing ones. For each namespace that should NOT allow hostPID, run:
For the rare namespace that must allow hostPID (e.g. system diagnostics), you consciously opt out by not setting these labels or by setting a lower level and documenting the exception:
If you do not use PodSecurity admission (older clusters), you must instead use a policy engine such as Gatekeeper/OPA or Kyverno. Example Kyverno policy (disallow hostPID except in explicitly allowed namespaces):
Apply the policy:
Verification (matches the audit logic):

Additional Reading: