Skip to main content

Minimize The Admission Of Containers Sharing The Host IPC

More Info:​

Containers sharing the host IPC namespace can access inter-process communication of other host processes. Their admission should be restricted via Pod Security Admission policies.

Risk Level​

High

Address​

Security

Compliance Standards​

  • CIS AKS

Triage and Remediation​

Remediation​

Manual Steps

  1. Identify namespaces with user workloads

    • Run on: any machine with kubectl access
    kubectl get ns

    Decide which namespaces are user-facing (exclude system namespaces like kube-system, kube-public, kube-node-lease, and cloud-provider/system add-on namespaces).

  2. Find existing pods that use hostIPC: true

    • Run on: any machine with kubectl access
    for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
      echo "Namespace: $ns"
      kubectl get pods -n "$ns" -o json | \
        jq -r '.items[] | select(.spec.hostIPC==true) | .metadata.name' || true
    done

    Review any listed pods with application owners and decide whether hostIPC is strictly required. If not, plan to remove it from their Pod/Deployment/StatefulSet manifests and redeploy.

  3. Review current Pod Security labels on namespaces

    • Run on: any machine with kubectl access
    kubectl get ns --show-labels

    For each user namespace, check whether pod-security.kubernetes.io/enforce (or pod-security.kubernetes.io/warn) is present and what level it is set to (privileged, baseline, or restricted). Note that restricted disallows hostIPC: true.

  4. Decide the appropriate policy level per namespace

    • For each user namespace:
      • If no workloads require hostIPC, plan to enforce restricted.
      • If some workloads temporarily require hostIPC, consider baseline or an exception namespace for those workloads, and plan to migrate them off hostIPC where possible.
      • Document any justified exceptions, including owning team, purpose, and review date.

  5. Apply or adjust namespace Pod Security labels

    • Run on: any machine with kubectl access
    • To enforce restricted where hostIPC is not required: 
      kubectl label --overwrite ns NAMESPACE pod-security.kubernetes.io/enforce=restricted
    • To add a warning-level policy (e.g., cluster-wide baseline warnings): 
      kubectl label --overwrite ns --all pod-security.kubernetes.io/warn=baseline

    Replace NAMESPACE with each chosen user namespace. Coordinate with application owners before enforcing in production to avoid unexpected admission failures.

  6. Verify the effect of the policy and current usage

    • Confirm namespace labels: 
      kubectl get ns --show-labels
    • Attempt (in a test namespace) to create a pod with hostIPC: true and ensure it is rejected where enforce=restricted is set.
    • Re-run the hostIPC usage scan to confirm no unintended hostIPC pods remain: 
      for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
        echo "Namespace: $ns"
        kubectl get pods -n "$ns" -o json | \
          jq -r '.items[] | select(.spec.hostIPC==true) | .metadata.name' || true
      done
Using kubectl

Using kubectl​

1. List pods using hostIPC​

Run on: any machine with kubectl access.

kubectl get pods -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,HOST_IPC:.spec.hostIPC' \
  | grep -E 'true|HOST_IPC'

Output indicating a problem:

  • Any line (other than the header) where HOST_IPC is true is a pod sharing the host IPC namespace and must be reviewed.

To see full spec for a specific pod:

kubectl get pod POD_NAME -n NAMESPACE -o yaml

Check:

  • .spec.hostIPC: true → this pod is sharing host IPC.

2. See current Pod Security Admission labels on namespaces​

Run on: any machine with kubectl access.

kubectl get ns -o custom-columns='NAME:.metadata.name,ENFORCE:.metadata.labels.pod-security\.kubernetes\.io/enforce,WARN:.metadata.labels.pod-security\.kubernetes\.io/warn'

Output indicating a problem (with respect to host IPC restriction):

  • Namespaces that run user workloads and:
    • Have ENFORCE unset or set to privileged may allow hostIPC: true unless other policies exist.
    • Use baseline instead of restricted may still allow some higher-risk options; verify separately with your policy requirements.

You must decide:

  • Which namespaces should be hardened (e.g., enforce=restricted).
  • Whether any hostIPC: true pods are strictly necessary for their workloads.

3. Check for namespace-level policies that might already restrict hostIPC (optional deeper review)​

If you use Gatekeeper/OPA or other policy engines, list their constraints (example for Gatekeeper):

kubectl get constrainttemplates.constraints.gatekeeper.sh
kubectl get constraints.gatekeeper.sh -A

Output indicating a problem:

  • No constraints referencing hostIPC or similar fields means nothing (beyond Pod Security Admission) is limiting host IPC usage, so hostIPC: true pods you found are likely admitted without additional controls.

These commands only surface the current state. A human must review which hostIPC: true pods are justified and whether namespace labels and policies are appropriate for your risk tolerance.

Automation
#!/usr/bin/env bash
# Report pods using hostIPC and namespace Pod Security labels
# Run on: any machine with kubectl access and current context set

set -o errexit
set -o nounset
set -o pipefail

echo "=== Namespace Pod Security labels (enforce/warn) ==="
kubectl get ns \
  -o custom-columns=NAME:.metadata.name,ENFORCE:'.metadata.labels.pod-security\.kubernetes\.io/enforce',WARN:'.metadata.labels.pod-security\.kubernetes\.io/warn' \
  | sed 's/<none>//g'

echo
echo "=== Pods requesting hostIPC=true (cluster-wide) ==="
kubectl get pods --all-namespaces -o json \
  | jq -r '
    .items[]
    | select(.spec.hostIPC == true)
    | [
        .metadata.namespace,
        .metadata.name,
        (.metadata.ownerReferences[0].kind // "Pod"),
        (.metadata.ownerReferences[0].name // "N/A")
      ]
    | @tsv
  ' 2>/dev/null \
  | awk 'BEGIN { OFS="\t"; print "NAMESPACE","POD","OWNER_KIND","OWNER_NAME" } { print }'

echo
echo "=== Summary: count of pods with hostIPC=true per namespace ==="
kubectl get pods --all-namespaces -o json \
  | jq -r '
    [ .items[] | select(.spec.hostIPC == true) | .metadata.namespace ] 
    | group_by(.) 
    | map({ns: .[0], count: length}) 
    | sort_by(.ns) 
    | .[] 
    | "\(.ns)\t\(.count)"
  ' 2>/dev/null \
  | awk 'BEGIN { OFS="\t"; print "NAMESPACE","HOSTIPC_POD_COUNT" } { print }'

echo
echo "=== Detail: pods with hostIPC=true and their containers ==="
kubectl get pods --all-namespaces -o json \
  | jq -r '
    .items[]
    | select(.spec.hostIPC == true)
    | . as $pod
    | $pod.spec.containers[]
    | [
        $pod.metadata.namespace,
        $pod.metadata.name,
        .name,
        ($pod.metadata.labels."app" // ""),
        ($pod.metadata.labels."app.kubernetes.io/name" // "")
      ]
    | @tsv
  ' 2>/dev/null \
  | awk 'BEGIN { OFS="\t"; print "NAMESPACE","POD","CONTAINER","APP_LABEL","APP_K8S_NAME_LABEL" } { print }'

Explanation of output indicating a problem:

  • In “Pods requesting hostIPC=true” and “Detail: pods with hostIPC=true and their containers”:
    • Any listed pod is a potential issue. Each such pod should be reviewed to determine if hostIPC is strictly necessary.
  • In “Summary: count of pods with hostIPC=true per namespace”:
    • Namespaces with non‑zero HOSTIPC_POD_COUNT require review; high counts suggest broader policy gaps.
  • In “Namespace Pod Security labels”:
    • Namespaces running user workloads that:
      • lack pod-security.kubernetes.io/enforce=restricted, or
      • have no ENFORCE label at all, should be evaluated. If workloads do not require hostIPC or other privileged features, consider enforcing the restricted profile (or stronger controls via alternative mechanisms).