Belajar Kata Containers - AI & Agent Sandboxes

#Pendahuluan

Dari semua kasus penggunaan yang dibahas sepanjang series ini, tidak ada yang lebih relevan dengan tahun-tahun terakhir selain AI agents. Agent-agen ini menjalankan tool, mengakses file, dan mengeksekusi perintah dari sumber yang tidak bisa dipercaya penuh. Setiap agent adalah potensi sandbox escape. Kata Containers memberi jawaban yang alami: jalankan setiap agent di microVM sendiri.

Episode 19 membahas pola ini secara nyata: menjalankan LLM inference di microVM dengan GPU via VFIO, membuat sandbox per agent dan per session, serta isolasi CI/CD yang mengeksekusi artefak pihak ketiga. Ini adalah topik yang sudah dibicarakan di OpenInfra Summit dan diadopsi platform seperti Northflank.

#Mengapa AI Agent Membutuhkan Sandbox

#Sifat Agent yang Tidak Bisa Dipercaya

AI agent modern bekerja seperti ini: model (LLM) memutuskan langkah, lalu mengeksekusi — menjalankan kode, memanggil API, membaca file, menginstall paket. Input yang memandu keputusan ini datang dari pengguna, dari konten web, atau dari tool yang berinteraksi dengan dunia nyata. Satu prompt jailbroken atau satu dokumen berbahaya bisa membuat agent menjalankan perintah yang merugikan.

Risikonya bukan teori — sudah banyak insiden di mana agent mengeksekusi kode berbahaya yang disisipkan di halaman web atau dokumen yang dibacanya. Container biasa memberi agent akses ke kernel bersama; satu escape berarti seluruh node berisiko.

#Perbedaan Sandbox Agent vs Sandbox Tradisional

Sandbox biasa mengisolasi input: menjalankan file yang tidak dikenal dan membuang hasilnya. Agent berbeda — ia aktif dan persisten: menjelajah, berinteraksi, dan bertahan lama. Isolasi yang dibutuhkan lebih ketat, dan microVM adalah jawaban yang paling sesuai.

Keuntungan microVM untuk agent:

• Kernel terpisah: escape dari proses agent tidak menembus kernel host.
• Egress terbatas: dengan policy episode 14, agent hanya bisa berkomunikasi ke endpoint yang diizinkan.
• Destroy-and-recreate: sandbox yang mencurigakan bisa dihancurkan total tanpa jejak.

#Menjalankan LLM Inference di MicroVM

#Workload Inference

LLM inference adalah workload komputasi yang menuntut GPU. Dengan Kata, kalian bisa menjalankan inference server (misalnya vLLM atau TGI) di dalam microVM dengan GPU yang di-passthrough via VFIO — kombinasi yang dibahas di episode 10.

Pola ini menarik karena dua alasan: input inference tidak bisa dipercaya (prompt dari pengguna berpotensi berbahaya), dan model itu sendiri bernilai (aset intelektual yang harus dilindungi). MicroVM mengisolasi keduanya: runtime model terlindungi dari prompt jahat, dan model terlindungi dari node.

Pod inference dengan GPU:

apiVersion: v1
kind: Pod
metadata:
  name: kata-llm
spec:
  runtimeClassName: kata
  containers:
    - name: inference
      image: vllm/vllm-openai:latest
      command: ["vllm", "serve", "/models/llama", "--port", "8000"]
      resources:
        limits:
          nvidia.com/gpu: 1
          memory: 32Gi

nvidia.com/gpu: 1 memberikan GPU ke microVM, dan seluruh server inference berjalan di dalam guest. Egress policy membatasi akses model ke endpoint yang diizinkan saja.

#Pola Sandbox per Agent dan per Session

#Sandbox per Agent

Pola paling sederhana: setiap agent mendapat pod/microVM sendiri. Satu agent, satu microVM, satu lifecycle. Ketika agent selesai atau mencurigakan, microVM dihancurkan — tidak ada state yang tersisa.

Pola ini dipakai oleh platform seperti Northflank dan divisualisasikan di OpenInfra Summit: sandbox per agent adalah unit isolasi paling natural. Agent tidak pernah berbagi kernel atau resource dengan agent lain.

#Sandbox per Session

Variasi yang lebih granular: setiap session interaksi mendapat sandbox baru. Sebuah agent yang berjalan lama bisa memulai session baru untuk setiap tugas yang melibatkan input tidak tepercaya — session yang mencurigakan dibuang tanpa mempengaruhi agent utama.

Keuntungannya: granularity isolasi mengikuti tingkat risiko input. Input tepercaya bisa diproses agent langsung; input mencurigakan masuk ke session sandbox baru.

Implementasi praktisnya tetap sederhana — pod baru per session:

kubectl apply -f - <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: agent-session-42
  namespace: sandbox
spec:
  runtimeClassName: kata
  containers:
    - name: executor
      image: sandbox-runner:latest
      env:
        - name: SESSION_ID
          value: "42"
EOF

kubectl apply -f - membuat pod sandbox session baru. Namespace sandbox sudah dijamin memakai Kata oleh admission policy (episode 15), jadi tidak ada risiko berjalan di runc.

#Resource dan Kadaluarsa

Sandbox per session menuntut pengelolaan resource yang disiplin:

• TTL: hancurkan sandbox secara otomatis setelah waktu tertentu.
• Quota: batasi resource per session (episode 16) agar satu session tidak menghabiskan node.
• Monitoring: pantau per-microVM (episode 16) untuk mendeteksi behavior mencurigakan.

#CI/CD Isolates

#Masalah CI/CD

CI/CD mengeksekusi kode yang tidak dipercaya secara fundamental — artefak dari kontributor, dependency dari internet, skrip build pihak ketiga. Menjalankan build di container biasa berarti setiap build punya akses ke kernel bersama. Satu dependency compromised bisa menyerang runner host.

Kata menyelesaikan masalah ini dengan pola yang sama: setiap build job berjalan di microVM. Build pipeline yang memakai Kubernetes (misalnya dengan Runner Kubernetes) cukup menandai pod sebagai sandboxed:

apiVersion: v1
kind: Pod
metadata:
  name: ci-job-1234
spec:
  runtimeClassName: kata
  restartPolicy: Never
  containers:
    - name: build
      image: builder:latest
      command: ["/build.sh"]

restartPolicy: Never — job sekali jalan, microVM dibuat untuk job ini, dihancurkan setelah selesai. Pola ini memberi isolasi penuh antar build tanpa mengorbankan kecepatan yang memadai (boot 150-300 ms).

#Egress untuk Build

Build membutuhkan akses ke registry dan repository — tapi tidak ke jaringan internal. Egress policy yang ketat (episode 14) membatasi build hanya ke endpoint yang dibutuhkan: registry image, package manager, dan source repo. Jika build mencurigakan mencoba akses lain, traffic di-block.

#Penutup

Inti yang harus dibawa pulang:

• AI agent mengeksekusi kode tak dikenal — microVM adalah sandbox yang paling sesuai.
• LLM inference bisa dijalankan di microVM dengan GPU via VFIO.
• Dua arah isolasi inference: runtime dari prompt jahat, model dari pengintipan.
• Pola sandbox per agent dan per session memberi granularity sesuai risiko input.
• CI/CD isolates: setiap build job berjalan di microVM dengan egress terbatas.
• TTL, quota, dan monitoring per-VM menjaga pola ini tetap sehat.

Di episode 20 selanjutnya kita akan membahas performance & optimization — hugepages, CPU pinning, memory balloon, optimasi boot time dengan Dragonball/CH, serta cara benchmarking boot time dan overhead per pod dibanding runc. Semua konsep dari episode 5 dan 6 akan dipakai untuk membuat microVM seefisien mungkin.