Skip to main content

Minimize The Admission Containers Wishing Share The Host

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 AKS
  • CIS Critical Security Controls v8
  • 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. List namespaces that should host user workloads

    • On any machine with kubectl access: 
      kubectl get ns
    • Identify which namespaces are for user workloads (e.g., exclude kube-system, gatekeeper-system, azure-arc, etc.). Document this list.

  2. Check for existing hostNetwork usage in each user-workload namespace

    • On any machine with kubectl access, for each user-workload namespace USER_NS: 
      kubectl get pods -n USER_NS -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.hostNetwork}{"\n"}{end}' | grep -E "true$" || echo "No hostNetwork pods in USER_NS"
    • Review any pods showing true. Confirm with the owning team whether host networking is strictly required.

  3. Review namespace-level Pod Security labels and current policy stance

    • On any machine with kubectl access: 
      kubectl get ns --show-labels
    • For each user-workload namespace, check if it has any of:
      pod-security.kubernetes.io/enforce, pod-security.kubernetes.io/audit, pod-security.kubernetes.io/warn.
    • Note namespaces lacking pod-security.kubernetes.io/enforce=restricted (these are not enforcing restricted Pod Security standards and may allow hostNetwork).

  4. Decide which namespaces must be allowed to use hostNetwork (if any)

    • For all pods currently using hostNetwork: true, decide if they:
      • a) Can be refactored to not require host networking (preferred), or
      • b) Must keep host networking (e.g., specific networking/ingress/observability components).
    • For namespaces that must allow hostNetwork, note that they should either:
      • Remain at baseline or lower enforcement, or
      • Be carved out into a dedicated “system” or “infra” namespace with clearly documented exceptions.

  5. Apply or tighten Pod Security labels on user-workload namespaces

    • On any machine with kubectl access, for user-workload namespaces that should not allow hostNetwork (most cases): 
      kubectl label --overwrite ns USER_NS pod-security.kubernetes.io/enforce=restricted
    • Optionally, to emit warnings cluster-wide when policies are only at baseline: 
      kubectl label --overwrite ns --all pod-security.kubernetes.io/warn=baseline
    • Ensure you do not enforce restricted on namespaces where known workloads legitimately require hostNetwork until those workloads are moved or redesigned.

  6. Verify policy and current usage after changes

    • On any machine with kubectl access: 
      kubectl get ns --show-labels
      Confirm that all user-workload namespaces that should forbid hostNetwork now have pod-security.kubernetes.io/enforce=restricted.
    • Re-run the hostNetwork usage check to ensure no unexpected pods are using host networking: 
      for ns in $(kubectl get ns -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
        echo "Namespace: $ns"
        kubectl get pods -n "$ns" -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.hostNetwork}{"\n"}{end}' | grep -E "true$" || echo "  No hostNetwork pods"
        echo
      done
    • Any remaining hostNetwork: true pods in restricted namespaces indicate workloads that must be redesigned or moved to an appropriately labeled exception namespace.
Using kubectl
# 1) List all namespaces and their Pod Security labels
# Run on: any machine with kubectl access
kubectl get ns --show-labels

Problem indication:

  • Namespaces running user workloads that do NOT have pod-security.kubernetes.io/enforce=restricted.
  • Namespaces that explicitly allow host networking via PodSecurity admission exemptions or lack any Pod Security labels.
# 2) Show namespaces that do NOT enforce 'restricted' Pod Security
kubectl get ns \
  -o jsonpath='{range .items[?(!@.metadata.labels.pod-security\.kubernetes\.io/enforce)]}{.metadata.name}{"\n"}{end}'

Problem indication:

  • Any namespace listed here that hosts user workloads may allow hostNetwork: true unless controlled by some other mechanism (e.g., Gatekeeper, Azure Policy).
# 3) Inspect Pod Security labels for a specific namespace
# Replace <namespace> with the namespace you are evaluating.
kubectl get ns <namespace> --show-labels -o yaml

Problem indication:

  • For user-workload namespaces, missing or weaker labels than:
    • pod-security.kubernetes.io/enforce: restricted
  • Presence of labels that imply looser constraints (e.g., enforce: baseline) without compensating controls.
# 4) Find currently running Pods using hostNetwork
kubectl get pods -A -o wide \
  --field-selector spec.hostNetwork=true

Problem indication:

  • Any Pods in user-workload namespaces (non-system, non-infra) appearing in this list.
  • Especially concerning if those namespaces do not enforce restricted Pod Security.
# 5) For a specific namespace, list Pods and show hostNetwork setting
kubectl get pods -n <namespace> -o custom-columns=NAME:.metadata.name,HOSTNETWORK:.spec.hostNetwork

Problem indication:

  • HOSTNETWORK value true for user workloads that do not have a clearly justified need (requires human review with app owners).
# 6) Review raw Pod spec for a specific Pod using hostNetwork
kubectl get pod <pod-name> -n <namespace> -o yaml

Problem indication:

  • spec.hostNetwork: true present in Pods that are not explicitly approved to use host networking.
  • Combined with lack of restricted Pod Security enforcement on the namespace.
Automation
#!/usr/bin/env bash
#
# Report pods using hostNetwork, grouped by namespace.
# Run from any machine with kubectl access and current-context set.

set -euo pipefail

echo "=== Summary: namespaces with pods using hostNetwork:true ==="
kubectl get pods --all-namespaces -o jsonpath='{range .items[?(@.spec.hostNetwork==true)]}{.metadata.namespace}{"\n"}{end}' \
  | sort -u

echo
echo "=== Detailed report of pods using hostNetwork:true ==="
kubectl get pods --all-namespaces \
  -o jsonpath='{range .items[?(@.spec.hostNetwork==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.serviceAccountName}{"\t"}{.status.phase}{"\n"}{end}' \
  | column -t

echo
echo "=== Namespaces and their Pod Security labels (enforce/warn) ==="
kubectl get ns \
  -o custom-columns='NAMESPACE:.metadata.name,ENFORCE:metadata.labels.pod-security\.kubernetes\.io/enforce,WARN:metadata.labels.pod-security\.kubernetes\.io/warn' \
  | sort

echo
echo "=== Suggested review ==="
echo "1) Any namespace in the first summary list that runs user workloads is a REVIEW TARGET."
echo "2) For those namespaces:"
echo "   - Verify each pod actually requires hostNetwork:true."
echo "   - Consider tightening Pod Security labels, e.g.:"
echo "       kubectl label --overwrite ns <ns> pod-security.kubernetes.io/enforce=restricted"
echo "3) System/control-plane namespaces (kube-system, aks-*, gatekeeper-system, etc.)"
echo "   may legitimately use hostNetwork, but should still be reviewed."

Problematic output to look for:

  • First section lists any non-system namespaces (for example, default, prod, staging, team-a) that appear there: these contain pods using hostNetwork: true and must be manually reviewed.
  • In the third section, such namespaces often have empty or non-restricted pod-security.kubernetes.io/enforce labels, indicating that hostNetwork use is not being constrained by policy and should be evaluated.

Additional Reading:​