Host Network #

Di antara semua network driver yang ditawarkan Docker, host adalah yang paling sederhana secara konsep — dan yang paling kontroversial secara implikasi. Saat container dijalankan dengan --network host, ia tidak punya network namespace sendiri. Container menggunakan network stack host secara langsung: interface eth0 host, port 80 host, routing table host, semuanya. Tidak ada NAT, tidak ada bridge, tidak ada port mapping. Container adalah “warga kelas satu” di jaringan host.

Implikasi langsungnya: container kehilangan satu fitur keamanan utama Docker — isolasi jaringan. Tapi sebagai gantinya, kamu dapat performa jaringan terbaik dan akses ke semua interface host. Untuk beberapa workload, trade-off ini sangat worth it. Untuk yang lain, ini adalah anti-pattern serius.

Artikel ini membahas host network secara mendalam: cara kerjanya di level OS, kapan harus dipakai (dan kapan tidak boleh dipakai), trade-off performa vs isolasi, dan pola penggunaan di production. Pada akhirnya kamu akan bisa membuat keputusan arsitektur yang tepat untuk kasusmu.

Apa Itu Host Network? #

Host network adalah mode di mana container tidak membuat network namespace baru. Ia berjalan di namespace host — namespace jaringan yang sama dengan proses host itu sendiri.

flowchart TB
    subgraph HOST["Docker Host - Network Namespace"]
        H_ETH0[eth0: 192.168.1.10]
        H_LO[lo: 127.0.0.1]
        H_PORT[Port 80, 443, 3000, dll]

        subgraph CT1["Container A (host net)"]
            C_ETH0[eth0: 192.168.1.10 - sama dengan host]
            C_PORT[Port 80 - sama dengan host]
        end

        subgraph CT2["Container B (host net)"]
            C_ETH0B[eth0: 192.168.1.10 - sama dengan host]
            C_PORTB[Port 8080 - sama dengan host]
        end
    end

Karakteristik utama:

• Container share network stack dengan host.
• Container lihat IP host sebagai IP sendiri (localhost = host’s localhost, eth0 = host’s eth0).
• Port container = port host — port 80 di container = port 80 di host. Tidak ada port mapping.
• Tidak ada NAT, tidak ada bridge, tidak ada veth — koneksi langsung ke physical network.
• Tidak ada isolasi jaringan — container bisa bind ke port yang sama dengan host, dan mereka akan konflik.

Konflik port adalah risiko utama. Kalau host sudah menjalankan nginx di port 80, kamu tidak bisa menjalankan container di host network yang juga listen di port 80. Container kedua akan crash dengan error “address already in use”.

Cara Kerja di Level OS #

Untuk memahami host network, kamu perlu paham network namespace dulu — konsep yang sudah dibahas di artikel Overview. Di Linux, setiap proses berjalan di dalam satu atau lebih namespace. Namespace jaringan memisahkan interface, routing table, dan iptables rule.

# Lihat network namespace yang ada
ip netns list
# (kosong untuk container normal - mereka di namespace anonymous)

# Lihat network namespace dari container host network
docker run --rm --network host alpine ip netns identify
# Akan error atau return "host" - container ada di namespace yang sama

# Lihat proses apa saja di namespace host
sudo ls -la /proc/1/ns/net
# Container host network akan symbolic link ke file yang sama

flowchart LR
    subgraph Normal["Container Normal (bridge)"]
        NS_C[Namespace: container-xyz]
        ETH_C[eth0: 172.17.0.2]
        VETH[veth pair]
    end
    subgraph Host["Container Host Network"]
        NS_H[Namespace: sama dengan host]
        ETH_H[eth0: 192.168.1.10]
        PHY[eth0 fisik host]
    end
    Normal --> VETH --> BR[bridge docker0]
    Host --> PHY

Pada mode bridge, Docker membuat namespace baru, interface virtual (veth), dan bridge untuk menghubungkan container. Pada mode host, tidak ada semua itu. Container “meminjam” namespace host secara langsung.

Ini juga yang menjelaskan kenapa port mapping tidak mungkin di host network: port mapping butuh iptables DNAT untuk meneruskan traffic dari port host ke container. Tapi di host network, traffic port 80 sudah langsung di-handle oleh proses di container — tidak perlu diteruskan.

Cara Menjalankan Container dengan Host Network #

# Cara CLI
docker run -d --network host nginx

# Docker Compose
services:
  nginx:
    image: nginx
    network_mode: host

Verifikasi container jalan di host network:

# Cek IP container - harus sama dengan host
docker run --rm --network host alpine ip addr show eth0

# Cek port yang di-listen oleh container
docker run --rm --network host nginx &
sleep 1
ss -tlnp | grep 80
# Akan muncul nginx di namespace host

Di macOS dan Windows Docker Desktop, host network tidak benar-benar pakai network host. Docker Desktop berjalan di VM Linux (karena container butuh Linux kernel), dan host network di VM itu — bukan di laptopmu. Ini sering mengecoh developer. Untuk testing host network beneran, kamu butuh Linux native.

Perbandingan dengan Network Mode Lain #

Bridge dengan NAT dan bridge forwarding menambah overhead kecil tapi terukur. Untuk ribuan koneksi per detik, perbedaan ini bisa signifikan. Host menghilangkan overhead itu semua.

Kapan Host Network Sebaiknya Digunakan #

1. High-Throughput Reverse Proxy #

Nginx atau Traefik yang harus handle ribuan request per detik. Overhead NAT dan bridge bisa terasa.

services:
  nginx:
    image: nginx:alpine
    network_mode: host
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro

Best practice industri: Untuk production dengan traffic tinggi, Traefik atau HAProxy di host network adalah pola umum. Mereka tidak butuh isolasi, dan mereka harus jadi “pintu utama” — efisien di sini sangat penting.

2. Network Monitoring & Sniffing #

Tool seperti Wireshark, tcpdump, atau intrusion detection system butuh akses ke semua traffic di host. Host network memungkinkan ini.

# Container dengan tcpdump yang bisa sniff semua traffic host
docker run -it --rm --network host --cap-add=NET_ADMIN nicolaka/netshoot tcpdump -i any

3. DNS Server atau DHCP Server #

Container yang harus bind ke port 53 (DNS) atau 67/68 (DHCP). Port ini sering di-handle langsung oleh host daemon (systemd-resolved), dan host network memudahkan integrasi.

4. Service Discovery Tools #

Consul agent, etcd, atau Prometheus node exporter — biasanya jalan di host network untuk meng-collect metric dari host itu sendiri.

services:
  node-exporter:
    image: prom/node-exporter
    network_mode: host
    pid: host  # agar bisa baca proses host juga

5. Game Server atau Real-Time Application #

Game server (Minecraft, Counter-Strike, dll) butuh latency serendah mungkin. NAT dan bridge menambah mikrodetik yang bisa terasa di gameplay.

docker run -d --network host \
  -e EULA=TRUE \
  itzg/minecraft-server

6. BuildKit atau CI/CD #

Docker-in-Docker (DinD) sering butuh host network agar build cache dan registry lokal bisa diakses tanpa overhead.

Kapan Host Network Tidak Boleh Digunakan #

1. Multi-Tenant Environment #

Kalau host dipakai banyak user atau proyek, host network memungkinkan container mendengarkan traffic dari container/proses lain di host. Ini pelanggaran isolasi serius.

2. Production Microservices #

Aplikasi microservices modern biasanya terdiri dari banyak service. Kalau semuanya pakai host network, port conflict adalah mimpi buruk.

# ✗ Anti-pattern: semua service pakai host network
service_a (port 8080)
service_b (port 8080)  # CONFLICT!

# ✓ Solusi: bridge network + port mapping
service_a -p 8080:8080
service_b -p 8081:8080
# Tidak ada konflik

3. Database atau Service Sensitif #

Postgres, MySQL, Redis, MongoDB — service yang menyimpan data sensitif. Host network mengekspos mereka ke semua traffic di host, dan jika ada container lain yang menjalankan malicious code, ia bisa langsung akses database.

# ✗ Anti-pattern: database di host network
services:
  postgres:
    image: postgres
    network_mode: host
    # Port 5432 host = port 5432 container = bisa diakses semua proses di host

# ✓ Solusi: bridge internal network
services:
  postgres:
    image: postgres
    networks:
      - backend
  api:
    image: my-api
    networks:
      - backend
    depends_on:
      - postgres

networks:
  backend:
    internal: true

4. Application Multi-Container Standar #

Untuk aplikasi web biasa, API + database + cache, bridge network adalah default yang lebih aman dan cukup performant.

Implikasi Keamanan Host Network #

Karena container share network namespace dengan host, implikasi keamanannya serius:

flowchart TB
    CT[Container: host network] -->|lihat semua proses| PS[Proses host]
    CT -->|bind ke port apapun| PORT[Semua port host]
    CT -->|sniff traffic| SNIFF[Semua traffic di host]
    CT -->|bypass firewall| FW[iptables host - container sama]

    subgraph Host["Host"]
        PS
        PORT
        SNIFF
        FW
    end

• Process visibility — tanpa --pid=host, container hanya lihat prosesnya sendiri. Tapi dengan network=host saja, ia punya akses ke semua network host.
• Port binding — container bisa bind ke port manapun di host, termasuk port yang sudah dipakai. Crash atau takeover port.
• Traffic sniffing — dengan CAP_NET_RAW atau tcpdump, container bisa sniff semua traffic di host, termasuk HTTPS (well, tidak bisa baca content, tapi bisa lihat metadata).
• Firewall bypass — iptables Docker tidak berlaku. Container benar-benar warga host.

Jalankan container host network dengan image yang kamu percaya. Image dari Docker Hub random, apalagi dari publisher yang tidak jelas, jangan pernah dijalankan dengan --network host. Image itu bisa sniffer data, bind ke port SSH host, atau melakukan lateral movement ke service host lain.

Cara Mengamankan Host Network #

Kalau kamu tetap harus pakai host network, ada beberapa mitigasi:

# 1. Drop capabilities yang tidak dibutuhkan
docker run --network host --cap-drop=ALL --cap-add=NET_BIND_SERVICE nginx

# 2. Jalankan sebagai user non-root
docker run --network host --user 1000:1000 my-app

# 3. Pakai image minimal (alpine, distroless)
docker run --network host nginx:alpine

# 4. Read-only filesystem
docker run --network host --read-only nginx

# 5. Hindari mount sensitive directories
# JANGAN mount /proc, /sys, /var/run/docker.sock

Kasus terburuk: container dengan --network host -v /var/run/docker.sock:/var/run/docker.sock. Ini memberikan container akses penuh ke Docker daemon — ia bisa spawn container lain, membaca image, atau bahkan menghapus semuanya. Hindari kombinasi ini kecuali kamu benar-benar paham implikasinya (misal untuk tool management seperti Portainer).

Host Network dan Docker Compose #

Di Docker Compose, host network dideklarasikan dengan network_mode:

version: "3.9"
services:
  proxy:
    image: traefik:v3
    network_mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./traefik.yml:/etc/traefik/traefik.yml:ro
    command:
      - "--providers.docker=true"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"

Kamu juga bisa mix: beberapa service di host network, yang lain di bridge.

services:
  # Traefik di host - pintu masuk
  proxy:
    image: traefik
    network_mode: host

  # Backend services di internal network
  api:
    image: my-api
    networks:
      - internal

  db:
    image: postgres
    networks:
      - internal

networks:
  internal:
    internal: true

Pola ini sangat umum di production: Traefik/Nginx di host network untuk performa, backend services di internal bridge network untuk keamanan. Traefik menjadi satu-satunya yang terekspos.

Monitoring: Bandwidth dan Koneksi di Host Network #

Karena container share network dengan host, monitoring tradisional Docker (per-container network stats) tidak berlaku. Kamu pakai network stats host saja.

# Lihat traffic per interface host
iftop -i eth0
nethogs
bmon

# Lihat koneksi aktif
ss -tunap

# Container stats
docker stats --no-stream
# Network IO container = sama dengan host untuk host network

# Prometheus scrape config untuk host network container
scrape_configs:
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['localhost:9100']  # node-exporter jalan di host

Anti-Pattern: Tanda Bahwa Kamu Salah Pakai Host Network #

# ✗ Anti-pattern 1: database di host network
docker run -d --network host postgres
# Postgres terekspos ke semua interface host

# ✗ Anti-pattern 2: terlalu banyak service di host network
docker run -d --network host service-a
docker run -d --network host service-b
# Port conflict waiting to happen

# ✗ Anti-pattern 3: image tidak terpercaya di host network
docker run -d --network host some-random-image-from-internet
# Risiko keamanan sangat tinggi

# ✗ Anti-pattern 4: lupa bahwa host network disable iptables isolation
docker run -d --network host --publish 8080:80 nginx
# Port 8080 diabaikan! Container listen di port 80 host langsung

Kapan Harus Pindah dari Host Network #

Pakai signs ini sebagai panduan:

Benchmark: Seberapa Besar Perbedaan Host vs Bridge? #

Klaim “host network lebih cepat” sering disebut tapi jarang diukur. Berikut benchmark sederhana yang bisa kamu reproduksi sendiri.

# Install tool
docker run --rm --network host alpine apk add wrk
docker run --rm --network bridge alpine apk add wrk

# Jalankan nginx
docker run -d --name nginx-host --network host nginx
docker run -d --name nginx-bridge --network bridge -p 8080:80 nginx

# Benchmark host
wrk -t4 -c100 -d30s http://localhost:80

# Benchmark bridge (di terminal kedua)
wrk -t4 -c100 -d30s http://localhost:8080

Pada pengujian umum, perbedaan throughput antara host dan bridge untuk HTTP kecil (10–30%), tapi latency host network bisa 30–50% lebih rendah karena tidak ada extra hop NAT.

flowchart LR
    A[Client] -->|1 hop| B[Bridge]
    B -->|DNAT| C[Container]
    C --> B
    B --> A

    A2[Client] -->|0 hop| C2[Container di host net]
    C2 --> A2

Untuk workload yang sensitif terhadap latency (financial trading, real-time gaming, video streaming), perbedaan ini krusial. Untuk web app biasa, sulit terasa.

Catatan: di production dengan HTTPS, perbedaan host vs bridge mengecil karena TLS overhead mendominasi. Tapi untuk service internal (HTTP/2, gRPC, message broker), host network masih unggul signifikan.

Ringkasan #

• Host network = container share network namespace dengan host. Tidak ada bridge, NAT, veth, atau port mapping. Container lihat IP host, port host, dan interface host.
• Performa terbaik, tapi isolasi hilang. Trade-off utama: performance vs security.
• Cocok untuk: reverse proxy high-throughput, network monitoring, DNS/DHCP server, game server, real-time apps, service discovery agents.
• Tidak cocok untuk: multi-tenant, microservices banyak service, database sensitif, image tidak terpercaya, aplikasi multi-container standar.
• Risiko keamanan: container bisa sniff traffic, bind ke port apapun, bypass firewall iptables Docker. Jalankan hanya image terpercaya dengan capability minimum.
• Default port conflict: dua container host network tidak bisa bind ke port yang sama. Ini bukan fitur, ini jebakan umum.
• Docker Desktop (macOS/Windows) tidak benar-benar pakai host network — container jalan di VM Linux, bukan di laptopmu. Untuk testing asli, pakai Linux native.
• Pola umum production: Traefik di host network + backend di internal bridge. Pintu masuk efisien, backend aman.
• Anti-pattern: database di host network, semua service di host network, image random di host network, lupa bahwa -p diabaikan saat host network.
• Monitoring container host network = monitoring host. Network stats per-container tidak tersedia.

← Sebelumnya: NAT   Berikutnya: None Network →