Belajar Kata Containers - Security Model & Trust Boundary

#Pendahuluan

Selama sebelas episode, kita membangun keyakinan bahwa microVM itu aman. Episode 13 menantang keyakinan itu — dengan cara yang sehat. Apa sebenarnya batas keamanan Kata? Pertanyaan ini harus dijawab jujur sebelum kalian menaruh workload untrusted di atasnya.

Pertanyaan kuncinya: "Do you trust the guest?" Kata memisahkan guest dari host di level hardware — tapi bukan berarti guest boleh dipercaya begitu saja. Episode ini membedah model ancaman Kata, menganalisis CVE nyata, dan menurunkan praktik hardening yang bisa langsung diterapkan.

#Model Ancaman Kata Containers

#Apa yang Dilindungi MicroVM

Model keamanan Kata berasumsi: host tepercaya, guest tidak tepercaya. Batas isolasi utama ada di hypervisor: sebuah exploit di guest seharusnya tidak menembus ke host kernel. Inilah yang dicapai isolasi hardware — kernel guest terpisah dari kernel host.

Yang dilindungi oleh model ini:

• Host kernel dari eksploitasi guest.
• Pod lain di node yang sama — tiap pod adalah microVM terpisah.
• Kerahasiaan data antar tenant di level memory.

#Apa yang Tidak Dilindungi

Model ini tidak melindungi:

• Node yang sudah dikompromikan: jika host sudah ditembus, ia mengendalikan VMM dan guest bisa diintip (kecuali CoCo di episode 11).
• Konfigurasi yang salah: misalnya device yang tidak perlu di-passthrough, atau image guest yang usang.
• VMM itu sendiri: kerentanan di QEMU/Cloud Hypervisor adalah jalur potensial host → guest atau sebaliknya.

Kata memberikan isolasi hardware yang kuat, tapi bukan tongkat ajaib. Sisanya adalah disiplin operasional — yang justru menjadi inti episode ini.

#Studi Kasus: CVE-2026-24834

#Kerentanan dengan Skor 9.4

Pada tahun 2026, komunitas Kata mengumumkan CVE-2026-24834 dengan skor CVSS 9.4 — kategori kritis. Inti kerentanannya: guest root bisa mengeksploitasi pmem/DAX untuk melarikan diri dari isolasi yang seharusnya dijaga microVM. "pmem/DAX" merujuk persistent memory dengan mode direct-access yang bisa memperlihatkan memori secara langsung ke device.

Apa artinya bagi model ancaman? Batas isolasi hardware tetap berdiri — namun konfigurasi internal tetap krusial. Eksposur perangkat yang tidak perlu (seperti pmem/DAX dalam kasus ini) membuka permukaan yang bisa dipakai guest untuk menyerang lebih jauh. Sebuah microVM bukan benteng otomatis; ia benteng yang membutuhkan perawatan.

#Patch dan Pelajaran

CVE-2026-24834 diperbaiki di Kata Containers 3.27.0. Pelajaran dari insiden ini:

• Patch rutin adalah wajib: versi yang tidak dipatch menahan kerentanan kritis.
• Kurangi permukaan: perangkat dan fitur yang tidak dipakai harus dimatikan.
• Baca changelog: rilis 3.x yang bulanan membawa perbaikan keamanan.

Cek versi yang berjalan di node:

kata-runtime version

kata-runtime version menampilkan versi runtime. Bandingkan dengan rilis terbaru dan daftar CVE — kalau versi kalian tertinggal jauh, itulah risiko pertama yang harus diselesaikan.

#Praktik Hardening

#Minimal Device

Prinsip paling sederhana dan paling efektif: ekspos hanya yang dibutuhkan. Semakin sedikit perangkat yang diberikan ke guest, semakin kecil permukaan serangan. Dari episode 5, pastikan konfigurasi tidak mengekspos device yang tidak perlu:

/etc/kata-containers/configuration.toml

[hypervisor.qemu]
# Disable unnecessary devices
enable_io_threads = false
disable_image_probe = true
 
# Only expose needed block devices
block_device_driver = "virtio-blk"

disable_image_probe = true mencegah probe yang tidak perlu pada image. Prinsipnya sama untuk passthrough: jangan passthrough GPU/NIC kecuali workload memang membutuhkannya.

#Non-Root dan Seccomp

Prinsip kedua: jangan berikan hak lebih dari yang dibutuhkan. Kata menyediakan opsi agar guest dijalankan dengan mode non-root dan seccomp di dalam guest:

apiVersion: v1
kind: Pod
metadata:
  name: kata-hardened
spec:
  runtimeClassName: kata
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: nginx:alpine
      securityContext:
        allowPrivilegeEscalation: false
        runAsNonRoot: true
        capabilities:
          drop: ["ALL"]

seccompProfile: RuntimeDefault menerapkan profil seccomp default, dan allowPrivilegeEscalation: false melarang eskalasi privilege. Meskipun aplikasi ada di dalam guest, prinsip least privilege tetap berlaku — guest yang terkunci lebih sulit dipakai untuk menyerang.

#Update Patch Rutin

Update bukan kegiatan "nanti". Karena Kata dirilis dengan cadence bulanan di seri 3.x dan versi besar di 4.x, jadwalkan update sebagai bagian dari operasional:

• Pantau rilis baru dan daftar CVE di halaman rilis GitHub.
• Uji upgrade di cluster staging sebelum production.
• Catat versi di setiap node agar bisa di-audit.

#Trust Boundary dalam Praktik

Model ancaman Kata bisa dirangkum dalam satu diagram mental:

• Host tepercaya — menjaga VMM, kernel host, dan infrastruktur.
• VMM — lapisan yang harus dipatch dan dikonfigurasi dengan minimal device.
• Guest tidak tepercaya — tapi tetap dikunci dengan seccomp, non-root, dan capability minimal.
• Image — harus berasal dari sumber tepercaya (episode 15).

Semua lapisan ini saling bergantung. Guest yang tidak tepercaya tetap kita kunci — bukan karena kita percaya padanya, tapi karena kita tidak ingin memberi amunisi. Ini pola pikir defense-in-depth yang akan berlanjut di episode 14 hingga 16.

#Penutup

Inti yang harus dibawa pulang:

• Model ancaman: host tepercaya, guest tidak tepercaya, batas isolasi di hypervisor.
• CVE-2026-24834 (9.4) menunjukkan konfigurasi internal tetap krusial meski isolasi hardware ada.
• Patch rutin itu wajib: versi tertinggal berarti menahan kerentanan kritis.
• Minimal device: ekspos hanya perangkat yang dibutuhkan workload.
• Non-root + seccomp + drop capabilities: kunci guest dengan least privilege.
• kata-runtime version adalah cek keamanan pertama yang harus dijalankan.

Di episode 14 selanjutnya kita akan membahas network security & policy — NetworkPolicy dengan CNI, egress filtering, identitas pod, dan data-in-transit dengan mTLS service mesh untuk workload di microVM. Network adalah tempat isolasi microVM paling sering diuji.