Belajar Firecracker - Security Model & Hardening

#Pendahuluan

Di episode 7 kita memasang jailer; di episode 13 kita mengisolasi jaringan. Episode 14 merangkai semuanya menjadi satu model keamanan yang utuh — dan menutup celah yang sering dilupakan operator.

Mengapa episode ini penting? Firecracker dipakai untuk workload untrusted: kode dari pengguna yang tidak kita percaya. Seluruh nilai produk serverless bergantung pada seberapa dalam kita memahami threat model-nya — apa yang dilindungi, dari siapa, dan dengan mekanisme apa. Episode ini adalah episode yang membedakan sandbox yang benar-benar aman dari sandbox yang sekadar terlihat aman.

#Isolasi Hardware KVM vs Container Escape

Pertanyaan yang paling sering disalahpahami: apa bedanya container dan microVM secara keamanan?

• Container berbagi kernel host. Isolasi bergantung pada namespace, cgroup, seccomp, dan kapabilitas Linux. Jika ada bug di kernel (CVE di namespace atau LSM), semua container di host terkena.
• MicroVM menjalankan kernel guest sendiri di bawah KVM. Isolasi bergantung pada perangkat keras virtualisasi. Untuk menembus, penyerang harus melompati dua lapis: kernel guest → hypervisor (KVM + Firecracker) → kernel host.

Escape dari container adalah "naik level" satu kernel. Escape dari microVM adalah menembus dua kernel dan hypervisor — permukaan serangan yang jauh lebih sempit. Inilah mengapa AWS pindah dari multi-tenant container ke VM-level isolation untuk Lambda: margin keamanan yang jauh lebih lebar.

Tapi margin itu hanya nyata jika Firecracker sendiri diperlakukan sebagai kode yang bisa ditembus. Di situlah hardening masuk.

#Seccomp Profile: Whitelist Syscall

Seccomp membatasi syscall yang boleh dipanggil proses Firecracker. Firecracker mengirimkan profil seccomp ketat saat start — hanya syscall yang dibutuhkan VMM yang diizinkan, selebihnya ditolak dengan SIGSYS.

Praktik hardening seccomp:

• Jangan longgarkan profil tanpa alasan kuat. Setiap syscall tambahan adalah serangan yang mungkin.
• Uji workload di profil standar dulu; jika ada syscall yang benar-benar dibutuhkan, tambahkan secara eksplisit dan dokumentasikan.
• Perhatikan arsitektur: profil berbeda antara x86_64 dan aarch64 — jangan menyalin profil antar arsitektur.

Profil seccomp Firecracker disimpan di direktori binary dan dipilih sesuai arsitektur. Verifikasi bahwa jailer memuatnya:

ps -o pid,comm,seccomp,user -C firecracker

Kolom seccomp bernilai 2 (filter mode) berarti profil aktif.

#Landlock dan LSM

Seccomp membatasi syscall; LSM (Linux Security Modules) dan Landlock membatasi akses objek — file, direktori, jaringan. Landlock memungkinkan proses membatasi akses filesystem ke whitelist tanpa root: proses Firecracker hanya bisa membaca file yang seharusnya (kernel, rootfs) dan tidak bisa menyentuh sisanya.

Kombinasi ideal:

• Seccomp: membatasi apa yang bisa dilakukan (syscall).
• Landlock: membatasi apa yang bisa dijangkau (filesystem).
• Namespace + chroot: membatasi dunia tempat ia hidup.

Ketiganya bersama adalah lapisan yang tumpang tindih — satu gagal, dua lainnya masih menahan. Ini esensi defense-in-depth.

#Jailer sebagai Defense-in-Depth

Jailer (episode 7) bukan alternatif seccomp — ia pelengkap. Jika seccomp adalah jaring pengaman di level syscall, jailer adalah penjara di level proses: namespace jaringan terpisah, cgroup sendiri, user non-root, chroot, rootfs read-only.

Model keamanan final Firecracker untuk workload untrusted:

1. Guest diisolasi oleh KVM dari proses Firecracker.
2. Proses Firecracker dikurung jailer (namespace, cgroup, chroot, read-only).
3. Syscall dibatasi seccomp.
4. Akses objek dibatasi LSM/Landlock.

Jika guest di-tembus → ia masuk ke proses Firecracker → bertemu seccomp dan jailer → tidak bisa menulis file, tidak bisa syscall berbahaya, tidak punya privilege. Host tetap utuh.

#Kebiasaan Patch CVE

Keamanan tidak pernah selesai. Firecracker secara rutin menerbitkan perbaikan — contoh terbaru: v1.16.1 (2 Juli 2026) memperbaiki CVE-2026-5747 di validasi inisialisasi virtio PCI. Pelajaran dari CVE semacam ini:

• Selalu ikuti rilis: pantau halaman release dan CHANGELOG resmi.
• Pahami dampak: CVE-2026-5747 berkaitan dengan device virtio — validasi yang tidak sempurna bisa dimanfaatkan guest. Severity menentukan kecepatan patch.
• Jadwalkan rolling update: cluster multi-node bisa di-patch bertahap tanpa downtime; tapi jangan menunda versi yang memperbaiki CVE kritis.
• Catat versi yang dipakai: inventaris versi Firecracker + jailer per node mempermudah audit dan rencana patch.

CVE adalah bagian tak terhindarkan dari menjalankan sandbox. Yang membedakan operator profesional adalah ritme: monitor → triase → patch → verifikasi.

#Prinsip Hardening Produksi

Checklist yang bisa diterapkan langsung:

1. Jangan beri CAP_NET_ADMIN global — TAP dan namespace per VM, bukan hak global di host. Jika satu VM disusupi, ia tidak boleh menciptakan interface sendiri.
2. Minimal device — hanya pasang device yang dipakai workload. Tidak butuh vsock? Jangan aktifkan. Setiap device adalah permukaan serangan.
3. Deny hardware passthrough — kecuali didukung kernel dengan mekanisme yang jelas (misal VFIO dengan isolasi), jangan expose device host ke guest.
4. Rootfs read-only — guest tidak boleh memodifikasi sistemnya.
5. Network deny-by-default — hanya route yang dibutuhkan workload.
6. Rate limiter di semua device I/O — mencegah satu VM menjatuhkan host dengan I/O flood.
7. Isolasi control plane — API socket hanya bisa diakses oleh proses yang berhak (permission file socket yang ketat).

#Common Pitfalls

• Menjalankan Firecracker sebagai root: menghapus seluruh manfaat jailer — selalu non-root.
• Memakai profil seccomp arsitektur salah: profil x86_64 di host aarch64 tidak aktif atau crash.
• TAP di namespace host dengan hak global: berikan hak per-VM, bukan CAP_NET_ADMIN global.
• Melewatkan rilis keamanan: CVE tidak dipatch → sandbox lemah; pantau rilis rutin.
• Device berlebih: vsock, entropy, balloon yang tidak dipakai adalah serangan yang tidak perlu.

#Penutup

Inti yang harus dibawa pulang:

• MicroVM menambahkan lapisan isolasi hardware KVM di atas isolasi container.
• Seccomp membatasi syscall; Landlock membatasi akses objek; keduanya saling melengkapi.
• Jailer adalah defense-in-depth yang berasumsi VMM bisa ditembus.
• Patch CVE adalah ritme wajib — contoh: CVE-2026-5747 di v1.16.1.
• Hardening: tanpa CAP_NET_ADMIN global, minimal device, deny passthrough, rootfs read-only, rate limiter.

Di episode 15 selanjutnya kita akan melihat arah masa depan keamanan Firecracker: Confidential Computing & Trusted Guests — attestation dan VM tepercaya, posisi Firecracker terhadap ekosistem Kubernetes, keterbatasan yang masih ada, serta distribusi secret yang aman lewat MMDS dan TLS tanpa mengekspos metadata ke internet.