Part 7 · 1 chapters · ~8 min

Firecracker and gVisor

Why containers are not enough for untrusted multi-tenant code, gVisor's user-space kernel and its platforms, Firecracker microVMs with a minimal device model and jailer, Kata Containers, WebAssembly sandboxes, the performance and compatibility trade-offs, and choosing a boundary for AI agent code execution.

Sandboxes compared

code

# gVisor with Docker: install runsc, then pick it per container
docker run --rm --runtime=runsc alpine dmesg      # prints gVisor's own kernel messages, not the host's

# Kubernetes: choose a sandbox per pod with RuntimeClass
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata: { name: gvisor }
handler: runsc
---
spec: { runtimeClassName: gvisor, containers: [ … ] }

# Firecracker: a microVM configured through a REST API on a Unix socket
curl --unix-socket /tmp/fc.sock -X PUT http://localhost/boot-source -d '{"kernel_image_path":"vmlinux","boot_args":"console=ttyS0 reboot=k panic=1"}'
curl --unix-socket /tmp/fc.sock -X PUT http://localhost/drives/rootfs -d '{"drive_id":"rootfs","path_on_host":"rootfs.ext4","is_root_device":true,"is_read_only":false}'
curl --unix-socket /tmp/fc.sock -X PUT http://localhost/actions -d '{"action_type":"InstanceStart"}'

AI agents running code: code generated by a model and executed on your infrastructure is untrusted code. Run it in a microVM or gVisor sandbox with no network by default, short lifetimes, CPU and memory limits, and no credentials in the environment (AI-native course).

STRONGER BOUNDARIES FOR UNTRUSTED CODE

what each sandbox puts between the code and the host kernel

swipe the figure sideways, or tap expand for full screen

1/4

the problem

Running other people's code (functions as a service, CI jobs, plugins, AI agent code) in ordinary containers trusts the shared kernel completely.

shared kernel, untrusted codeone kernel bug away