Skip to main content

Minimize Admission Of Containers Sharing The Host IPC

More Info:​

Sharing the host IPC namespace allows a container to access shared memory of other processes on the node. Enforce policies that restrict admission of hostIPC containers.

Risk Level​

High

Address​

Security

Compliance Standards​

  • CIS OKE

Triage and Remediation​

Remediation​

Manual Steps

  1. List existing pods using hostIPC in all namespaces

    • Run on: any machine with kubectl access
    • Command: 
      kubectl get pods -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,HOST_IPC:.spec.hostIPC' --no-headers | grep -w true || echo "No pods with hostIPC: true found"
    • Review which workloads currently require hostIPC: true, and document the business/technical justification for each.

  2. Inspect pod specs that use hostIPC to understand why it is needed

    • Run on: any machine with kubectl access
    • For each namespace with hostIPC: true pods: 
      NAMESPACE=<namespace-name>
      kubectl get pods -n "$NAMESPACE" -o yaml | awk '/^  hostIPC: true/{show=1} show{print} /^status:/{show=0}'
    • Decide case-by-case whether the host IPC access is strictly required or can be removed/alternative design used.

  3. Review existing admission controls (e.g. Pod Security Standards / policies) per namespace

    • Run on: any machine with kubectl access
    • If using built-in Pod Security admission labels: 
      kubectl get ns --show-labels
    • If using Gatekeeper/Kyverno or another policy engine, list policies and identify those that constrain spec.hostIPC: 
      # Gatekeeper example
      kubectl get k8spsp* constraints.constraints.gatekeeper.sh -A 2>/dev/null || true
      kubectl get constraints.constraints.gatekeeper.sh -A 2>/dev/null || true

      # Kyverno example
      kubectl get clusterpolicy,policy -A 2>/dev/null || true
    • Determine which namespaces hosting user workloads currently lack any policy preventing hostIPC: true.

  4. Decide and design namespace-level policy to minimize hostIPC

    • For each user-workload namespace, decide:
      • Should hostIPC be completely forbidden?
      • Are there exceptional workloads that must be allowed, and how will they be identified (labels, dedicated namespace, etc.)?
    • Based on your admission controller (Pod Security, Gatekeeper, Kyverno, etc.), design or select a policy that:
      • Denies pods with spec.hostIPC: true in general user namespaces.
      • Optionally allows only explicitly approved workloads/namespaces.

  5. Apply or adjust the policy manifests for each user-workload namespace

    • Run on: any machine with kubectl access
    • Apply your chosen policy manifests using kubectl apply -f <file>.yaml (content depends on your chosen policy engine and your decision in step 4).
    • For namespaces that must permit hostIPC for specific workloads, document and implement a controlled exception mechanism (e.g., dedicated namespace with stricter access control).

  6. Re-verify that hostIPC usage is minimized and new admission is restricted

    • Run on: any machine with kubectl access
    • Confirm no unintended pods use hostIPC: 
      kubectl get pods -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,HOST_IPC:.spec.hostIPC' --no-headers | grep -w true || echo "No pods with hostIPC: true found (except any intentional exceptions)"
    • Attempt (in a test namespace) to create a pod with hostIPC: true and confirm it is rejected by the policy, adjusting the policy if necessary.
Using kubectl

Using kubectl​

Run all commands from any machine with kubectl access.

1. Discover current PodSecurity admission level per namespace​

These labels indicate if baseline/restricted Pod Security is enforced, which can block hostIPC: true.

kubectl get ns --show-labels

Potential problem:

  • Namespaces that run user workloads and either:
    • Have no pod-security.kubernetes.io/* labels, or
    • Are labeled with privileged or have only warn/audit levels, not enforce, may allow hostIPC: true pods.

Focus on namespaces like default, app-specific namespaces, and any non-system namespaces.

2. List existing pods/containers using hostIPC​

kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'

Any output indicates pods that are sharing the host IPC namespace and should be reviewed.

To inspect one of them:

kubectl get pod -n <namespace> <pod-name> -o yaml

Look for:

spec:
  hostIPC: true

Problem indication:

  • Any workload pod (not a deliberately privileged/system tool) with hostIPC: true is a potential security concern.

3. Check workloads that could create hostIPC pods​

Deployments:

kubectl get deploy -A
kubectl get deploy -A -o yaml | grep -n "hostIPC"

DaemonSets:

kubectl get daemonset -A
kubectl get daemonset -A -o yaml | grep -n "hostIPC"

StatefulSets:

kubectl get statefulset -A
kubectl get statefulset -A -o yaml | grep -n "hostIPC"

Problem indication:

  • Any controller spec containing hostIPC: true will continuously create pods with host IPC enabled unless changed.

4. Find admission policies that address hostIPC (if using Kyverno/OPA/Gatekeeper, etc.)​

Kyverno ClusterPolicies:

kubectl get clusterpolicy | sed '1d' || echo "No Kyverno ClusterPolicies found"

If present, inspect for hostIPC rules:

kubectl get clusterpolicy -o yaml | grep -n "hostIPC"

Gatekeeper constraints (if installed):

kubectl get constrainttemplates || echo "No Gatekeeper ConstraintTemplates found"
kubectl get constraints --all-namespaces || echo "No Gatekeeper constraints found"
kubectl get constraints --all-namespaces -o yaml | grep -n "hostIPC"

Problem indication:

  • No admission policies referencing hostIPC in namespaces with user workloads means there is no explicit control preventing hostIPC: true pods.

5. Verification after any policy decisions​

After you adjust labels/policies manually, verify again:

# 1) Confirm no new hostIPC pods exist
kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'

# 2) Confirm namespaces have intended PodSecurity labels
kubectl get ns --show-labels

# 3) Confirm admission policies reference hostIPC as intended (if used)
kubectl get clusterpolicy -o yaml | grep -n "hostIPC" || true
kubectl get constraints --all-namespaces -o yaml | grep -n "hostIPC" || true

Any remaining hostIPC: true workloads should be individually reviewed to decide if they are truly necessary and appropriately isolated.

Automation
#!/usr/bin/env bash
# Report pods that share the host IPC namespace, cluster-wide.
# Run on: any machine with kubectl access and current kube-context set.

set -euo pipefail

echo "=== Host IPC usage by pods (hostIPC: true) ==="
echo

# 1) List all pods with hostIPC: true, across all namespaces
kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.serviceAccountName}{"\n"}{end}' \
  | sort \
  | awk 'BEGIN { printf "%-30s %-40s %-30s\n", "NAMESPACE", "POD", "SERVICEACCOUNT";
                 print  "------------------------------ ---------------------------------------- ------------------------------" }
         { printf "%-30s %-40s %-30s\n", $1, $2, $3 }'

echo
echo "=== Namespaces that contain pods with hostIPC: true ==="
kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.namespace}{"\n"}{end}' \
  | sort -u

echo
echo "=== Detailed spec for each hostIPC pod (for review) ==="
for ns in $(kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.namespace}{"\n"}{end}' | sort -u); do
  echo
  echo "Namespace: ${ns}"
  echo "-----------------------------"
  # Show only the hostIPC=true field and basic identifiers to keep it readable
  kubectl get pods -n "${ns}" \
    -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}POD: {.metadata.name}  SA: {.spec.serviceAccountName}  hostIPC: {.spec.hostIPC}{"\n"}{end}'
done

echo
echo "=== OPTIONAL: PodSecurity-related labels on each affected namespace ==="
echo "(These labels influence whether hostIPC is allowed under Pod Security Admission)"
echo
for ns in $(kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.namespace}{"\n"}{end}' | sort -u); do
  echo "Namespace: ${ns}"
  kubectl get ns "${ns}" --show-labels
  echo
done

How to interpret the output

  • The first table lists all pods that currently have hostIPC: true.
    • Any entry here is a potential problem that must be explicitly justified as an exception.
  • The “Namespaces that contain pods with hostIPC: true” list shows where you must ensure admission policies (e.g., Pod Security, PSP replacements, or validating admission policies) are configured to control or forbid hostIPC.
  • The detailed spec section helps you review:
    • Which service accounts and applications are using host IPC.
    • Whether usage aligns with an approved exception.
  • The namespace labels section helps you see if Pod Security (or equivalent) is configured strongly enough; namespaces with permissive labels while also having hostIPC: true pods are higher-risk and should be reviewed closely.

This script only reports; you must decide case by case whether each hostIPC: true pod is acceptable and then adjust admission policies and workload manifests accordingly.