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

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS GKE
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Manual Steps

  1. Identify all pods using hostIPC: true
    • Run on: any machine with kubectl access
    If jq is unavailable:
  2. Map pods to their controllers and manifests
    • For each <namespace> <pod> from step 1, run:
    • Note the owning Deployment / StatefulSet / DaemonSet / Job / ReplicaSet (or Pod if standalone). Locate and open the corresponding manifest in your Git/IaC repo if applicable.
  3. Review necessity of hostIPC per workload
    • For each owning object, inspect the spec:
    • Look for hostIPC: true. With application owners, confirm whether sharing the host IPC namespace is strictly required (e.g., for specific low-level IPC use cases). If not clearly justified, mark it for removal.
  4. Adjust manifests to remove or avoid hostIPC: true
    • In your deployment manifests (Git/IaC or exported YAML), remove the hostIPC: true line from the pod spec, or set it to false only if you must be explicit:
    • Apply the corrected manifests:
  5. Optionally define restrictive policy (PSP-equivalent or admission policy)
    • If you use PodSecurityPolicy (legacy) or a replacement (e.g., Pod Security Admission, Gatekeeper, Kyverno), author a policy that disallows hostIPC: true except in tightly scoped namespaces. Example evidence command to inspect existing PSPs (if in use):
    • For Pod Security Admission, verify namespaces are at least baseline (which disallows host namespaces by default):
  6. Verify no remaining pods use hostIPC: true
    • After changes roll out, rerun:
    • Confirm the command returns no output, or only the small, explicitly approved set you intended to keep. Document any approved exceptions with their justification.
Interpretation:
Any line printed (not the final “No pods…” message) shows a pod with HOST_IPC set to true. Each such pod needs review: confirm whether sharing the host IPC namespace is strictly required.

Interpretation:
Inspect each pod spec that includes hostIPC: true. Use this to decide which workloads can safely be modified to drop hostIPC.

Interpretation:
Any PodSecurityPolicy with .spec.hostIPC: true permits use of the host IPC namespace. Any role/clusterrolebinding referencing such a PSP extends that permission to the bound subjects (service accounts, users, groups). Those namespaces and identities need review to confirm hostIPC use is intentional and tightly scoped.

Interpretation:
Identify namespaces not labeled with a restrictive policy (e.g., pod-security.kubernetes.io/enforce=restricted). Namespaces with no or permissive labels are more likely to admit pods with hostIPC: true and should be reviewed and, where appropriate, tightened.

Interpretation:
If only the final “No pods with hostIPC: true found” line appears, there are currently no pods requesting the host IPC namespace. If any pods still show HOST_IPC as true, those remaining cases must be explicitly accepted as exceptions or further remediated.
How to interpret the output
  • Problems / items to review:
    • Any entry in section 1): pods listed there are currently running with hostIPC: true.
    • Any namespace listed in section 2): these namespaces host at least one such pod.
    • Any workload listed in section 3): these controllers are configured to create pods with hostIPC: true (persistent risk).
    • Any PSP listed in section 4) with hostIPC allowed: these policies permit hostIPC: true.
  • These outputs should be reviewed to decide whether hostIPC: true is strictly necessary and, if not, have manifests/PSPs updated so that .spec.hostIPC is omitted or set to false.

Additional Reading: