# Container With Host Network

> Setting `hostNetwork: true` puts a pod directly on the node's network stack, so NetworkPolicy no longer applies to it and it can bind any of the 65,535 node ports. ZopNight skips the 7 system namespace patterns where CNI and node agents legitimately need this.

Source: https://zop.dev/integrations/kubernetes/recommendations/container-with-host-network
Updated: 2026-08-19

---

## 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

```bash
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.