# CL-0008: Host Network Mode

**Severity:** HIGH

**References:**
- [OWASP Docker Security Rule #5](https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html#rule-5-be-mindful-of-inter-container-connectivity)
- CIS Docker Benchmark 5.10 — Ensure that the host's network namespace is not shared

## What it detects

Any service with `network_mode: host`. Other network modes (`bridge`, `service:`, custom networks) are not flagged.

## Why it matters

Host network mode disables Docker's network isolation entirely. The container:

- Shares the host's IP address and all network interfaces
- Can bind to any port on the host without publishing
- Can observe and capture all host network traffic
- Can communicate with services bound to `127.0.0.1` on the host
- Bypasses Docker network policies and inter-container firewalling

This is a significant isolation bypass — any network-based security boundary between the container and the host is removed.

## Fix

Remove `network_mode: host` and use bridge networking with explicit port mappings:

```yaml
services:
  web:
    image: nginx:1.27-alpine
    ports:
      - "127.0.0.1:8080:8080"
    networks:
      - app-network

networks:
  app-network:
```

For most workloads, Docker's default bridge driver is the right answer. There is some NAT/iptables overhead — connection-rate ceilings and a few percent of latency on small packets — but the isolation boundary is worth it. Only workloads that genuinely need to see host traffic (network monitoring, certain VPN agents, eBPF-based tools) require host networking.

`network_mode: host` is also the most-extreme version of CL-0005's iptables-bypass concern: port-publish rules don't apply, so anything the container binds is on the host's interfaces directly. UFW / firewalld will not protect those bindings.

## When to suppress

- Network-monitoring sidecars (cAdvisor, node-exporter, Netdata) that legitimately need host-namespace visibility.
- Userspace VPN agents that manage host routing tables.

In both cases suppress with a `reason:` naming the workload, and pair with `cap_drop`, `read_only`, and `no-new-privileges` to harden whatever isolation remains.

## See also

- [CL-0005](CL-0005.md) — port binding (irrelevant under host networking; the container is already on the host's interfaces)
- [CL-0010](CL-0010.md) — sibling host-namespace sharing for PID/IPC/UTS/userns
