Host network and Pod network — the trade-off and the consequences

A Pod with hostNetwork: true shares the node’s network namespace. The Pod’s IP is the node’s IP. The Pod sees the host’s interfaces, the host’s routes, and the host’s iptables. The use cases are narrow; the consequences are severe. This lesson walks the mechanism, the use cases, and the operational discipline of limiting host network usage.

What hostNetwork: true does

The Pod spec supports a hostNetwork field:

apiVersion: v1
kind: Pod
metadata:
  name: node-exporter
spec:
  hostNetwork: true
  containers:
    - name: node-exporter
      image: prom/node-exporter:1.7.0

When hostNetwork: true is set, the kubelet does not create a network namespace for the Pod. The Pod joins the host’s network namespace. The Pod’s IP is the node’s IP.

flowchart LR
    A[Pod A: eth0 host netns] --> B[Host eth0]
    B --> C[Node IP]
    D[Pod B: netns] -->|veth| E[cali*]
    E --> F[Bridge cni0]
    F --> B

The host network Pod can bind to the host’s ports directly. A Pod with hostPort: 9100 and the host’s network namespace is the same as a process binding to port 9100 on the host.

The use cases

The use cases for host network are narrow:

• Node-local agents: node-exporter, fluentd, logshippers that need to scrape node metrics or read node logs.
• CNI plugin agents: Calico’s calico-node, Cilium’s cilium-agent, Flannel’s kube-flannel.
• kube-proxy replacement: Cilium’s kube-proxy replacement runs in the host network namespace.
• Host-level networking: Pods that need to bind to specific host ports (e.g., a NodePort alternative).
• Network debugging: temporary Pods that need access to the host’s network stack.

The use cases are node-local or network-level. Application workloads should not run in host network mode.

The consequences

The host network mode has severe consequences:

• NetworkPolicy does not apply. A Pod in the host network namespace is on the host network, not on the Pod network. The NetworkPolicy selectors match Pods by their Pod IP, not by the host IP.
• The Pod can access the host network. The Pod sees the host’s interfaces, routes, and services. A compromised Pod is a compromised node.
• No NetworkPolicy isolation. The Pod can reach any service on the host, including services that bind to localhost (e.g., the kubelet’s HTTP endpoint).
• Port conflicts. The Pod binds to the host’s ports. A Pod that uses port 9100 on node-1 conflicts with another Pod that uses port 9100 on node-1.
• No Pod IP. The Pod’s status does not have a podIP field set. The Service cannot route to the Pod via the Pod IP.

The Pod Security Standards

The Pod Security Standards “restricted” profile rejects hostNetwork: true. The “baseline” profile allows it. The cluster operator can enforce the restricted profile at the namespace level:

apiVersion: v1
kind: Namespace
metadata:
  name: prod-app
  labels:
    pod-security.kubernetes.io/enforce: restricted

A Pod with hostNetwork: true in a restricted namespace is rejected by the admission controller.

The hostAliases alternative

For Pods that need to bind to specific host ports without the full host network, the cluster operator can use hostAliases and hostPort:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: app
      image: my-app
      ports:
        - containerPort: 8080
          hostPort: 8080

hostPort binds to the host’s port but the Pod remains in its own network namespace. The Pod’s IP is the Pod’s IP, but the host’s port is shared. The trade-off is that the Pod cannot use the host’s network interfaces; the Pod can only bind to the specific port.

The host network and the kubelet

The kubelet, on host network mode, does not invoke the CNI plugin’s ADD. The Pod skips the CNI entirely. The Pod’s network namespace is the host’s; the CNI’s view of the Pod is empty.

This means the CNI plugin cannot report the host network Pod’s IP. The Pod’s status is updated by the kubelet’s view of the Pod’s network namespace, which is the host’s network namespace.

The failure modes

The host network’s failure modes:

• Port conflict: two Pods bind to the same host port. The fix is to use the scheduler’s port spreading.
• Policy gap: NetworkPolicy does not apply. The fix is to enforce the Pod Security Standards.
• Compromised host: a compromised Pod is a compromised node. The fix is to limit the host network usage to node-local agents.
• Missing metrics: the Pod’s IP is not in the cluster’s metrics. The fix is to configure the metrics pipeline to use the host network.

The operational discipline

The host network’s operational discipline:

• Audit the host network usage. The cluster operator must enumerate every Pod with hostNetwork: true.
• Enforce the Pod Security Standards. The restricted profile rejects host network.
• Limit the host network to node-local agents. Application workloads should not be in host network.
• Monitor the host network Pods. The metrics are the same as the host’s metrics.
• Document the host network usage. The cluster operator must understand what runs in host network.
• Test the host network changes in staging. The host network is security-relevant; the test must cover the use cases.

Quiz

Production discipline

• hostNetwork is a security-relevant decision. A Pod with host network has no NetworkPolicy isolation.
• The use cases are narrow. Node-local agents, CNI agents, kube-proxy replacement.
• The Pod Security Standards restricted profile rejects hostNetwork: true. The cluster operator must enforce it at the namespace level.
• Audit the host network usage. The cluster operator must enumerate every Pod with host network.
• Limit the host network to node-local agents. Application workloads should not be in host network.
• Monitor the host network Pods. The metrics are the same as the host’s metrics.
• Document the host network usage. The cluster operator must understand what runs in host network.
• Test the host network changes in staging. The host network is security-relevant.