Workloads sharing the node network namespace outside system namespaces

What host networking actually removes

A pod with hostNetwork: true does not get its own network namespace. It uses the node’s.

Three protections disappear at once, and only the first is widely understood.

NetworkPolicy stops applying. Policies select pods by their pod IP. A host-networked pod has the node IP, so ingress and egress rules written against it match nothing. A default-deny namespace policy does not constrain this pod at all, yet the policy object still shows as applied.

Port binding becomes unrestricted. The container can listen on any port the node has free. Nothing reserves the kubelet’s port, the CNI’s, or a monitoring agent’s; the first process to bind wins.

Node-local services become reachable. Anything listening on 127.0.0.1 on that node (kubelet’s read-only endpoints, a metadata proxy, a local sidecar) is now localhost from inside the container.

The exclusions are deliberate, not gaps

Seven namespace patterns are skipped: kube-system, kube-public, kube-node-lease, calico-system, tigera-operator, gke-managed-* and aks-managed-*. CNI agents, kube-proxy and node monitoring genuinely require the host stack, and flagging them produces noise that trains people to ignore the whole category.

A workload outside those namespaces is a different matter. Application teams almost never need it, and it usually arrives copied from an example manifest rather than chosen.

hostPort is the narrower tool

Where the requirement is genuinely “reachable on the node’s IP at a known port”, a hostPort on the single container port does that, and leaves the pod’s own network namespace, and therefore its NetworkPolicy coverage, intact.

That distinction is the useful part of this finding. The answer is rarely “you cannot do this”; it is “you asked for one port and were given the whole stack”.

When the rule stays silent

No recommendation is produced when the discoverer did not capture a hostNetwork key for the workload at all. Absent metadata is treated as unknown, not as false, since the rule will not assert a security finding it cannot substantiate.

Listing pods with hostNetwork set to true

kubectl get pods -A -o json | jq -r '
  .items[] | select(.spec.hostNetwork == true)
  | select(.metadata.namespace | test("^(kube-|calico-system|tigera-operator|gke-managed|aks-managed)") | not)
  | "\(.metadata.namespace)/\(.metadata.name)"'

Enforce it cluster-wide with the Pod Security Standards restricted profile, which forbids hostNetwork outright. One namespace label beats auditing manifests forever.