Membongkar Mekanisme Container Leakage: Analisis Kerentanan Kernel Namespace dan Strategi Hardening Kubernetes Tingkat Lanjut

Dalam era komputasi modern, kontainerisasi telah menjadi standar emas untuk deployment aplikasi. Docker dan Kubernetes menawarkan isolasi yang andal, memfasilitasi skalabilitas instan dan portabilitas lintas lingkungan. Namun, di balik kemudahan orkestrasi tersebut, banyak pengembang yang salah kaprah menganggap kontainer setara dengan mesin virtual (VM) dalam hal batas keamanan.

Kontainer pada hakikatnya bukanlah bentuk virtualisasi perangkat keras, melainkan sekumpulan proses yang diisolasi menggunakan fitur bawaan kernel Linux seperti namespaces, cgroups, dan seccomp. Ketika batas-batas ini salah dikonfigurasi, risiko container leakage—di mana proses di dalam kontainer dapat keluar dari batas isolasi dan mengakses host—menjadi ancaman nyata.

---

Anatomi Isolasi Kernel: Di Mana Celah Terbuka?

Secara arsitektural, Docker dan Kubernetes bergantung pada kemampuan kernel Linux untuk mempartisi sumber daya sistem operasi. Komponen utamanya meliputi:

• Namespaces: Membatasi apa yang dapat dilihat oleh sebuah proses (PID, NET, MNT, IPC, UTS, USER, Cgroup).
• Control Groups (cgroups): Membatasi jumlah sumber daya yang dapat dikonsumsi oleh sekumpulan proses (CPU, memori, I/O disk).
• Capabilities: Memecah hak istimewa root tradisional menjadi unit-unit kecil yang dapat diberikan secara selektif.

Masalah keamanan muncul ketika kontainer dijalankan dengan hak istimewa berlebih (privileged mode), menggunakan namespace host, atau mengekspos soket Docker (/var/run/docker.sock) ke dalam kontainer aplikasi.

Skenario Bahaya: Hak Istimewa Berlebih (Privileged Mode)

Ketika Anda menjalankan kontainer dengan flag --privileged di Docker atau memberikan konteks keamanan privileged: true di Kubernetes, kernel hampir sepenuhnya menonaktifkan isolasi cgroups dan namespaces. Kontainer tersebut memiliki akses penuh ke perangkat keras host dan seluruh kapabilitas sistem.

apiVersion: v1
kind: Pod
metadata:
  name: insecure-pod
spec:
  containers:
  - name: app
    image: nginx:alpine
    securityContext:
      privileged: true # BAHAYA: Membuka akses penuh ke host kernel

Jika penyerang berhasil mengeksploitasi aplikasi web yang berjalan di dalam insecure-pod ini, mereka dapat dengan mudah memasang modul kernel berbahaya, membaca sistem file host secara langsung, atau melakukan eskalasi hak istimewa hingga mengambil alih seluruh node klaster.

---

Vektor Serangan Umum pada Ekosistem Kubernetes

Selain privileged mode, terdapat beberapa vektor serangan tersembunyi yang sering diabaikan oleh tim engineering:

1. Mounting Soket Docker (docker.sock): Banyak alat CI/CD (seperti Jenkins worker) yang melakukan Docker-in-Docker dengan me-mount /var/run/docker.sock ke dalam kontainer. Kontainer ini pada dasarnya memiliki kendali penuh atas daemon Docker host, memungkinkan mereka membuat kontainer baru dengan hak akses penuh ke host.
2. Eksploitasi Kernel yang Belum Di-patch: Karena kontainer berbagi kernel yang sama dengan host, kerentanan Zero-Day atau unpatched CVE pada kernel Linux (seperti celah pada subsistem netfilter atau io_uring) dapat dieksploitasi dari dalam kontainer untuk melakukan container escape.
3. Miskonfigurasi Capabilities: Memberikan kapabilitas berbahaya seperti CAP_SYS_ADMIN, CAP_NET_RAW, atau CAP_SYS_PTRACE secara sembarangan membuka celah bagi proses kontainer untuk memanipulasi jaringan atau melakukan debugging tingkat lanjut pada proses lain di luar batas isolasinya.

---

Strategi Hardening Tingkat Lanjut untuk Docker dan Kubernetes

Untuk memitigasi risiko container leakage, pendekatan pertahanan berlapis (defense-in-depth) mutlak diperlukan. Berikut adalah langkah-langkah mitigasi praktis yang dapat diterapkan:

1. Menerapkan Pod Security Standards (PSS)

Kubernetes menyediakan mekanisme Pod Security Standards (Privileged, Baseline, Restricted) untuk menegakkan kebijakan keamanan secara otomatis pada level namespace menggunakan Admission Controller.

apiVersion: v1
kind: Namespace
metadata:
  name: production-workloads
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Kebijakan restricted melarang konfigurasi berbahaya seperti penggunaan kontainer privileged, pelarangan root user, dan pengetatan akses volume mount.

2. Mengaktifkan Seccomp dan AppArmor/SELinux

Gunakan profil Seccomp (Secure Computing Mode) untuk memfilter system call yang dapat dilakukan oleh kontainer ke kernel. Secara default, Kubernetes menerapkan profil seccomp RuntimeDefault yang memblokir sejumlah besar system call berbahaya yang jarang digunakan oleh aplikasi web biasa.

securityContext:
  seccompProfile:
    type: RuntimeDefault

Selain itu, pastikan modul Mandatory Access Control (MAC) seperti AppArmor atau SELinux diaktifkan pada node klaster untuk memberikan lapisan pembatasan akses file dan jaringan yang independen dari kepemilikan UID/GID.

3. Prinsip Least Privilege pada Security Context

Selalu jalankan kontainer sebagai non-root user dan jatuhkan seluruh kapabilitas (drop all capabilities) kecuali yang benar-benar dibutuhkan oleh aplikasi.

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL
    add:
      - NET_BIND_SERVICE # Hanya jika butuh binding port di bawah 1024

---

Ringkasan

Keamanan kontainer bukanlah fitur bawaan yang aktif secara otomatis, melainkan hasil dari konfigurasi disiplin yang konsisten. Memahami cara kerja kernel namespace dan mematuhi prinsip Least Privilege dalam mendesain manifes Kubernetes adalah kunci utama untuk menutup celah container leakage sebelum dieksploitasi oleh pihak yang tidak bertanggung jawab. Evaluasi kembali klaster Anda hari ini untuk memastikan batas isolasi berjalan optimal.