Skip to main content

More Info:

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

Risk Level

Critical

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. Identify pods currently using hostIPC (any machine with kubectl access):
  2. 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: true is strictly required; if not, plan to remove it and block future use.
  3. Remove hostIPC from existing workload specs (any machine with kubectl access):
    • For a Deployment (repeat for other controllers as needed):
      Edit /tmp/deploy-no-hostipc.yaml and remove any line like:
      from under spec.template.spec.
      • Apply the change:
    • Repeat similarly for StatefulSets, DaemonSets, Jobs, and CronJobs in that namespace.
  4. Create or update a PodSecurityPolicy (if still in use in your cluster) or Pod Security admission configuration to disallow hostIPC in 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 forbids hostIPC (e.g. restricted), after reviewing impact:
  5. 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:
  6. Verification (any machine with kubectl access):
    Review output and ensure no pods report is_pod_hostipc: true.
On any machine with kubectl access:
  1. Identify namespaces with user workloads (example list; adjust to your environment):
  1. 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 as deny-hostipc-pods.yaml:
Apply:
Edit the namespaces list in the manifest to cover each namespace that hosts user workloads.

Example: Gatekeeper (OPA) ConstraintTemplate + Constraint

Save as hostipc-template.yaml:
Apply:
Then create a constraint, e.g. hostipc-constraint.yaml:
Apply:
Update the namespaces list as needed.

Example: PodSecurityPolicy (only if PSP is enabled)

Save as psp-no-hostipc.yaml:
Apply:
Then bind it per namespace (example for prod):
Apply:
Repeat the Role/RoleBinding per namespace that hosts user workloads.
  1. Verification (re-run the provided audit):
Confirm no new pods with is_pod_hostipc: true can be created in the protected namespaces.

Additional Reading: