Praktik terbaik penahanan agen: sandboxing (beta pribadi)

Untuk pelanggan dalam Program Verifikasi Siber kami, kami menyediakan pengklasifikasi sandbox escape baru di API untuk memantau dan mengurangi penyalahgunaan. Artikel ini menjelaskan mengapa agen otonomi memerlukan isolasi yang kuat, bagaimana desain referensi mengisolasinya, dan cara menentukan cakupan serta mengawasi keterlibatan yang memerlukan akses jaringan.

Untuk ikhtisar semua sumber daya yang tersedia bagi Anda, lihat Praktik terbaik penahanan agen: memulai (beta pribadi).

Jika Anda membangun sandbox Anda sendiri, ini adalah properti yang disediakan desain referensi. Sisa artikel ini menjelaskan satu cara untuk mendapatkannya.

Jalankan agen otonomi dalam sandbox yang kuat, dan pikirkan efek samping apa yang masih dapat disebabkan oleh proses dalam sandbox tersebut. Model frontier semakin mahir menemukan jalur kreatif di sekitar pembatasan: properti yang sama yang membuat mereka menjadi pemburu kerentanan yang efektif berarti mereka mungkin mengambil tindakan yang tidak terduga terhadap lingkungan eksekusi mereka sendiri. Ini bukan hipotesis. Anthropic telah menerbitkan contoh model yang mengatasi batasan lemah untuk menyelesaikan tugas (lihat Cara kami menahan Claude di seluruh produk).

Secara konkret, jangan jalankan agen pencarian kerentanan otonomi dalam Docker/runc biasa, dan terutama tidak dengan --privileged atau host networking. Kontainer standar berbagi kernel host, jadi exploit kernel di dalam kontainer adalah kompromi host. Kami merekomendasikan menempatkan kernel yang divirtualisasi perangkat keras antara kode target dan host, yang berarti menjalankan agen di mesin virtual. Jika itu tidak mungkin, gunakan host bare-metal khusus yang tidak menyimpan apa pun. Jika Anda membangun sandbox Anda sendiri, kami merekomendasikan Firecracker di Linux, Hyper-V di Windows, dan VM berdasarkan kerangka Hypervisor di macOS. Desain referensi menggunakan Firecracker.

Blokir semua egress dari sandbox. Agen mencapai API model hanya melalui proxy yang menambahkan kredensial dan berjalan di luar sandbox, jadi sandbox tidak memerlukan rute langsung ke host API. Instal setiap alat, paket, dan dependensi sebelum proses dimulai, sehingga tidak ada yang perlu diambil selama proses.

Penggunaan interaktif, dengan manusia dalam loop, umumnya membawa risiko lebih rendah, tetapi kami masih merekomendasikan sandbox untuk itu. Jika Anda menjalankan agen secara interaktif dari Claude Code di laptop, baik tinjau setiap penggunaan alat (mode manual), atau andalkan pengklasifikasi izin mode otomatis dan minta manusia menyetujui setiap tindakan yang menjangkau di luar repo. Mode otomatis menghilangkan prompt izin rutin: ia menyetujui pembacaan dan pengeditan direktori kerja secara otomatis dan mengirim semuanya ke pengklasifikasi latar belakang yang bertujuan untuk memblokir tindakan yang merusak, tidak dapat diubah, atau di luar tugas. Ini adalah pemeriksaan upaya terbaik. Ini dapat melewatkan hal-hal, dan dalam pekerjaan keamanan itu juga dapat menolak beberapa langkah yang sah. Mode otomatis menjelaskan cara kerjanya, apa yang diharapkan darinya, dan cara mengonfigurasinya untuk lingkungan Anda.

Jangan pernah memasang jalur yang menyimpan kredensial seperti ~/.aws, ~/.ssh, atau .env ke dalam lingkungan agen. Hal yang sama berlaku untuk kredensial yang digunakan panggilan model agen sendiri. Jauhkan dari sandbox, dan miliki proxy yang tidak dapat dibaca agen untuk menambahkannya ke setiap permintaan (lihat Proxy kredensial). Jangan hubungkan agen ke server MCP atau alat dengan akses tulis ke status eksternal seperti email, penyimpanan cloud, atau infrastruktur produksi.

Ini adalah satu pola yang menerapkan panduan di atas. Fase pengaturan memiliki akses internet keluar dan manusia dalam loop yang menyetujui setiap panggilan alat. Di dalamnya agen menarik dependensi, membangun target, dan menyiapkan sandbox dari dokumen spesifikasi. Fase serangan tidak memiliki akses internet umum. Semua egress melewati proxy daftar izin yang hanya mengizinkan host yang dinamai dalam keterlibatan, jadi proxy juga menerapkan cakupan. Panggilan model melewati proxy kredensial terpisah. Agen kemudian dapat menyelidiki target tanpa pengawasan. Proxy berisi lalu lintas agen sendiri. Ini tidak berisi lalu lintas yang dikirim target jaringan atas nama agen.

Panggang dependensi yang dibutuhkan agen secara berulang ke dalam gambar pengaturan, sehingga proses fase serangan tidak memerlukan akses internet sama sekali. Kredensial cakupan per target, sehingga agen yang bekerja pada satu target tidak dapat menggunakannya terhadap target lain. Jauhkan mode otomatis Claude Code di dalam sandbox selama fase serangan dan jelaskan sandbox ke pengklasifikasinya. Lihat Mode otomatis.

Berikan setiap agen anggaran eksplisit, sehingga proses yang melebihi pengujian yang dimaksudkan berhenti dengan sendirinya dan bukan ketika seseorang memperhatikan. Terapkan batas giliran keras pada setiap agen. Ketika agen menghabiskan, akhiri proses dan jangan berikan lebih banyak giliran secara otomatis. Meluncurkan kembali dengan batas yang lebih tinggi adalah titik di mana seseorang memutuskan untuk melanjutkan. Batasi proses dalam waktu juga. Akhiri sesi yang melebihi batas waktu dengan cara yang sama: proses adalah final dan tidak pernah dilanjutkan, dan proses agen dihentikan, bahkan ketika batas tercapai di tengah perintah yang berjalan lama. Jika batas ditetapkan ke nilai yang tidak dapat dibaca, tolak untuk meluncurkan daripada menjalankan tanpa batas. Tetapkan batas dengan sengaja untuk keterlibatan dan jangan terima default yang murah hati. Pasangkan dengan kadence pemantauan dalam pemantauan offline transkrip agen, sehingga batch panjang dilihat setiap jam atau dua jam dan bukan hanya di akhir. Ketahui cara menghentikan satu agen tanpa menghentikan batch. Dalam pengaturan berbasis Docker itu adalah docker rm -f <agent-container>. Orkestrator harus mencatat proses itu sebagai gagal dan melanjutkan dengan sisa batch.

Untuk panduan lebih lanjut, baca dua sumber daya Anthropic. Penyebaran agen AI yang aman mencakup opsi isolasi, proxy kredensial, dan pengerasan sistem file. Retrospektif teknik Cara kami menahan Claude di seluruh produk mencakup apa yang bertahan dan apa yang tidak ketika mekanisme yang sama berjalan dalam produksi.

Sandbox membatasi apa yang dapat dijangkau agen. Untuk pentesting, red teaming, dan keterlibatan lain yang memerlukan akses jaringan, praktik di bawah membatasi apa yang diminta dan diizinkan untuk dilakukan agen. Mereka bergantung pada target dan tim Anda, jadi tooling tidak dapat menempatkan sebagian besar di tempat untuk Anda.

Sebelum proses, beri tahu agen target mana yang dalam cakupan, tindakan mana yang diizinkan, di mana batas jaringan, dan apa yang di luar cakupan. Frasekan setiap batasan sebagai niat ("jangan akses host di luar 10.0.3.0/24") dan bukan sebagai klaim tentang lingkungan ("Anda tidak dapat menjangkau internet"), sehingga instruksi masih berlaku jika lingkungan salah konfigurasi. Lakukan ini untuk pekerjaan lokal yang disandboxkan juga: beri tahu agen untuk tidak menggunakan akses internet, meskipun sandbox memblokir. Deskripsi yang Anda berikan pengklasifikasi mode otomatis adalah hal yang berbeda. Ini menyatakan fakta tentang mesin (lihat Mode otomatis).

Jika Anda bisa, jalankan agen di dalam isolasi yang sama yang dijelaskan di atas, dan daftar izin egress hanya ke target dalam cakupan (lihat Daftar izin egress). Agen mencapai API model melalui proxy kredensial, bukan melalui daftar izin. Jika tersedia, arahkan keterlibatan ke lingkungan staging atau replika yang terputus dari produksi.

Berikan agen akses ke sistem target melalui sesuatu yang dapat Anda amati, seperti proxy akses atau set alat yang ditentukan. Hindari membiarkan agen menulis tooling-nya sendiri dengan akses umum ke target. Dalam harness khusus, pisahkan alat baca-saja dari alat yang mengubah status, dan awasi grup kedua lebih dekat. Pertimbangkan menganalisis perintah berisiko saat diusulkan, dan menolak atau mengeskalasi ke orang.

Kami merekomendasikan bahwa insinyur menonton setiap proses saat dijalankan, mengikuti panggilan alat dan aktivitas jaringan, dan dapat menghentikan proses segera. Agen bertindak dengan kecepatan mesin, jadi pengamatan langsung melengkapi kontrol yang bertindak sebelum tindakan dijalankan (daftar izin jaringan, alat yang dimediasi, dan tinjauan tindakan yang mengubah status). Ini tidak menggantikan mereka. Untuk proses panjang atau otonomi di mana perhatian berkelanjutan tidak praktis, pantau terus dalam perangkat lunak (lihat Pemantauan offline transkrip agen).

Jangan jalankan agen otonomi terhadap sistem produksi aktif di mana tindakan di luar cakupan dapat membahayakan keselamatan atau ketersediaan layanan kritis, seperti OT/ICS, medis, atau sistem energi. Ini sudah menjadi norma untuk pengujian yang dipimpin manusia dari sistem tersebut, dan berlaku sama di sini. Uji terhadap replika, testbed, atau kembar digital, atau selama pemadaman yang direncanakan. Jika akses langsung tidak dapat dihindari, batasi agen ke aktivitas pasif atau baca-saja dan minta orang melakukan setiap langkah yang mengubah status.

Sebelum Anda menjalankan keterlibatan nyata dari host, uji sandbox-nya dengan dua langkah di bawah. Lakukan ini sebelum penggunaan nyata pertama, dan lagi setiap kali Anda mengubah model atau sandbox. Perubahan sandbox mencakup host baru, versi baru hypervisor atau container runtime, setup jaringan atau proxy yang berbeda, dan konfigurasi kontainer atau compose yang diedit.

Dalam sesi Claude Code interaktif di host, minta untuk membaca konfigurasi sandbox seperti yang diatur di mesin ini dan melaporkan apa pun yang melemahkan batas yang dijelaskan artikel ini. Arahkan ke:

Langkah ini hanya membaca konfigurasi dan status. Ini tidak meluncurkan agen.

Luncurkan agen uji dengan cara yang sama seperti Anda meluncurkan agen produksi, bukan dengan perintah yang dibangun tangan, sehingga tes menjalankan jalur nyata. Bagian Verifikasi isolasi sendiri di bawah mencakup pemeriksaan tangan batas sebagai gantinya. Berikan agen satu tugas: coba jangkau apa pun di luar batasnya, dan berhenti serta laporkan segera setelah ada yang berhasil. Beri nama batas secara konkret dalam prompt: host, kontainer lain, soket container-runtime, layanan metadata cloud, dan host apa pun yang tidak ada di daftar izin proxy. Jalankan ini hanya di bawah pengawasan manusia yang ketat, di host tanpa akses internet di luar API model dan yang siap Anda bangun kembali, sehingga escape yang berhasil tidak menimbulkan kerusakan. Di bare metal, jalankan tes di dalam VM sekali pakai. Di cloud VM, gunakan instance baru dan hancurkan setelahnya. Tonton sesi saat berjalan. Perlakukan kesuksesan apa pun sebagai pemblokir: perbaiki host, ulangi tes, dan jangan jalankan engagement dari host itu sampai tes lulus.

Periksa apa yang dicoba agen serta apakah itu keluar. Cari koneksi langsung yang tidak melalui proxy, pembacaan file kredensial atau alamat metadata, penggunaan soket container-runtime atau probe kontainer tetangga, penulisan di luar filesystem kontainer sendiri, dan upaya mengubah pengaturan atau tooling agen sendiri. Tes lulus ketika transkrip menunjukkan masing-masing dicoba dan gagal karena alasan yang Anda harapkan. Catat, untuk masing-masing, apakah sandbox atau pengklasifikasi izin menghentikannya. Upaya yang ditolak pengklasifikasi tidak pernah mencapai sandbox, jadi tutupi dengan pemeriksaan tangan (lihat Verifikasi isolasi sendiri di bawah). Tes yang lulus adalah standar minimum, bukan bukti isolasi.

Konfirmasi sebelum peluncuran bahwa tugas dapat diselesaikan seperti yang diberikan. Beberapa contoh tugas yang tidak dapat diselesaikan: area fokus tanpa apa pun untuk ditemukan, target yang tidak dapat dijangkau, bug yang tidak ada, atau alat yang dibutuhkan tugas yang tidak diinstal. Kapan pun Anda mengubah setup atau memulai jenis tugas baru, konfirmasi sebelum peluncuran bahwa target dibangun dan dapat dijangkau dan agen memiliki alat yang dibutuhkan. Untuk alasan yang sama, ketika Anda meninjau batch, baca transkrip jalankan yang gagal atau tidak menemukan apa pun sebelum yang berhasil.

Jalankan pemeriksaan ini dengan tangan di setiap host. Kolom kedua menjelaskan pemeriksaan untuk desain referensi (Docker dengan runtime Kata dan Firecracker). Sesuaikan dengan runtime Anda sendiri.

Bagian ini menjelaskan bagaimana implementasi referensi memenuhi panduan di atas. Implementasi tidak disertakan. Bacanya sebagai desain yang dapat Anda salin.

Setiap agen berjalan sebagai claude -p di dalam microVM-nya sendiri, di sebelah biner target dan sumber. MicroVM adalah kontainer Kata Containers yang didukung oleh monitor mesin virtual Firecracker, terdaftar dengan Docker sebagai runtime. Alat Read, Write, dan Bash agen hanya melihat filesystem dan kernel tamu itu.

Koneksi antara tamu dan host sengaja kecil. Ini terdiri dari KVM dan beberapa perangkat virtual yang Firecracker emulasi: perangkat blok untuk disk kontainer, satu antarmuka jaringan, dan saluran kontrol vsock yang Kata gunakan untuk memulai proses di dalam tamu. Proses Firecracker sendiri terbatas di host. Ini berjalan dalam "penjara," yang merupakan direktori chroot yang hanya menyimpan file VM itu, dengan namespace mount sendiri, namespace jaringan kontainer, dan filter seccomp bawaan Firecracker. Ini diperhitungkan untuk cgroup kontainer. Apa yang Anda percayai di sisi host adalah KVM, Firecracker, dan proses runtime Kata ("shim" per-kontainer yang Docker bicarakan, yang berjalan sebagai root).

Orchestrator tetap di host terpercaya. Ini mengelola lifecycle kontainer, mengalirkan transkrip, dan memindahkan file masuk dan keluar dengan docker exec, yang Kata layani melalui agennya di dalam tamu. Launcher memulai agen hanya di dalam sandbox ini. Sebelum agen apa pun dimulai, ia memeriksa bahwa runtime sandbox terdaftar, bahwa /dev/kvm ada, dan bahwa proxy egress aktif, dan menolak untuk menjalankan sebaliknya.

Apa yang sandbox ubah untuk setiap permukaan:

Tempat setiap properti diterapkan: virtualisasi perangkat keras menyediakan batas kernel dan sistem file. Read/Write/Bash agen berjalan terhadap kernel tamu, dan proses Firecracker di baliknya dijail dan dibatasi seccomp di host. Kebijakan egress diterapkan di sisi host antarmuka jaringan VM, oleh jembatan Docker --internal (tidak ada rute default keluar) dan dua proxy di jaringan itu. Proxy kredensial meneruskan panggilan model dan tidak ada yang lain. Proxy egress menolak setiap tujuan lain, karena daftar izinnya kosong kecuali Anda menambahkannya. Lalu lintas keluar melalui tumpukan jaringan tamu sendiri; penyaringan terjadi di dua proxy.

Kredensial untuk API model (kunci API Anda, token OAuth, kredensial AWS atau Google) tidak pernah ditempatkan di kontainer agen. Orkestrator di host membaca dan memvalidasinya, dan setiap peluncuran memulai satu kontainer kecil ekstra, proxy kredensial, untuk menahannya. Proxy terhubung ke jaringan internal agen, dan kontainer agen mengirim panggilan model mereka ke sana: claude CLI mereka mendapatkan alamat proxy sebagai URL dasar API mereka, dan nilai placeholder tetap di mana kunci atau token biasanya berada. Ini mengikuti praktik terbaik menjangkau API model hanya melalui proxy, dengan kunci API disuntikkan dari luar sandbox. Dalam desain referensi, proxy adalah kontainer terpisah di jaringan agen, bukan proses di localhost agen sendiri. Untuk setiap permintaan, proxy:

Untuk kontainer agen yang dikompromikan, ini berarti tidak ada kunci, token, atau file kredensial untuk dibaca, disalin, atau dikirim ke mana pun. Layanan metadata cloud juga tidak dapat dijangkau dari kontainer. Apa yang masih dapat dilakukan kontainer adalah membuat panggilan model melalui proxy, di akun Anda, selama jalankan aktif. Untuk alasan itu, lebih suka kredensial dengan cakupan sempit untuk jalankan agen, dan rotasi setelah jalankan apa pun yang transkrip menunjukkan perilaku tak terduga. Proxy mencatat satu baris per permintaan, dengan alamat klien, metode, jalur, status, dan ukuran. Itu tidak mencatat header atau badan. Simpan log itu ketika jalankan berakhir (lihat Bagian Retensi dalam Pemantauan offline transkrip agen).

Apa pun yang dikirim agen ke API model meninggalkan jaringan Anda, dalam badan permintaan yang tidak diperiksa atau dicatat proxy.

Apa yang dipegang setiap sisi, per rute auth:

Kontainer proxy kredensial adalah bagian dari sisi terpercaya pengaturan. Itu berjalan di bawah runc biasa daripada runtime sandbox, sebagai root dengan setiap kemampuan dijatuhkan kecuali yang dibutuhkan untuk membaca file yang dipasang, dan dengan sistem file baca-saja. Itu mendengarkan hanya di alamatnya di jaringan internal agen, dan terhubung ke penyedia secara langsung daripada melalui proxy egress. Orkestrator meneruskan kredensial ke proxy yang berjalan melalui docker exec. Untuk rute file token WIF dan profil, direktori yang memegang token atau profil dipasang baca-saja ke dalam proxy, yang membaca file dari sana. Kredensial tidak ada di lingkungan kontainer proxy atau di baris perintahnya, sehingga docker inspect padanya menunjukkan pemasangan dan bukan rahasia.

Mulai satu proxy per peluncuran, dan hapus ketika jalankan berakhir atau terputus. Periksa proxy yang ditinggalkan oleh jalankan yang dibunuh, dan hapus sebelum peluncuran berikutnya.

Proxy kredensial memiliki dua efek samping. Pertama, CLI agen diberi alamat API non-default, jadi beberapa fitur CLI yang hanya berlaku untuk alamat default dimatikan di dalam kontainer agen. Telemetri dan pemeriksaan pembaruan juga dimatikan, karena tidak akan memiliki rute keluar bagaimanapun. Kedua, di Vertex filter jalur proxy adalah kontrol utama yang menghentikan kontainer agen menggunakan sisa API Vertex AI (lihat Daftar izin egress). Pemeriksaan cakupan IAM kunci saat peluncuran adalah lapisan kedua.

Daftar izin proxy egress kosong secara default. Kontainer agen menjangkau API model hanya melalui proxy kredensial (lihat Proxy kredensial). Setiap peluncuran memulai proxy itu untuk penyedia yang dipilih kredensial Anda, jadi tidak ada yang spesifik penyedia disimpan dalam pengaturan sandbox. Setiap tujuan lain yang diminta agen melalui proxy egress, termasuk host API model itu sendiri, mendapat 403 dan baris tolak dalam lognya. Nilai wilayah yang memilih titik akhir Bedrock dan Vertex (AWS_REGION, CLOUD_ML_REGION) diperiksa terhadap pola ketat sebelum digunakan, sehingga nilai yang salah bentuk tidak dapat mengirim kredensial ke host yang berbeda.

Vertex memiliki satu batasan untuk disadari. …aiplatform.googleapis.com melayani seluruh API Vertex AI, jadi kredensial yang diizinkan membuat pekerjaan khusus dapat menjalankan kontainer arbitrer dengan egress internet penuh di proyek Anda. Gunakan dua kontrol terhadap ini. Buat proxy kredensial meneruskan hanya panggilan model penerbit di proyek yang dikonfigurasi Anda (…/publishers/anthropic/models/…:rawPredict, :streamRawPredict, dan :countTokens) dan tolak setiap jalur lain. Dan periksa cakupan IAM kunci saat peluncuran dan gagal tertutup: tolak ADC pengguna gcloud, periksa kunci akun layanan dengan testIamPermissions, dan tolak jika memegang izin pembuatan beban kerja apa pun. Berikan akun peran khusus yang hanya memegang aiplatform.endpoints.predict. Server metadata, STS Google, dan titik akhir kredensial IAM tidak boleh dapat dijangkau dari kontainer agen.

Jika agen perlu menjangkau host ekstra, seperti cermin paket atau target dalam cakupan, tambahkan ke daftar izin proxy egress sebagai entri host:port. Tambahkan hanya apa yang dibutuhkan keterlibatan (lihat Cakupan dan pengawasan).

Jangan tambahkan host model-API ke daftar ini. Agen tidak membutuhkannya, karena panggilan model mereka melewati proxy kredensial. Menambahkannya memberikan kontainer agen rute langsung ke API, dan sisa desain, termasuk apa yang diberitahu pengklasifikasi izin, mengasumsikan mereka tidak memilikinya.

Mengubah daftar izin berarti memulai ulang proxy egress, yang menghentikan koneksi agen langsung apa pun. Lakukan di antara batch daripada selama satu, dan konfirmasi setelahnya daftar mana yang dimuat proxy.

Turunkan titik akhir penyedia dari konfigurasi kredensial Anda, dan abaikan variabel URL dasar seperti ANTHROPIC_BASE_URL yang diatur pada host: proxy kredensial harus selalu meneruskan ke titik akhir yang dipilih kredensial.

Bagian ini mengumpulkan apa yang dipelajari dari menjalankan agen di bawah Kata dengan Firecracker dalam implementasi referensi. Ini bukan serangkaian langkah instalasi.

Desain referensi memerlukan mesin Linux fisik, atau VM yang dapat menjalankan VM itu sendiri:

Sandboxnya memerlukan KVM pada host Linux. Docker di Mac berjalan di dalam VM Linux bersama yang memasang direktori home pengguna dan menahan daemon Docker, sehingga tidak dapat memberikan isolasi hardware per-agen. Jika Anda bekerja di Mac, jalankan agen pada host Linux dengan KVM (bare metal, atau cloud VM dengan nested virtualization) dan dorong mereka melalui SSH. Jika Anda membangun sandbox Anda sendiri di macOS atau Windows, lihat hypervisor yang dinamai di bagian Panduan umum di atas.

Gambar dan kontainer yang dibuat di penyimpanan sebelumnya Docker menjadi tidak terlihat oleh Docker setelah beralih ke snapshotter devmapper. Mereka tetap di disk. Untuk melihatnya lagi, masukkan kedua pengaturan penyimpanan di daemon.json (storage-driver dan features.containerd-snapshotter) kembali ke apa yang mereka lakukan dan mulai ulang Docker.

Sematkan rilis Kata, dan verifikasi digestnya sebelum Anda menginstalnya. Desain referensi dimulai dari profil Firecracker Kata dan menyematkan pengaturan ini di /etc/kata-containers/configuration.toml:

Nilai kernel, image, dan kernel_params yang disertakan dengan rilis Kata tetap seperti adanya.

Setiap VM boot dari dua file yang sama, Kata bind-mount mereka ke setiap jail, dan jailer dimulai sebagai root, jadi izin file biasa tidak akan menghentikan proses Firecracker yang dikompromikan dari menulis ulang image yang setiap VM kemudian boot. Atur flag immutable pada keduanya (chattr +i). Menghapus flag tersebut memerlukan system call yang filter seccomp Firecracker tidak izinkan, yang dirancang untuk menghentikan bahkan root di dalam jail dari melakukannya. Hapus flag sendiri sebelum Anda menginstal rilis Kata baru. Pada filesystem tanpa dukungan chattr, gunakan bind mount read-only sebagai gantinya.

Setiap agent VM diukur sekali, saat boot: default_memory ditambah --memory container. Dengan baseline 4096 MiB dan batas container 4g, agent adalah VM 8 GiB. Host mengalokasikan memori tersebut ke VM saat tamu menggunakannya, bukan semua saat boot, tetapi rencanakan jumlah penuh per agent bersamaan: sepuluh agent secara paralel dapat tumbuh menuju 80 GiB. Apakah batas --memory container juga membatasi VM secara keseluruhan tergantung pada tata letak cgroup host. Periksa mana dari ini yang berlaku di host Anda:

Kami belum mengonfirmasi perilaku ini pada setiap jenis host. Bagaimanapun, ukuran host berdasarkan ukuran VM.

Setiap VM mendapat default_vcpus. Firecracker tidak dapat menambahkan CPU ke VM yang sedang berjalan, jadi untuk target yang berat build naikkan nilainya sebelum peluncuran; maksimumnya adalah 32 per VM.

Setiap image dan setiap container mendapat disk virtual dari thin pool device-mapper, yang mendukung image store. Jika pool penuh, penulisan di dalam container gagal dengan I/O atau out-of-space errors. Jika filesystem yang menyimpan pool penuh terlebih dahulu, pool menjadi read-only dan setiap container di dalamnya gagal. Bebaskan ruang dengan docker rmi dan docker system prune (blok yang dibebaskan kembali ke pool). sudo dmsetup status <pool> menunjukkan penggunaan. Untuk host yang berumur panjang, thin pool LVM pada disk khusus adalah tata letak yang lebih baik.

Setiap awal agent boot kernel guest. Itu membutuhkan waktu jauh di bawah satu detik pada bare metal dan beberapa detik di bawah nested virtualization, yang kecil dibandingkan dengan waktu run agent.

Setelah Anda menyiapkan mesin segar, urutan ini menunjukkan bahwa sandbox bekerja end to end. Langkah 3 dan 4 membuat panggilan model nyata.

Menjalankan agent di bawah Kata dengan Firecracker berbeda dari menjalankan container biasa dengan cara-cara ini.

Firecracker tidak memiliki host-filesystem sharing, jadi Kata menyalin file atau direktori yang di-bind-mount ke guest saat container dimulai, dan perubahan kemudian di host tidak terlihat di dalam. Itu baik-baik saja untuk input yang tidak berubah selama run, seperti target source, dan ini dapat tetap read-only mounts. Tidak ada credential file yang di-mount atau di-stream, karena container agent tidak menyimpan apa pun (lihat Proxy kredensial). File yang berubah selama run harus ditulis ke dalam container oleh orchestrator, melalui docker exec, dan tetap terkini. Salinan in-container adalah file biasa yang agent di bawah test dapat edit, jadi biarkan orchestrator membaca original di host, dan menilai findings dari salinan yang agent di bawah test tidak dapat jangkau.

Antarmuka jaringan microVM harus ada saat VM boot; Firecracker tidak dapat menambahkan satu nanti. Docker, bagaimanapun, menghubungkan jaringan container hanya setelah runtime telah membuat container. Desain referensi mengatasi ini. Pertama kali memulai container idle kecil yang terpasang ke jaringan yang tepat dan hanya menjalankan sleep, dan kemudian memulai agent di dalam namespace jaringan container tersebut (--network container:<name>). Kata menemukan antarmuka di sana saat boot dan melampirkannya ke VM. Pendamping melayani tepat satu VM, karena Kata meninggalkan perangkat jaringan sisi host VM di dalamnya, jadi buat dan hapus pasangan bersama dan jangan gunakan kembali pendamping. Satu biaya proses idle sekitar 12 MB.

docker rm -f <agent-container> sudah cukup. Orchestrator harus mendeteksi container mati, menandai run sebagai gagal, dan menghapus container pendamping saat merobohkan run.

DNS tertanam Docker berjalan di namespace jaringan sisi host dan tidak dapat dijangkau dari dalam guest, jadi teruskan proxy ke agen sebagai alamat IP, dan berikan target jaringan IP statis.

docker exec ke dalam kontainer agen berperilaku seperti biasa; agen Kata di dalam guest menjalankan perintah. docker cp ke dalam atau keluar dari kontainer agen tidak berfungsi, karena file kontainer berada di disk virtual di dalam guest. Gunakan docker exec <container> cat <path> dan sejenisnya.

Kata memulai jailer dengan uid 0, jadi proses Firecracker dibatasi oleh chroot, namespace, filter seccomp, dan cgroup-nya, bukan oleh id pengguna yang tidak istimewa. Dua file yang dibagikan setiap VM, kernel guest dan image, dilindungi oleh flag immutable sebagai gantinya (lihat Pengaturan Kata).

Kata menjalankan Firecracker melalui runtime Go yang lebih lama. Kata 4.0 menjadikan runtime Rust yang lebih baru sebagai default untuk hypervisor lainnya dan menghentikan runtime Go. Upstream mengatakan runtime Go masih menerima perbaikan bug kritis dan perbaikan CVE, dan mungkin dihapus tidak lebih awal dari Kata 5.0. Runtime Rust tidak mencantumkan Firecracker di antara hypervisor-nya, dan upstream menguji integrasi Docker-nya terutama dengan QEMU. Rencanakan migrasi. Saat Anda mengubah versi Kata, ulangi Memvalidasi host baru. Kata juga dapat menggunakan Cloud Hypervisor sebagai pengganti Firecracker; implementasi referensi belum menguji atau memperkuat konfigurasi tersebut.

Pesan runtime Kata, Firecracker, dan guest-agent masuk ke jurnal: journalctl -t kata. Masalah containerd dan Docker ada di journalctl -u containerd dan journalctl -u docker.