Skip to main content

Minimize The Admission Containers Wishing Share The Host

More Info:​

Do not generally permit containers to be run with the hostNetwork flag set to true.

Risk Level​

High

Address​

Security

Compliance Standards​

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS GKE
  • 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 all pods using hostNetwork (evidence gathering)
    Run on any machine with kubectl access:

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

    Save the output and identify which workloads are intentionally using hostNetwork.

  2. Identify how each offending pod is deployed (manifest source)
    For each <namespace> <pod> from step 1, find its controller:

    kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.metadata.ownerReferences[*].kind}{" "}{.metadata.ownerReferences[*].name}{"\n"}'

    Then inspect the parent object (e.g., Deployment, DaemonSet, StatefulSet):

    kubectl get deployment <name> -n <namespace> -o yaml
    # or
    kubectl get daemonset <name> -n <namespace> -o yaml
    # or
    kubectl get statefulset <name> -n <namespace> -o yaml

    Determine whether these are system/critical components (e.g., CNI, ingress, monitoring agents) or application workloads.

  3. Review necessity of hostNetwork per workload (risk/requirement decision)
    For each controller using hostNetwork: true:

    • Confirm with the owning team or application documentation whether direct host networking is strictly required (e.g., running a node agent, host-level monitoring, low-latency network functions).
    • If not clearly required, mark it as “candidate for removal of hostNetwork”.
    • Document any justified exceptions (name, namespace, reason).
  4. Update manifests to remove or avoid hostNetwork where possible
    For each “candidate for removal” workload, edit its manifest in your Git/IaC source (preferred) or via kubectl (temporary):

    kubectl edit deployment <name> -n <namespace>

    In the pod template, either:

    • Remove the hostNetwork: true line completely from spec.template.spec, or
    • Set it explicitly to false:
      spec:
      template:
      spec:
      hostNetwork: false

    Apply equivalent changes for DaemonSets/StatefulSets/other controllers. Ensure the application still functions as expected after rollout.

  5. Define and apply restrictive admission policy for hostNetwork (e.g., PSP replacement)
    Based on your cluster’s admission mechanism (e.g., Pod Security Admission, OPA/Gatekeeper, Kyverno), create or tighten policy so that:

    • hostNetwork is denied by default for general namespaces.
    • Only explicitly approved namespaces or workloads are allowed to set hostNetwork: true.
      Example (evidence-only) for clusters still using PodSecurityPolicy:
    kubectl get psp -o yaml | sed -n '/hostNetwork/p'

    Use this output to verify that general-purpose PSPs do not allow hostNetwork: true, or introduce a new “restricted” policy and bind it to non-privileged namespaces.

  6. Re-verify cluster state after changes (evidence of improvement)
    Run again on any machine with kubectl access:

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

    Confirm that:

    • Only documented, justified system or exception workloads appear in the list.
    • All general application namespaces either have zero results or only contain approved exceptions recorded in step 3.
Using kubectl
# 1) List all Pods that request hostNetwork=true in all namespaces
# Run on: any machine with kubectl access
kubectl get pods --all-namespaces -o jsonpath='{range .items[?(@.spec.hostNetwork==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'

Problem indication: Any lines returned indicate Pods that are running with hostNetwork: true and must be reviewed. An empty output means no current Pods use hostNetwork: true.

# 2) Show full specs for Pods using hostNetwork=true for detailed review
kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.hostNetwork==true) | {namespace:.metadata.namespace, name:.metadata.name, spec:.spec}'

Problem indication: Inspect these specs for non-infrastructure workloads, especially application Pods, that do not have a clear, documented need to share the host network namespace.

# 3) Find workload controllers (Deployments/DaemonSets/StatefulSets/Jobs/CronJobs)
# whose pod templates use hostNetwork=true
kubectl get deploy,ds,sts,job,cronjob --all-namespaces -o json \
| jq '.items[] | select(.spec.template.spec.hostNetwork==true) |
{kind:.kind, namespace:.metadata.namespace, name:.metadata.name}'

Problem indication: Any listed controllers create Pods with hostNetwork: true. These are the primary objects you would later edit (in manifests or via kubectl) if you decide host networking is not justified.

# 4) Check for HostNetwork use in PodSecurityPolicy (if PSP is enabled)
kubectl get psp -o yaml | grep -nC3 hostNetwork

Problem indication: A PSP that either sets hostNetwork: true or does not restrict it allows Pods to request host networking. You must review whether such PSPs are appropriately scoped (e.g., only for system or network add-on namespaces).

# 5) If Pod Security Admission (PSA) is used, inspect namespace labels
kubectl get ns --show-labels

Problem indication: Namespaces with pod-security.kubernetes.io/enforce set to a level that permits host networking (or lacking restrictive labels) may allow hostNetwork: true. You must cross-check with your Pod Security configuration and policies, since kubectl cannot directly show the PSA-level hostNetwork rule.

# 6) For a specific namespace under review, list Pods and controllers using hostNetwork=true
NAMESPACE=default # replace with the namespace you are assessing
kubectl get pods,deploy,ds,sts,job,cronjob -n "$NAMESPACE" -o json \
| jq '.items[] | select(.spec.hostNetwork==true) |
{kind:.kind, namespace:.metadata.namespace, name:.metadata.name}'

Problem indication: Any listed workloads in that namespace are using host networking; these require human judgement on whether that is acceptable for that namespace’s security posture.

Automation
#!/usr/bin/env bash
# Purpose: Report pods, workloads, and (if present) PSPs that allow or use hostNetwork=true
# Run on: any machine with kubectl access and current-context set to target cluster

set -euo pipefail

echo "=== 1) Pods currently running with hostNetwork: true ======================="
kubectl get pods --all-namespaces -o jsonpath='{range .items[?(@.spec.hostNetwork==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.serviceAccountName}{"\n"}{end}' \
| sort || true
echo
echo "If any lines are printed above, those pods are using hostNetwork=true and must be reviewed."

echo
echo "=== 2) Workloads whose pod templates set hostNetwork: true ================="
echo "--- Deployments ---"
kubectl get deploy --all-namespaces -o json \
| jq -r '.items[]
| select(.spec.template.spec.hostNetwork == true)
| [.metadata.namespace, .metadata.name, (.spec.template.spec.serviceAccountName // "default")]
| @tsv' | sort || true

echo "--- DaemonSets ---"
kubectl get daemonset --all-namespaces -o json \
| jq -r '.items[]
| select(.spec.template.spec.hostNetwork == true)
| [.metadata.namespace, .metadata.name, (.spec.template.spec.serviceAccountName // "default")]
| @tsv' | sort || true

echo "--- StatefulSets ---"
kubectl get statefulset --all-namespaces -o json \
| jq -r '.items[]
| select(.spec.template.spec.hostNetwork == true)
| [.metadata.namespace, .metadata.name, (.spec.template.spec.serviceAccountName // "default")]
| @tsv' | sort || true

echo
echo "Any entries above indicate workload specs that request hostNetwork=true and should be justified or changed."

echo
echo "=== 3) (If present) PodSecurityPolicies allowing hostNetwork ================="
if kubectl api-resources | awk '{print $1}' | grep -q '^podsecuritypolicies$'; then
kubectl get podsecuritypolicies.policy -o json \
| jq -r '.items[]
| select(.spec.hostNetwork == true or .spec.hostNetwork == null)
| [.metadata.name,
(if .spec.hostNetwork == true then "hostNetwork:true"
elif .spec.hostNetwork == null then "hostNetwork:omitted"
else "hostNetwork:false" end)]
| @tsv' | sort || true

echo
echo "PSPs listed above either explicitly allow hostNetwork (hostNetwork:true)"
echo "or omit the field (hostNetwork:omitted). These should be reviewed and tightened."
else
echo "PodSecurityPolicy is not enabled in this cluster; skip PSP review."
fi

echo
echo "=== 4) Namespaces with pods using hostNetwork:true (summary) ================"
kubectl get pods --all-namespaces -o json \
| jq -r '
[ .items[]
| select(.spec.hostNetwork == true)
| .metadata.namespace ]
| sort
| unique[]
' 2>/dev/null || true

echo
echo "Any namespaces listed above currently contain at least one pod with hostNetwork:true."
echo "Review these namespaces and workloads to decide where hostNetwork usage is strictly necessary."

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

  • Section 1: Any printed pod line (<namespace> <pod-name> <serviceAccount>) means that pod is running with hostNetwork: true and must be reviewed.
  • Section 2: Any listed Deployment/DaemonSet/StatefulSet has spec.template.spec.hostNetwork: true and is configured to use host networking; this is a policy/configuration issue even if pods are not currently running.
  • Section 3 (if PSP exists): Any PSP shown as hostNetwork:true or hostNetwork:omitted allows hostNetwork; PSPs should normally enforce hostNetwork: false unless there is a clear exception.
  • Section 4: Any namespace listed contains at least one pod with hostNetwork: true and should be prioritized for review.

Use this report to manually decide which workloads truly require host networking and where to tighten policies/manifests; this control cannot be fully auto-remediated.

Additional Reading:​