Skip to main content

Minimize The Admission Of Containers Wishing To Share The

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 OKE
  • 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 namespaces with user workloads and existing PSP/PSa configs

    • Run on: any machine with kubectl access
    • Commands: 
      kubectl get ns
      kubectl get psp
      kubectl get psp -o yaml | grep -n "hostIPC"
      kubectl get clusterrolebindings.rbac.authorization.k8s.io \
        -o custom-columns=NAME:.metadata.name,SUBJECTS:.subjects \
        | grep -E 'system:serviceaccount|system:authenticated'
      kubectl get ns --show-labels
    • Decide which namespaces are “user workload” (non-system, non-control-plane) based on name and labels.

  2. Review current use of hostIPC in existing workloads

    • Run on: any machine with kubectl access
    • Commands (list all pods using hostIPC): 
      kubectl get pods --all-namespaces -o json \
        | jq -r '.items[]
          | select(.spec.hostIPC == true)
          | [.metadata.namespace, .metadata.name] | @tsv'
    • For each namespace returned, inspect the workload specs to understand why hostIPC is used and whether it is strictly required: 
      kubectl get deploy,sts,ds -n <NAMESPACE> -o yaml | grep -n "hostIPC"

  3. Decide acceptable exceptions and document them

    • For each pod/workload currently using hostIPC: true, decide:
      • Is host IPC genuinely required for the application?
      • Can the need be removed by application/config changes (e.g., using pod IPC, different libraries, or sidecars)?
    • Document any namespaces/workloads that must retain hostIPC as explicit, reviewed exceptions (include justification, owner, and review date).

  4. Design admission controls for each user namespace

    • If you use Pod Security Admission (PSa):
      • Prefer enforcing restricted level on user namespaces; it disallows hostIPC by default. 
        kubectl label ns <NAMESPACE> \
          pod-security.kubernetes.io/enforce=restricted \
          pod-security.kubernetes.io/enforce-version=latest \
          --overwrite
      • For namespaces requiring exceptions, consider:
        • Using a different label level (e.g., baseline) only where justified, and
        • Restricting who can deploy into those namespaces via RBAC.
    • If you use a third-party admission controller (e.g., Kyverno / OPA Gatekeeper), draft or update policies to deny pods with spec.hostIPC: true except in explicitly allowed namespaces or with specific labels.

  5. Implement or tighten policies and adjust workloads

    • Apply or update policies (example for Kyverno – adjust to your policy engine; omit if not in use): 
      cat << 'EOF' | kubectl apply -f -
      apiVersion: kyverno.io/v1
      kind: ClusterPolicy
      metadata:
        name: disallow-hostipc
      spec:
        validationFailureAction: enforce
        rules:
          - name: deny-hostipc
            match:
              any:
                - resources:
                    kinds: ["Pod"]
            preconditions:
              all:
                - key: "{{ request.namespace }}"
                  operator: NotIn
                  value: ["kube-system","kube-public","kube-node-lease"]
            validate:
              message: "Using hostIPC is not allowed."
              pattern:
                spec:
                  hostIPC: "false"
      EOF
    • For workloads where hostIPC is not justified, update manifests to remove hostIPC: true and redeploy: 
      # Example: edit a deployment to remove hostIPC
      kubectl -n <NAMESPACE> edit deploy <DEPLOYMENT_NAME>
      # Delete the 'hostIPC: true' line, save, and exit

  6. Verify policy effectiveness and residual usage

    • Confirm new pods with hostIPC: true are rejected in user namespaces (attempt a test deployment): 
      cat << 'EOF' | kubectl apply -f -
      apiVersion: v1
      kind: Pod
      metadata:
        name: test-hostipc
        namespace: <USER_NAMESPACE>
      spec:
        hostIPC: true
        containers:
          - name: pause
            image: k8s.gcr.io/pause:3.9
      EOF
    • Confirm no unexpected pods are running with hostIPC: 
      kubectl get pods --all-namespaces -o json \
        | jq -r '.items[]
          | select(.spec.hostIPC == true)
          | [.metadata.namespace, .metadata.name] | @tsv'
    • Review that any remaining hostIPC usage matches your documented exceptions.
Using kubectl
# 1) List all namespaces (any machine with kubectl access)
kubectl get ns -o wide

Review which namespaces actually host user workloads (exclude obvious system ones like kube-system, kube-public, kube-node-lease, provider-specific system namespaces, etc.). Those user namespaces are your review scope.

# 2) For each user namespace, check for existing policies
kubectl get psp,psa,limitrange,resourcequota,networkpolicy \
  --all-namespaces 2>/dev/null

Look for any admission-related objects (e.g., PodSecurityPolicy in legacy clusters, Pod Security Admission labels on namespaces, or custom admission controllers via annotations) that could already restrict hostIPC: true. Absence of such controls in user namespaces means hostIPC is likely not restricted there.

# 3) Inspect namespace-level pod security labels (per-namespace PSA)
kubectl get ns --show-labels

For each user namespace, examine labels like:

  • pod-security.kubernetes.io/enforce
  • pod-security.kubernetes.io/enforce-version

If enforce is unset or set to a level that allows hostIPC (e.g. privileged), that namespace does not have a strict control preventing hostIPC. You will need a human decision whether that is acceptable.

# 4) Find all running pods that currently use hostIPC (cluster-wide)
kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'

Any lines in the output indicate pods that are already running with hostIPC: true. For each such pod, you must:

  • Confirm whether this is an intentional exception.
  • Decide whether that namespace requires tighter policy or a documented exception.
# 5) Show full specs of pods using hostIPC in a given namespace
NAMESPACE=default  # set to a user namespace you are reviewing
kubectl get pods -n "$NAMESPACE" -o yaml | \
  yq 'select(.spec.hostIPC == true)'

Review the YAML to understand why hostIPC is requested, what app it is, and whether it is justified. Any presence of spec.hostIPC: true is a potential problem unless you explicitly accept that risk.

# 6) Search for hostIPC usage in workload manifests (Deployments, etc.)
NAMESPACE=default  # set per-namespace
kubectl get deploy,ds,sts,job,cronjob -n "$NAMESPACE" -o yaml | \
  grep -n 'hostIPC' -C3 || echo "No hostIPC references found"

If hostIPC: true appears in any controller spec, that namespace is capable of continuously creating hostIPC pods. This is riskier than a single standalone pod and usually indicates a policy gap that needs review.

# 7) Check for validating/mutating webhooks that might enforce hostIPC policy
kubectl get validatingwebhookconfiguration,mutatingwebhookconfiguration -o yaml | \
  grep -n -i 'hostipc' -C4 || echo "No hostIPC-related webhook references found"

If no webhooks appear to reference hostIPC or custom policies around it, admission control for hostIPC is likely not centrally enforced and must be evaluated.

# 8) Verification re-run after any policy decisions (read-only)
kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'
kubectl get ns --show-labels

Interpreting the output:

  • If any user namespace has running pods with spec.hostIPC: true and no clear policy/exception, this is a likely finding.
  • If user namespaces lack pod security labels or other admission policies that would prevent future hostIPC: true usage, the cluster is not minimizing hostIPC admission. A human must decide which namespaces should disallow it and where exceptions are acceptable.
Automation
#!/usr/bin/env bash
# Report pods, controllers, and policies related to hostIPC usage in the cluster.
# Run on: any machine with kubectl access and current context set to target cluster.

set -euo pipefail

echo "=== 1) Workloads currently using hostIPC ==="
echo
echo "--- Pods with hostIPC: true (all namespaces) ---"
kubectl get pods --all-namespaces -o json \
  | jq -r '
    .items[]
    | select(.spec.hostIPC == true)
    | [.metadata.namespace, .metadata.name, .spec.nodeName]
    | @tsv' 2>/dev/null \
  | awk 'BEGIN { OFS="\t"; print "NAMESPACE","POD","NODE"} {print}' || {
    echo "No pods found with hostIPC: true or jq not available."
  }

echo
echo "--- Controllers (Deployments/StatefulSets/DaemonSets/Jobs/CronJobs) with hostIPC: true ---"
# For each workload type, print namespace, name, kind, and whether hostIPC is true in pod template.
for kind in deployment.apps statefulset.apps daemonset.apps job.batch cronjob.batch; do
  echo
  echo "Kind: ${kind}"
  kubectl get "${kind}" --all-namespaces -o json 2>/dev/null \
    | jq -r --arg KIND "${kind}" '
        .items[]
        | select(.spec.template.spec.hostIPC == true)
        | [.metadata.namespace, .metadata.name, $KIND, .spec.template.spec.hostIPC]
        | @tsv' 2>/dev/null \
    | awk 'BEGIN { OFS="\t"; print "NAMESPACE","NAME","KIND","hostIPC"} {print}' || {
      echo "  (none with hostIPC: true or jq not available)"
    }
done

echo
echo "=== 2) Namespaces and their PodSecurity / admission policies regarding hostIPC ==="
echo
echo "--- Namespaces and Pod Security Admission labels ---"
kubectl get ns --show-labels

echo
echo "--- PodSecurityPolicies (if any) that allow hostIPC ---"
if kubectl get podsecuritypolicies.policy >/dev/null 2>&1; then
  kubectl get podsecuritypolicies.policy -o json \
    | jq -r '
        .items[]
        | [.metadata.name, .spec.hostIPC]
        | @tsv' 2>/dev/null \
    | awk 'BEGIN { OFS="\t"; print "PSP","hostIPC_allowed"} {print}' || {
      echo "Unable to query PodSecurityPolicies (or jq not available)."
    }
else
  echo "No PodSecurityPolicy resources found (or PSP not enabled on this cluster)."
fi

echo
echo "=== 3) Summary of risk indicators ==="
echo "Review guidance:"
echo "1) Any entry above where hostIPC is 'true' indicates a potential policy violation."
echo "   - Pods listed in 'Pods with hostIPC: true' are currently running with host IPC."
echo "   - Controllers listed in section 1 will create pods with hostIPC: true."
echo "2) For each namespace with user workloads:"
echo "   - Ensure it has appropriate Pod Security Admission labels (e.g. 'pod-security.kubernetes.io/enforce')"
echo "     that disallow hostIPC, or equivalent admission policies."
echo "3) Any PodSecurityPolicy with 'hostIPC_allowed' set to 'true' should be reviewed and"
echo "   tightened or scoped only to trusted namespaces/service accounts."

How to interpret the output (what indicates a problem):

  • In section “Pods with hostIPC: true”: any listed pod is currently sharing the host IPC namespace and should be reviewed; in most user workloads this is undesirable.
  • In the controllers section: any Deployment/StatefulSet/DaemonSet/Job/CronJob with hostIPC shown as true will create pods with host IPC access; these specs should be reviewed and usually updated to remove hostIPC: true.
  • In the PodSecurityPolicy section: any PSP with hostIPC_allowed set to true permits host IPC; this is a potential risk unless it is intentionally scoped to very specific, trusted use cases.
  • In the namespace labels listing: namespaces that run user workloads but lack restrictive Pod Security labels (or equivalent admission policies) should be reviewed and updated so that hostIPC is disallowed by policy except where explicitly needed.

Additional Reading:​