Mengira Celah Kernel Linux Tidak Berdampak ke Aplikasi di Docker

Banyak pengelola server mengira bahwa memasukkan aplikasi ke dalam container Docker otomatis membuat sistem host aman dari celah keamanan. Anggapan ini biasanya muncul karena container terasa seperti virtual machine kecil yang punya filesystem, network interface, dan proses tersendiri. Padahal, batas pemisah container bukan dinding isolasi hardware, melainkan fitur isolasi proses biasa di level sistem operasi. Ketika celah keamanan ditemukan pada kernel Linux, ilusi pemisahan tersebut langsung runtuh. Container tidak membawa kernel sendiri; semua container di sebuah server berbagi satu kernel yang sama dengan sistem host. Jika kernel memiliki kelemahan yang memungkinkan eskalasi hak akses lokal (local privilege escalation atau LPE), penyerang yang berhasil masuk ke dalam satu container bisa menembus dinding pembatas dan mengambil kendali penuh atas sistem host.

Kenapa container tidak sama dengan virtual machine

Di meja bantuan hosting, pertanyaan seputar isolasi container sering muncul saat tim teknis atau pemilik server bingung mengapa server utama mereka bermasalah setelah aplikasi di salah satu container mengalami gangguan. Perbedaan mendasarnya ada pada arsitektur virtualisasi. Virtual machine berbasis hypervisor seperti KVM menjalankan salinan kernel Linux yang sepenuhnya independen di dalam tiap mesin tamu. Jika kernel di dalam VM bermasalah, kerusakan atau eksploitasi umumnya tertahan di VM tersebut. Container Docker bekerja dengan cara yang sangat berbeda. Docker menggunakan fitur bawaan kernel Linux seperti namespaces untuk menyembunyikan proses lain dan cgroups untuk membatasi penggunaan sumber daya. Kita pernah membahas bagaimana cgroups mengatur alokasi ini secara rinci di artikel mengenai manajemen sumber daya cgroups v2. Namun, fitur-fitur ini bukan sandbox keamanan mutlak. Syscall (panggilan sistem dari program ke kernel) yang dijalankan oleh aplikasi di dalam container tetap diproses langsung oleh kernel host yang sama. Begitu ada bug pada subsistem memori kernel atau driver tertentu, syscall yang dieksekusi dari dalam container berinteraksi langsung dengan kode kernel yang bermasalah. Ketika celah LPE berhasil dimanfaatkan, penyerang tidak hanya menjadi root di dalam container, tetapi juga root di sistem host. Istilah teknis untuk kondisi ini adalah container breakout.

Risiko mitigasi darurat dan modul kernel

Saat celah kernel baru diumumkan sebelum paket pembaruan resmi (patch) dirilis oleh distro seperti Ubuntu atau Debian, vendor sistem operasi sering kali memberikan saran mitigasi sementara. Mitigasi ini umumnya berupa perintah untuk menonaktifkan atau mem-blacklist modul kernel tertentu yang menjadi sumber kerentanan, misalnya modul kriptografi perangkat keras seperti algif_aead. Langkah mitigasi darurat ini terdengar sederhana, tetapi membawa risiko regresi aplikasi yang cukup besar. Jika aplikasi web atau service di dalam container kita bergantung pada fungsi kriptografi kernel tersebut dan tidak memiliki mekanisme fallback (pengalihan otomatis) ke fungsi user-space, aplikasi bisa langsung berhenti bekerja atau melempar error koneksi. Pengelola server akhirnya dihadapkan pada pilihan sulit: membiarkan modul aktif dengan risiko keamanan celah kernel, atau mematikan modul tetapi memicu downtime pada layanan. Selain itu, mitigasi sementara sering kali membutuhkan reboot server agar konfigurasi modul benar-benar bersih dari memori kerja kernel. Menunda reboot sama saja dengan membiarkan celah tersebut tetap terbuka bagi penyerang yang menggunakan skrip eksploitasi otomatis.

Untuk memahami bagaimana container dan host berbagi kernel secara nyata, kamu bisa mengujinya langsung di VPS pengujian. Pemeriksaan sederhana ini membuktikan bahwa versi kernel dan arsitektur yang dilihat oleh aplikasi di dalam container identik dengan milik host. Jalankan perintah berikut di terminal host, lalu bandingkan hasilnya dengan perintah yang dijalankan di dalam container:

BASH

# Periksa versi kernel pada host
uname -r

# Jalankan container alpine dan periksa kernel yang terbaca di dalamnya
docker run --rm alpine uname -r

Kedua perintah di atas akan menghasilkan baris versi kernel yang persis sama. Jika host menjalankan kernel yang rentan terhadap bug memori, container alpine yang sangat ramping sekalipun akan memproses panggilan sistemnya lewat kernel yang rentan tersebut. Langkah berikutnya adalah memastikan container tidak berjalan dengan izin yang berlebihan. Docker secara default memblokir beberapa syscall berbahaya lewat seccomp profile, tetapi kebiasaan buruk yang sering ditemukan adalah menambahkan opsi --privileged saat menjalankan container agar konfigurasi terasa mudah. Menjalankan container dengan opsi --privileged sama saja dengan mematikan hampir seluruh mekanisme pembatasan bawaan Docker. Kamu bisa membatasi risiko serangan dengan prinsip least privilege, yaitu mencabut kapabilitas Linux (Linux capabilities) yang tidak dibutuhkan oleh container aplikasi web:

BASH

# Menjalankan container dengan mencabut seluruh kapabilitas default,
# lalu hanya memberikan hak akses yang benar-benar dibutuhkan
docker run -d \
  --name web-app \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --read-only \
  nginx:alpine

Pengaturan di atas mencabut semua izin sistem dan hanya menyisakan kapabilitas untuk mengikat port jaringan standar. Jika terjadi celah kernel yang membutuhkan kapabilitas administrasi tertentu untuk dieksploitasi, container yang terkunci rapat seperti ini mempersulit penyerang untuk mengeksekusi payload secara mulus.

Membangun kebiasaan patching yang benar

Menjaga keamanan aplikasi berbasis container bukan sekadar rutin memperbarui base image Dockerfile. Pembaruan image container hanya memperbarui pustaka aplikasi di level user-space, bukan kernel yang menjalankannya. Di lingkungan produksi, patching kernel host dan perencanaan reboot terjadwal tetap menjadi garis pertahanan paling penting. Jika kamu mengelola workload multi-tenant di mana pengguna luar bisa menjalankan kode sembarang, pertimbangkan isolasi berbasis virtualisasi penuh atau microVM daripada sekadar mengandalkan container standar. Mengetahui batas kemampuan isolasi Docker membantu kita menentukan langkah mitigasi yang realistis tanpa rasa aman semu.