Workloads whose pods share the node's network namespace

Host networking removes the pod’s network boundary

A pod normally gets its own network namespace and IP address. With hostNetwork: true, described in the Pod API reference as using the host’s network namespace, the pod shares the node’s interfaces instead. It binds directly to the node’s addresses and competes for ports with everything else on the node; any hostPort must match the containerPort.

Network isolation weakens as well. The network policies page says NetworkPolicy behaviour for hostNetwork pods is undefined. In the most common implementation the plugin ignores them when matching pod selectors and treats their traffic as traffic from the node IP. The Pod Security Standards place spec.hostNetwork under Host Namespaces in the Baseline profile, allowed only when unset or false.

Finding pods on the host network

kubectl get deployments,statefulsets,daemonsets -A -o json | jq -r '
  .items[]
  | select(.spec.template.spec.hostNetwork == true)
  | "\(.kind) \(.metadata.namespace)/\(.metadata.name)"'

Running pods can also be listed directly, since spec.hostNetwork is a supported field selector:

kubectl get pods -A --field-selector spec.hostNetwork=true

One flag, outside the system namespaces

ZopNight reads the hostNetwork value recorded for each Deployment, StatefulSet and DaemonSet and fires when it is true. A workload where the value was not collected is skipped. The namespace must not be a system namespace, because cluster components and CNI or mesh agents there legitimately need host networking.

Namespaces that are never flagged

The exclusions are kube-system, kube-public, kube-node-lease, kubeadm, calico-system, tigera-operator, istio-system, linkerd, linkerd-viz, cilium and cilium-system, plus any namespace whose name starts with gke-managed- or aks-managed-. Agents installed elsewhere are checked like any other workload. Related container-level risks are covered by Privileged container and Container running as root.

A high-severity exposure without a saving

There is no dollar figure. The risk is a workload that shares the node’s network identity and sits outside the controls your NetworkPolicies are meant to provide.

Taking the workload off the host network

1. Ask why it was enabled. Common reasons are binding a fixed port or reaching node-local services.
2. Remove hostNetwork: true and expose the workload through a Service instead.
3. Avoid swapping it for hostPort; the Baseline profile disallows host ports too, unless they are restricted to a known list.
4. If an agent truly needs the host network, run it in a dedicated namespace with minimal privileges and document the exception.
5. Label application namespaces pod-security.kubernetes.io/enforce: baseline so new pods cannot turn host networking back on.