Skip to main content

More Info:

Sharing the host IPC namespace exposes host inter-process communication to the container. Restrict hostIPC pods in workload namespaces.

Risk Level

High

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. Identify pods using hostIPC (any machine with kubectl access):
  2. For each affected pod, retrieve its owning controller (Deployment/StatefulSet/DaemonSet/Job) if any (any kubectl machine):
    If there is an ownerReference, plan to edit the controller; otherwise plan to edit the Pod manifest source (e.g., Helm chart, YAML in Git).
  3. Create or update a PodSecurity admission policy to deny hostIPC in workload namespaces (any kubectl machine; example for namespace team-a using Pod Security Standards via namespace labels):
    The restricted profile forbids hostIPC: true in new or updated pods.
  4. For clusters without Pod Security Admission (or if you prefer Kyverno), create a policy manifest to block hostIPC (any kubectl machine). Example Kyverno ClusterPolicy:
    Adjust the policy or use your preferred admission controller (e.g., OPA/Gatekeeper) and scope it only to user workload namespaces as per your cluster design.
  5. Remove hostIPC: true from workload definitions (any kubectl machine, editing the actual source manifests/Helm values; example for a Deployment):
    For pods directly created from YAML:
    Review with application owners before removing hostIPC in case it is functionally required; if truly required, document and tightly scope exceptions in the admission policy.
  6. Verification (any machine with kubectl access):
    Confirm that no output lines show is_pod_hostipc: true is_compliant: false in user workload namespaces.