Belajar Firecracker - Confidential Computing & Trusted Guests

#Pendahuluan

Sejauh ini kita melindungi host dari guest. Episode 15 membalik pertanyaannya: bagaimana guest bisa melindungi dirinya dari host? Ini dunia confidential computing — di mana VM bisa membuktikan identitas dan integritasnya, dan data di dalamnya tetap rahasia bahkan dari operator mesin.

Mengapa episode ini penting? Firecracker dirancang untuk workload untrusted — kode dari pengguna. Tapi ada kelas workload lain: data sensitif (finansial, kesehatan) yang butuh jaminan kriptografis bahwa hanya kode yang tepat yang bisa membacanya. Memahami posisi Firecracker di sini — apa yang sudah bisa, apa yang masih berkembang — adalah bagian dari menilai kelayakan platform untuk workload kalian.

#Konsep: Trusted Guest dan Attestation

Dalam model cloud biasa, host adalah "pemilik" dan guest harus mempercayainya. Confidential computing membaliknya: dengan perangkat keras khusus (misalnya AMD SEV-SNP, Intel TDX), memori guest bisa dienkripsi sehingga host (termasuk administrator dan hypervisor) tidak bisa membacanya. Guest bahkan bisa attestation — membuktikan ke pihak ketiga: "saya dijalankan pada hardware terpercaya, dengan image yang benar, di bawah pengaturan yang sah."

Alur attestation yang umum:

1. Guest dimulai pada hardware confidential.
2. Perangkat keras menghasilkan quote kriptografis — bukti identitas dan integritas VM.
3. Quote dikirim ke verifier (attestation service) bersama nonce.
4. Verifier memeriksa quote terhadap kebijakan dan mengeluarkan hasil: VM ini terpercaya atau tidak.
5. Berdasarkan hasil itu, secret dikeluarkan ke guest — dan hanya ke guest yang terverifikasi.

Attestation adalah fondasi dari "zero-trust compute": secret tidak lagi dikirim ke sebuah IP, melainkan ke sebuah bukti.

#Posisi Firecracker terhadap Ekosistem Kubernetes

Bagaimana Firecracker masuk ke dunia confidential computing? Ada dua dimensi:

• Sebagai VMM dalam rantai attestation: Firecracker bisa menjadi bagian dari solusi — VMM yang menjalankan guest di atas hardware confidential, dengan metadata boot (kernel, cmdline, rootfs) yang masuk ke dalam ukuran integritas. Jika image di-tamper, quote berubah dan attestation gagal.
• Sebagai bagian dari cluster Kubernetes: pola runtime class microvm (episode 12) bisa dikombinasikan dengan confidential workload — Pod dijalankan dalam microVM trusted, dan attestation dikelola oleh komponen seperti operator attestation di sisi control plane.

Ekosistem Kubernetes memiliki dukungan tumbuh untuk confidential containers (misal melalui kata-containers dengan hardware confidential). Firecracker sendiri tidak menjanjikan confidential computing end-to-end di luar kotak — tapi posisinya sebagai VMM ringan menjadikannya kandidat natural dalam stack tersebut.

#Keterbatasan Saat Ini: Kejujuran Teknis

Bagian penting dari evaluasi engineering adalah tahu batasnya:

• Firecracker bukan confidential VM penuh di semua versi: dukungan perangkat keras confidential (SEV/TDX) di ekosistem microVM masih berkembang. Sebelum berasumsi, cek dokumentasi dan versi.
• Attestation butuh komponen lain: Firecracker tidak menyediakan attestation service lengkap; kalian membangunnya di atas komponen (misal: mengukur metadata boot, memakai perangkat keras attestation).
• Performa: enkripsi memori dan overhead attestation menambah biaya; tidak semua workload perlu membayarnya.
• Ekosistem: dibanding kata-containers atau cloud-hypervisor, dukungan confidential di jalur Firecracker lebih muda.

Artinya: untuk kebutuhan confidential, evaluasi secara khusus. Firecracker bisa jadi bagian solusi, tapi belum tentu solusi lengkap — dan keputusan ini harus didasarkan pada pengujian, bukan pada keyakinan.

#MMDS: Secret Distribution yang Aman

Sementara confidential computing adalah masa depan, hari ini ada pola yang sudah aman dan praktis untuk mendistribusikan secret: MMDS (episode 6). Kunci keamanannya:

• Alamat link-local 169.254.169.254 tidak di-routing — metadata hanya bisa diakses guest itu sendiri, tidak bisa diakses guest lain atau internet.
• Firecracker intercepts request ke alamat itu di level device — tidak pernah keluar ke jaringan fisik.

Pola produksi distribusi secret dengan MMDS:

1. Guest boot, membaca dari MMDS: alamat secret store, token sementara, dan config server.
2. Guest menghubungi secret store (misal Vault) lewat TLS — koneksi terenkripsi, kredensial untuk memulai diambil dari metadata.
3. Secret asli diambil on-demand, bukan di-bake di image atau di-passing sebagai environment variable.

Kombinasi MMDS + TLS memberikan: jalur pengantar yang terisolasi (MMDS) + transport terenkripsi (TLS) + secret on-demand (secret store). Ini pola yang dipakai production — dan jangan pernah mengekspos MMDS ke internet (tidak mungkin secara teknis, tapi jangan juga menyetel routing yang membuka 169.254.169.254 ke luar).

#Membangun Pipeline Attestation Sederhana

Untuk memahami konsepnya di level praktik, alur mini yang bisa kalian bangun:

# 1. Guest membaca identitas dan nonce dari MMDS
TOKEN=$(curl -s http://169.254.169.254/latest/token)
# 2. Guest memanggil attestation service dengan buktinya
curl -s https://attest.example.com/verify -H "Authorization: Bearer $TOKEN"
# 3. Jika terverifikasi, guest menarik secret via TLS
curl -s https://vault.example.com/v1/secrets/db -H "X-Vault-Token: $TOKEN"

Alur di atas mengajarkan pola penting: guest membuktikan diri dulu, baru menerima secret. Nonce mencegah replay; TLS mencegah penyadapan; dan token di MMDS bisa dirotasi per boot.

#Common Pitfalls

• Menganggap Firecracker otomatis confidential: cek versi dan hardware; confidential computing butuh komponen di luar VMM.
• Secret di-bake di image: image immutable yang mengandung secret bocor saat image tersebar — selalu on-demand.
• MMDS dibuka ke jaringan: 169.254.169.254 adalah link-local; jangan pernah menambahkan route yang mengeksposnya.
• Attestation tanpa nonce: tanpa nonce, quote bisa di-replay; selalu sertakan nilai acak per request.
• Trust tanpa verifikasi: mengirim secret ke IP saja bukan zero-trust; verifikasi dulu, kirim kemudian.

#Penutup

Inti yang harus dibawa pulang:

• Confidential computing melindungi guest dari host lewat hardware dan attestation.
• Attestation: quote kriptografis → verifier → keputusan trust → pengeluaran secret.
• Firecracker bisa jadi bagian rantai attestation, tapi bukan solusi end-to-end di luar kotak.
• MMDS (169.254.169.254) adalah jalur metadata yang aman dan terisolasi.
• Pola produksi: MMDS untuk token, TLS ke secret store, secret on-demand dengan rotasi.

Di episode 16 selanjutnya kita akan mengukur semuanya: Testing & Performance Benchmark — mengukur waktu boot cold versus snapshot, overhead memori, throughput IOPS dan bandwidth, menjalankan load test dengan ribuan microVM per host, serta latihan failure injection untuk memvalidasi ketahanan platform.