More Info:
Sharing the host PID namespace lets a container view and interact with all processes on the node. Enforce policies that restrict admission of hostPID containers.Risk Level
HighAddress
SecurityCompliance Standards
- CIS OKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify all pods using
hostPIDin each workload namespace- Run on: any machine with kubectl access
- Command:
- Record which namespaces and applications currently use
hostPID.
-
Review whether
hostPIDusage is strictly necessary- For each identified pod, inspect its spec and discuss with the owning team whether it truly requires host-level process visibility (e.g., specific debugging/monitoring daemons).
- Command (example for one pod):
- Decide: keep
hostPID(documented justification and owner) or plan to remove it from the pod spec.
-
Check for existing admission controls related to
hostPID- Run on: any machine with kubectl access
- If you use PSP (legacy clusters):
- If you use Pod Security Admission labels:
- If you use other admission controllers (e.g., Kyverno, Gatekeeper), list their policies and search for
hostPIDin the policy repo or manifests used to deploy them.
-
Decide and implement a namespace-level policy for future pods
- For each user workload namespace, decide on the stance:
- Disallow hostPID by default, with explicit exceptions via separate namespaces or explicit policy overrides.
- Example Kyverno policy manifest snippet (to be customized and applied if you use Kyverno):
- Apply with:
- If you use a different admission mechanism, create/adjust an equivalent rule there.
- For each user workload namespace, decide on the stance:
-
Refactor existing workloads that do not need
hostPID- For pods where
hostPIDis not strictly required, update their manifests (Deployments, StatefulSets, DaemonSets, etc.) to removehostPID: trueor explicitly sethostPID: false. - Example edit for a Deployment:
- In the opened manifest, remove or change:
to either omit
hostPIDor set it tofalse. - Save and allow the controller to roll out the updated pods.
- For pods where
-
Verify that
hostPIDusage is minimized and blocked going forward- Re-run the discovery command:
- Confirm that:
- Only explicitly justified system/monitoring pods (if any) still use
hostPID. - Attempting to create a new pod with
hostPID: truein a protected namespace is rejected by your admission policy (test with a small test pod manifest andkubectl apply -f).
- Only explicitly justified system/monitoring pods (if any) still use
- Re-run the discovery command:
Using kubectl
Using kubectl
hostPID: truein a PSP that is referenced by service accounts used for user workloads means those workloads are allowed to request host PID sharing.
- Any pod spec with
hostPID: trueis using the host PID namespace and must be reviewed. - Frequent or unreviewed use of
hostPID: truein user namespaces suggests insufficient admission control.
- Any controller template containing
hostPID: truewill continuously recreate pods with host PID access, making it harder to enforce restrictions.
- User-workload namespaces labeled with
pod-security.kubernetes.io/enforceset to a level that permitshostPID: true(e.g., notrestrictedin recent Kubernetes versions) mean host PID usage may not be blocked by default and relies solely on workload authors’ choices.
- Absence of any constraint touching
hostPID, or constraints scoped only to non–user namespaces, means there is no enforced policy to minimize host PID containers.
Verification (after you design and apply your chosen policy):
Automation
Automation
- Any line printed under any of the sections (Pods, Deployments, StatefulSets, DaemonSets, ReplicaSets, CronJobs, Jobs) identifies a workload that is configured with
hostPID: true. - Workloads in user application namespaces with
hostPID: trueare the primary concern for this control and should be reviewed; where not strictly necessary, they should be reconfigured to avoid sharing the host PID namespace and governed by admission policies that prevent such configurations.

