More Info:
Do not generally permit containers to be run with the hostIPC flag set to true.Risk Level
CriticalAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify pods currently using
hostIPC(any machine with kubectl access): -
For each affected namespace, review whether any workload must legitimately use
hostIPC(design/ops decision):- List pods and their controllers:
- With application owners, decide whether
hostIPC: trueis strictly required; if not, plan to remove it and block future use.
- List pods and their controllers:
-
Remove
hostIPCfrom existing workload specs (any machine with kubectl access):- For a Deployment (repeat for other controllers as needed):
Edit
/tmp/deploy-no-hostipc.yamland remove any line like:from underspec.template.spec.- Apply the change:
- Apply the change:
- Repeat similarly for StatefulSets, DaemonSets, Jobs, and CronJobs in that namespace.
- For a Deployment (repeat for other controllers as needed):
-
Create or update a PodSecurityPolicy (if still in use in your cluster) or Pod Security admission configuration to disallow
hostIPCin user namespaces (any machine with kubectl access): Example PodSecurityPolicy (if PSP enabled):Then bind it to service accounts in user namespaces:If you use the built-in Pod Security admission instead of PSP, ensure user namespaces are labeled with a policy level that forbidshostIPC(e.g.restricted), after reviewing impact: -
Test admission control behavior in a non-production namespace (any machine with kubectl access):
Confirm that admission is rejected (pod is not created and an error is returned). After testing, you may delete the test namespace:
-
Verification (any machine with kubectl access):
Review output and ensure no pods report
is_pod_hostipc: true.
Using kubectl
Using kubectl
On any machine with kubectl access:Apply:Edit the Apply:Then create a constraint, e.g. Apply:Update the namespaces list as needed.Apply:Then bind it per namespace (example for Apply:Repeat the Role/RoleBinding per namespace that hosts user workloads.Confirm no new pods with
- Identify namespaces with user workloads (example list; adjust to your environment):
- Create a restrictive PodSecurityPolicy (if PSP is enabled) or a validating policy via a policy engine (e.g., Kyverno, Gatekeeper). Below are example manifests you can adapt; choose the mechanism actually available in your cluster.
Example: Kyverno policy to block hostIPC pods
Save asdeny-hostipc-pods.yaml:namespaces list in the manifest to cover each namespace that hosts user workloads.Example: Gatekeeper (OPA) ConstraintTemplate + Constraint
Save ashostipc-template.yaml:hostipc-constraint.yaml:Example: PodSecurityPolicy (only if PSP is enabled)
Save aspsp-no-hostipc.yaml:prod):- Verification (re-run the provided audit):
is_pod_hostipc: true can be created in the protected namespaces.Automation
Automation

