Belajar Kata Containers - Confidential Containers (CoCo)

#Pendahuluan

Semua episode sejauh ini melindungi workload dari tenant lain. Episode 11 menaikkan taruhan: melindungi workload dari host itu sendiri. Bayangkan menjalankan aplikasi yang mengolah data sangat sensitif di cloud milik penyedia lain — siapa yang bisa membaca memori aplikasi kalian? Administrator node? Hypervisor host? Dengan Confidential Containers, jawabannya: tidak ada — bahkan operator infrastruktur sekalipun.

Kata Containers menjadi fondasi Confidential Computing lewat dukungan TDX, SEV, dan SEV-SNP, dipakai lewat RuntimeClass kata-qemu-coco-dev yang sudah kita kenal di episode 4. Episode ini membedah cara kerjanya: enkripsi memori, attestation, measurement, dan bagaimana Kata mengintegrasikan semuanya.

#Konsep Confidential Computing

#Trusted Execution Environment

Confidential computing dibangun di atas TEE (Trusted Execution Environment): wilayah terisolasi di CPU di mana kode berjalan dengan memori terenkripsi. Data di memori microVM dienkripsi dengan kunci yang hanya bisa diakses prosesor — bukan hypervisor, bukan OS host, bukan penyedia cloud.

Dukungan hardware yang dipakai Kata:

• Intel TDX (Trust Domain Extensions): teknologi Intel untuk confidential VMs.
• AMD SEV dan SEV-SNP: Secure Encrypted Virtualization dengan Secure Nested Paging — memori VM terenkripsi dan integritas dijamin.

Perbedaan utamanya dengan isolasi biasa: episode-episode sebelumnya melindungi workload dari tenant lain. Confidential computing melindungi workload dari infrastructure — termasuk admin node, VMM, dan penyedia cloud.

#Peran Kata Containers

Kata sudah menjalankan workload di microVM. CoCo menambahkan: microVM tersebut dienkripsi dan hasilnya bisa di-attest. Kata memakai backend QEMU dengan dukungan confidential computing — RuntimeClass kata-qemu-coco-dev.

Nama RuntimeClass ini penting: coco merujuk Confidential Containers, dan dev menandakan bahwa fitur ini masih dalam tahap pengembangan/preview di beberapa platform. Jangan menganggapnya production-ready di semua penyedia.

#Cara Kerja: Enkripsi dan Attestation

#Enkripsi MicroVM

Ketika pod CoCo dibuat, microVM di-boot dengan memori terenkripsi. Prosesnya:

1. Pod memakai RuntimeClass kata-qemu-coco-dev.
2. QEMU membangun microVM dengan flag confidential computing (TDX/SEV-SNP).
3. Guest kernel boot dengan memori terenkripsi hardware.
4. Kata agent berjalan di dalam guest yang terenkripsi.

Guest image juga harus aman: image yang tidak terenkripsi bisa diintip saat disimpan di disk. CoCo memakai image yang ditandatangani dan diverifikasi sebelum guest dijalankan — menghubungkan langsung ke topik image trust di episode 15.

#Attestation dan Measurement

Attestation adalah proses membuktikan bahwa environment yang berjalan benar-benar aman. Ini adalah jantung CoCo: sebelum menerima data sensitif, klien harus yakin bahwa microVM menjalankan guest kernel yang benar, di hardware yang benar, dengan konfigurasi yang benar.

Caranya lewat measurement: hardware mencatat "sidik jari" kriptografis dari image dan konfigurasi guest. Attestation service membandingkan measurement ini dengan nilai yang diharapkan. Jika cocok, guest dianggap tepercaya dan data boleh dikirim.

Alur sederhananya:

1. Guest CoCo boot dan menghasilkan measurement.
2. Client meminta attestation ke service attestation.
3. Service memverifikasi measurement dan memberikan sertifikat/verdict.
4. Jika verdict positif, client mengirim data atau kunci ke guest.

Di sinilah keunikan CoCo dibanding sandbox biasa: bukan hanya isolasi, tapi bukti isolasi yang bisa diverifikasi pihak ketiga.

#Menjalankan Pod Confidential

Pod CoCo memakai RuntimeClass kata-qemu-coco-dev:

apiVersion: v1
kind: Pod
metadata:
  name: kata-coco-demo
spec:
  runtimeClassName: kata-qemu-coco-dev
  containers:
    - name: app
      image: quay.io/confidential-containers/demo-image:latest
      command: ["sleep", "3600"]

runtimeClassName: kata-qemu-coco-dev memerintahkan pod dijalankan dengan backend QEMU confidential. Perhatikan bahwa pod CoCo butuh node dengan CPU yang mendukung TDX atau SEV — node biasa tidak bisa menjalankannya.

#Kasus Penggunaan dan Keterbatasan

#Kapan CoCo Dipakai

• Cloud multi-tenant: menjalankan workload data sensitif di infrastruktur penyedia yang tidak dipercaya penuh.
• Regulasi dan compliance: bukti attestation untuk data yang diproses pihak ketiga.
• Model AI / data sensitif: melindungi model dan data training saat diproses di cloud bersama.
• Multi-party computation: beberapa pihak berbagi komputasi tanpa saling mempercayai infrastruktur.

#Keterbatasan

• Perangkat keras khusus: TDX dan SEV-SNP hanya di CPU tertentu; biaya dan ketersediaan jadi pertimbangan.
• Performa: enkripsi memori menambah overhead CPU.
• Kematangan fitur: ekosistem tooling dan dukungan penyedia masih berkembang; beberapa fitur masih preview.
• Kompleksitas: attestation, image signing, dan key management menambah beban operasional.

Penting bersikap jujur pada diri sendiri: CoCo menjawab ancaman yang sangat spesifik — host yang tidak dipercaya. Untuk sebagian besar cluster yang host-nya tepercaya (on-prem atau VPC terisolasi), isolasi Kata biasa di episode 4-10 sudah cukup. CoCo adalah lapisan tambahan untuk skenario dengan tingkat ancaman lebih tinggi.

#Verifikasi Dukungan

Untuk mengecek apakah node kalian mendukung confidential computing:

Cek dukungan TDX/SEV

grep -r tdx /proc/cpuinfo
grep -r sev /proc/cpuinfo
kata-runtime kata-env | grep -i confidential

grep -r sev /proc/cpuinfo menampilkan flag SEV jika CPU mendukungnya. kata-runtime kata-env | grep -i confidential memverifikasi bahwa konfigurasi runtime mengenali mode confidential.

#Penutup

Inti yang harus dibawa pulang:

• CoCo mengenkripsi memori microVM dengan TDX atau SEV/SEV-SNP.
• RuntimeClass kata-qemu-coco-dev memakai backend QEMU confidential.
• Attestation membuktikan guest berjalan dengan image dan konfigurasi yang benar.
• Measurement adalah sidik jari kriptografis yang diverifikasi service attestation.
• CoCo melindungi workload dari host — bukan hanya dari tenant lain.
• Fitur masih preview di banyak platform; uji di environment target.

Di episode 12 selanjutnya kita akan masuk ke debugging & troubleshooting — memakai kata-runtime list dan state, membaca log di /var/log/kata-containers/, masuk ke guest dengan kata-runtime exec dan debug console, serta mendiagnosis pod pending, OOM di VM, image pull, dan misconfig hypervisor.