None Network #

Di antara semua network driver yang ditawarkan Docker, none adalah yang paling sederhana secara konsep dan paling jarang dibahas secara serius. Saat container dijalankan dengan --network none, ia tidak punya network interface sama sekali — bukan bridge, bukan host, bukan overlay. Hanya ada satu interface: lo (loopback). Container benar-benar offline.

Pada pandangan pertama, ini terdengar tidak berguna. Untuk apa menjalankan container yang tidak bisa bicara ke siapa-siapa? Tapi justru di situlah letak kekuatannya: ada banyak workload yang justru tidak boleh bicara ke luar. Batch job yang memproses file lokal, security sandbox untuk menjalankan kode tidak terpercaya, hingga container yang sengaja dibuat terisolasi untuk audit — semua itu adalah use case ideal untuk none network.

Artikel ini membahas none network secara mendalam: cara kerjanya di level OS, kapan harus dipakai, kapan tidak boleh dipakai, dan bagaimana mengombinasikannya dengan pattern lain untuk isolasi ekstra. Pada akhirnya kamu akan paham mengapa mode yang terlihat “tidak berguna” ini justru salah satu alat keamanan paling tajam di Docker.

Apa Itu None Network? #

None network adalah mode di mana Docker tidak membuat interface jaringan untuk container. Tidak ada veth, tidak ada bridge, tidak ada IP address eksternal. Container hanya punya interface lo (loopback) yang selalu ada di semua sistem operasi Unix.

flowchart TB
    subgraph HOST["Docker Host"]
        H_NET[Network Host]
    end
    subgraph CT["Container (none network)"]
        LO[lo: 127.0.0.1]
    end
    HOST -. X no link .-> CT

Karakteristik utama:

• Tidak ada eth0, tidak ada IP address dari DHCP atau IPAM.
• Tidak bisa akses internet atau host network.
• Tidak bisa komunikasi dengan container lain, kecuali via filesystem atau stdin/stdout.
• Hanya bisa komunikasi internal lewat 127.0.0.1 (loopback) di dalam container itu sendiri.
• Tidak ada port mapping — tidak mungkin karena tidak ada interface.
• Isolasi jaringan maksimal — attack surface network = 0.

Loopback masih ada: localhost di dalam container menunjuk ke container itu sendiri, bukan ke host atau container lain. Ini berguna untuk aplikasi yang listen di 127.0.0.1 dan hanya boleh diakses secara internal (misal admin UI yang di-reverse-proxy lewat UNIX socket).

Cara Kerja di Level OS #

Untuk memahami none network, kamu perlu paham dua hal: bagaimana Docker biasanya membuat interface, dan apa yang tidak dilakukan pada mode none.

Saat Container Biasa Berjalan (Bridge) #

flowchart LR
    H_BR[bridge: docker0<br/>172.17.0.1] -->|veth| C_ETH[eth0: 172.17.0.2]
    H_BR -->|iptables NAT| H_ETH[eth0 host]

Docker membuat:

• veth pair — kabel virtual antara container dan host.
• Bridge interface — virtual switch yang menghubungkan banyak container.
• IP address dari subnet bridge.
• Route default lewat gateway bridge.
• iptables rules untuk NAT keluar dan DNAT masuk.

Saat Container di None Network #

flowchart LR
    C_LO[lo: 127.0.0.1]
    C_NO[eth0: TIDAK ADA]
    ROUTE[Route default: TIDAK ADA]

Docker membuat sangat sedikit:

• Loopback lo — selalu ada, hanya 127.0.0.1.
• Tidak ada veth — tidak ada kabel ke host.
• Tidak ada eth0 — tidak ada interface eksternal.
• Tidak ada route default — tidak ada cara untuk keluar.
• Tidak ada iptables rules untuk container ini — tidak ada yang perlu di-NAT.

Hasilnya, container adalah proses terisolasi total di level jaringan. Ia masih punya namespace sendiri (PID, mount, UTS, IPC), tapi network namespace-nya hanya berisi lo.

Cara Menjalankan Container dengan None Network #

# Cara CLI
docker run -d --network none --name isolated alpine sleep 3600

# Cek interface di dalam container
docker exec isolated ip addr show

Output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever

Hanya lo. Tidak ada eth0, tidak ada IP lain.

Cek routing:

docker exec isolated ip route

Output:

# (kosong - tidak ada route, termasuk default)

Cek konektivitas:

docker exec isolated ping -c 1 8.8.8.8
# ping: connect: Network is unreachable

docker exec isolated wget -qO- http://google.com
# wget: unable to resolve host address 'google.com'
# (DNS pun gagal karena tidak ada resolver)

DNS resolver tetap tidak ada: Bahkan DNS internal Docker (127.0.0.11) tidak aktif di none network. Container benar-benar terpisah dari semua sistem DNS. Semua dependency harus sudah ada di dalam image.

Docker Compose dengan None Network #

version: "3.9"
services:
  batch-processor:
    image: my-batch:v1
    network_mode: none
    volumes:
      - ./input:/data/input:ro
      - ./output:/data/output:rw

Container ini:

• Membaca file dari /data/input (volume).
• Memproses file secara lokal.
• Menulis hasil ke /data/output (volume).
• Tidak pernah bicara ke internet atau container lain.

Cocok untuk ETL offline, image processing, transcoding, atau workload apa pun yang bekerja purely on local data.

Use Case: Batch Job dan Offline Processing #

Batch job adalah use case paling jelas. Jika sebuah proses hanya butuh input/output file dan tidak butuh network, none network memberikan:

• Keamanan — tidak ada jalur data keluar tanpa sengaja.
• Performa — tidak ada overhead networking, container fokus pada CPU/disk.
• Predictability — batch job deterministik, tidak ada variabel “koneksi internet mati”.

Contoh konkret:

# Image processing pipeline
docker run --rm --network none \
  -v $PWD/photos:/photos:ro \
  -v $PWD/thumbs:/thumbs:rw \
  image-processor \
  --input /photos --output /thumbs --size 256x256

# Video transcoding
docker run --rm --network none \
  -v $PWD/videos:/videos:rw \
  jrottenberg/ffmpeg \
  -i /videos/input.mov -c:v libx264 /videos/output.mp4

# CSV ke Parquet
docker run --rm --network none \
  -v $PWD/data:/data:rw \
  csv-to-parquet:latest \
  --input /data/raw.csv --output /data/processed.parquet

Prinsip umum: Kalau batch job kamu bekerja sepenuhnya di filesystem, aktifkan --network none. Ini menghilangkan satu kelas masalah (network flakiness) dan satu vektor serangan (network exfiltration).

Use Case: Security Sandbox untuk Untrusted Code #

Salah satu use case paling bernilai: menjalankan kode yang tidak dipercaya dengan risiko minimal. Code injection, third-party scripts, ML model dari sumber tidak jelas — semua itu bisa dimasukkan ke container none network.

# Jalankan script dari user yang tidak dipercaya
docker run --rm --network none \
  --read-only \
  --tmpfs /tmp:size=10m \
  --cpus=1 --memory=256m \
  --user 1000:1000 \
  python:3.12-slim \
  python /mnt/user-script.py

Kombinasi none network + read-only + tmpfs + resource limit + non-root adalah pola sandbox terkuat di Docker. Ia tidak sempurna (ada risiko kernel exploit), tapi untuk ancaman application-level ia sangat efektif.

Defense in Depth #

flowchart TB
    A[Untrusted Code] --> B[Container]
    B --> C[none network]
    B --> D[read-only fs]
    B --> E[--user 1000]
    B --> F[--memory 256m]
    B --> G[--cpus 1]
    B --> H[--cap-drop ALL]

    style C fill:#dfd
    style D fill:#dfd
    style E fill:#dfd
    style F fill:#dfd
    style G fill:#dfd
    style H fill:#dfd

Tiap layer menambah isolasi. none network adalah layer yang menutup vektor network-based: data exfiltration, command & control callback, scanning internal services. Tanpa network, banyak serangan modern langsung gagal.

Use Case: CI/CD Build Step yang Tidak Perlu Network #

CI/CD sering menjalankan build step yang seharusnya tidak butuh internet. Image sudah di-pull, dependency sudah ter-cache. Build step yang download lagi adalah code smell — dan risiko security.

# GitHub Actions - build step tanpa network
jobs:
  build:
    runs-on: ubuntu-latest
    container:
      image: my-build-image:latest
      options: --network none
    steps:
      - uses: actions/checkout@v4
      - run: make build
      - run: make test

Dengan --network none, build step dijamin deterministik dan aman: tidak ada yang download binary tambahan, tidak ada yang fetch dependency yang tidak ter-cache. Kalau build berhasil, dependability-nya terjamin.

Bug yang umum diungkap oleh none network: aplikasi yang diam-diam fetch konfigurasi dari internet saat startup. Saat --network none diaktifkan, aplikasi crash karena tidak bisa reach endpoint. Ini pertanda arsitektur yang rapuh — konfigurasi harusnya embedded di image, bukan fetch runtime.

Use Case: Aplikasi dengan Sidecar Offline #

Pola menarik: sidecar container offline yang berjalan di mode none untuk melakukan housekeeping.

version: "3.9"
services:
  app:
    image: my-app
    networks: [app-net]
  
  audit-log:
    image: log-rotator
    network_mode: none
    volumes:
      - app-logs:/var/log/app:ro
      - archive:/archive:rw
    # Rotate log files tanpa network

audit-log membaca log dari volume, mengompresinya, menulis archive. Tidak perlu bicara ke siapa-siapa. Dengan none network, ia dijamin tidak akan tiba-tiba upload log ke luar.

Perbandingan dengan Bridge Network #

Jangan samakan none dengan “tidak ada network sama sekali”. Loopback 127.0.0.1 masih ada, dan aplikasi di dalam container masih bisa listen di port loopback (misal admin UI). Yang hilang adalah kemampuan keluar ke network lain. 127.0.0.1 adalah container itu sendiri, bukan host atau container lain.

Kapan None Network TIDAK Boleh Dipakai #

1. Aplikasi Web / API Server #

Web server butuh menerima request dan response. Tidak ada network = tidak ada request yang datang.

# ✗ Anti-pattern: web server tanpa network
docker run --network none -p 80:80 nginx
# Container jalan tapi tidak ada yang bisa konek
# -p diabaikan karena tidak ada interface

2. Database dengan Client dari Container Lain #

Database di none network = client tidak bisa konek. Database harus di bridge network yang sama dengan client-nya.

3. Service yang Butuh Update / Pull Image #

Container yang download sesuatu saat runtime (apt-get update, pip install, npm install) butuh network. Build dependency harus sudah ada di image.

4. Health Check via Network #

Health check lewat network (HTTP endpoint, TCP connect) tidak akan bekerja di none network. Pakai health check berbasis proses atau file.

services:
  worker:
    image: my-worker
    network_mode: none
    healthcheck:
      test: ["CMD", "test", "-f", "/tmp/worker.alive"]
      interval: 30s

Kombinasi dengan Network Manual (Advanced) #

Untuk kasus langka, kamu bisa tambah network secara manual ke container none setelah container running. Ini memberi kamu kontrol penuh kapan container boleh bicara ke network.

# 1. Buat container dengan none network
docker run -d --network none --name audit alpine sleep 3600

# 2. Saat perlu komunikasi, connect ke network (jika host network policy izinkan)
docker network connect bridge audit

# 3. Lakukan komunikasi
docker exec audit ping -c 1 172.17.0.3

# 4. Putuskan lagi
docker network disconnect bridge audit

Ini jarang dipakai, tapi berguna untuk:

• Emergency debugging — buka network sebentar, inspect, tutup lagi.
• Conditional connectivity — container normally offline, tapi aktifkan network untuk sync periodik.
• Privileged operations — admin bisa attach network saat troubleshooting.

Hati-hati: memberi network ke container none di production harus lewat kontrol yang sangat ketat. Ini salah satu pola yang sering dipakai attacker untuk escape sandbox. Audit setiap docker network connect ke container yang awalnya none.

Best Practice None Network #

✓ GUNAKAN none network jika:
  ✓ Batch job / offline processing
  ✓ Sandbox untuk untrusted code
  ✓ Build step CI/CD yang sudah deterministik
  ✓ Sidecar housekeeping (log rotation, metrics aggregation)
  ✓ Testing fault tolerance (cek app masih jalan tanpa network)
  ✓ Audit / compliance requirement (no network access)

✗ JANGAN gunakan none network jika:
  ✗ Aplikasi web/API/worker yang perlu menerima request
  ✗ Database dengan client
  ✗ Service yang butuh download dependency
  ✗ Health check berbasis network
  ✗ Container yang perlu sinkronisasi ke external system

Anti-Pattern yang Sering Terjadi #

1. Memakai None untuk Aplikasi yang Butuh Network #

# ✗ Anti-pattern: web server di none network
docker run -d --network none -p 80:80 nginx
# Container crash, port 80 host tidak menerima apa-apa

# ✓ Solusi: bridge + port mapping
docker run -d --network app-net -p 80:80 nginx

2. Lupa Bahwa DNS Juga Hilang #

# ✗ Anti-pattern: app yang fetch config dari internet
docker run --network none my-app
# App crash karena tidak bisa resolve "config.example.com"

# ✓ Solusi: embed config di image, atau pakai bridge

3. Berasumsi -p Bekerja di None Network #

# ✗ Anti-pattern: pakai -p tanpa network
docker run -d --network none -p 8080:80 my-app
# -p diabaikan. Container tidak bisa diakses.

# ✓ Solusi: gunakan bridge dengan -p, atau host network

None Network untuk Compliance dan Regulatory #

Beberapa industri punya regulasi yang secara eksplisit melarang container punya akses network. Finansial, healthcare, dan government punya requirement bahwa workload tertentu tidak boleh bicara ke external system sama sekali.

# Contoh: HIPAA-compliant processing pod
apiVersion: v1
kind: Pod
metadata:
  name: phi-processor
spec:
  containers:
  - name: processor
    image: phi-processor:v1
    securityContext:
      runAsNonRoot: true
      runAsUser: 1000
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]
    resources:
      limits:
        memory: "512Mi"
        cpu: "500m"
    volumeMounts:
    - name: data
      mountPath: /data
      readOnly: true
    - name: output
      mountPath: /output
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: phi-input
  - name: output
    persistentVolumeClaim:
      claimName: phi-output

Pada Kubernetes, kamu bisa enforce none network dengan NetworkPolicy yang deny semua egress, atau dengan podSelector kosong di policy. Hasilnya: container hanya bisa bicara lewat filesystem, sesuai regulasi.

Pattern compliance: Untuk workload yang memproses data sensitif (PHI, PII, financial data), gabungkan none network dengan read-only filesystem, runAsNonRoot, dan audit logging. Ini memberi jejak audit yang jelas: data masuk via volume, diproses, keluar via volume — tidak pernah leave the pod.

Ringkasan #

• None network = container tanpa network interface sama sekali (kecuali loopback). Tidak ada eth0, tidak ada IP, tidak ada route default, tidak ada iptables rules.
• Isolasi jaringan paling kuat di antara semua network mode. Attack surface network = 0.
• Cocok untuk: batch job offline, sandbox untrusted code, build step CI/CD deterministik, sidecar housekeeping, audit/compliance.
• Tidak cocok untuk: web server, database dengan client, service yang download dependency, health check berbasis network.
• DNS resolver juga hilang — 127.0.0.11 (Docker internal DNS) tidak aktif. Semua dependency harus embedded di image.
• Kombinasi keamanan: none network + --read-only + --user non-root + --cap-drop ALL + resource limit = sandbox terkuat di Docker.
• Kegunaan tak terduga: testing fault tolerance — jalankan app dengan none dan lihat apa yang rusak. Ini mengungkap hidden network dependency yang sering jadi sumber bug.
• Bisa ditambah network manual lewat docker network connect, tapi ini pattern advanced dan harus diaudit ketat.
• Anti-pattern: web server di none, lupa bahwa DNS juga hilang, pakai -p di none (diabaikan).
• Prinsip umum: kalau workload tidak butuh network, nonaktifkan network. Defaultnya adalah “least privilege” — buka hanya yang dibutuhkan.

← Sebelumnya: Host Network   Berikutnya: Port Mapping & Exposure →