AI-agenten · Les

VM-isolatie voor zeer veilige codeagents

gVisor, Firecracker-microVM's en isolatie op hardwareniveau voor agents.

Les 2 van 413 stappen

VM-isolatie voor zeer veilige codeagents is een gratis AI-agenten-les op CoddyKit. Dit is les 2 van 4. Je kunt de volledige les hieronder gratis lezen en daarna in de browser praktisch oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject AI-agenten. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus AI-agenten bevat in totaal 4 lessen.

Verder dan Docker: sterkere isolatie

Standaard Docker-containers delen de kernel van de host. Een kernel-exploit in de container kan ontsnappen naar de host. Voor het uitvoeren van code met hoge beveiliging zijn lagen voor sterkere isolatie vereist.

Er zijn twee belangrijke benaderingen: gVisor (kernelproxy in de gebruikersruimte) en Firecracker (lichte micro-VM's).

Hoe gVisor werkt

gVisor voegt een component in de gebruikersruimte toe, genaamd Sentry, tussen de container en de kernel van de host. De systeemaanroepen van de container gaan naar Sentry, dat een veilige subset daarvan opnieuw implementeert in Go, niet in de echte kernel.

De uitvoeringsomgeving heet runsc (een container in een sandbox uitvoeren).

# Configure Docker to use gVisor runtime (runsc)
# /etc/docker/daemon.json:
# {
#   "runtimes": {
#     "runsc": { "path": "/usr/local/bin/runsc" }
#   }
# }

import docker
client = docker.from_env()

output = client.containers.run(
    'python:3.12-slim',
    'python -c "print(\"hello from gVisor\")"',
    runtime='runsc',          # use gVisor
    network_disabled=True,
    auto_remove=True
)
print(output.decode())

gVisor onderschept systeemaanroepen

Wanneer code in de container open(), read() of socket() aanroept, onderschept gVisor de systeemaanroep en beslist of die wordt toegestaan, geëmuleerd of geweigerd.

Gevoelige systeemaanroepen zoals ptrace of het maken van raw sockets worden standaard geblokkeerd, waardoor veelvoorkomende aanvalsroutes worden afgesloten.

# gVisor blocks dangerous syscalls like ptrace.
# This code would fail inside a gVisor container:
#
# import ctypes
# libc = ctypes.CDLL(None)
# libc.ptrace(...)   # EPERM: Operation not permitted
#
# Normal Python I/O and computation works fine:
# open(), read(), write(), socket() (if network enabled)
# are all emulated safely by Sentry.
print('gVisor intercepts syscalls before they reach the host kernel')

Prestatieafweging van gVisor

Elke systeemaanroep gaat via Sentry in plaats van rechtstreeks naar de kernel. Dit voegt ongeveer 10-30% extra belasting toe aan I/O-intensieve werklasten. Voor CPU-gebonden berekeningen is de extra belasting veel kleiner.

De opstarttijd is vergelijkbaar met die van gewone Docker: milliseconden.

import time
import docker

client = docker.from_env()

start = time.time()
client.containers.run('python:3.12-slim', 'python -c "pass"',
                      runtime='runsc', auto_remove=True)
print(f'gVisor startup: {time.time()-start:.2f}s')   # ~0.3-0.8s

start = time.time()
client.containers.run('python:3.12-slim', 'python -c "pass"',
                      auto_remove=True)
print(f'Docker startup: {time.time()-start:.2f}s')   # ~0.1-0.3s

Firecracker-micro-VM's

Firecracker kiest een volledig andere aanpak: elke werklast wordt uitgevoerd in een volledige virtuele machine met een eigen kernel. De VM start op in ~50 ms en gebruikt slechts ~5 MB extra geheugen.

Omdat VM's een volledig afzonderlijke kernel hebben, is er geen aanvalsoppervlak van een gedeelde kernel.

# Firecracker is controlled via a REST API on a Unix socket.
# Python SDK example (firecracker-python-sdk or direct HTTP):

import requests_unixsocket

session = requests_unixsocket.Session()
base = 'http+unix://%2Ftmp%2Ffirecracker.socket'

# Boot the microVM
session.put(f'{base}/boot-source', json={
    'kernel_image_path': '/opt/kernel/vmlinux',
    'boot_args': 'console=ttyS0 reboot=k panic=1 pci=off'
})
session.put(f'{base}/actions', json={'action_type': 'InstanceStart'})
print('MicroVM booted in ~50ms')

Beveiligingsmodel van Firecracker

Firecracker-VM's hebben standaard een minimaal aanvalsoppervlak. De VMM stelt slechts 5 apparaattypen beschikbaar (virtio-net, virtio-block, serial, RTC, keyboard). Geen USB, geen PCI-bus en geen BIOS.

Elke VM is geïsoleerd op hypervisorniveau — een kernel-exploit in de VM kan de host niet bereiken.

# Firecracker security properties:
# 1. Each microVM has its own Linux kernel instance
# 2. Guest-to-host attack surface is tiny (5 device types)
# 3. The VMM (Virtual Machine Monitor) runs unprivileged
# 4. No shared memory between VMs
# 5. Snapshot/restore: freeze a running VM, clone it for next request

# Used in production by:
# - AWS Lambda (each function invocation = Firecracker microVM)
# - Fly.io (each app container)
# - Replit (code execution)
print('Firecracker: full VM isolation at container startup speed')

Kata Containers: beide combineren

Kata Containers gebruiken een lichte VM (met Firecracker of QEMU), maar bieden de standaard OCI-containerinterface. Je voert normale Docker-opdrachten uit; Kata handelt de VM-laag transparant af.

import docker
client = docker.from_env()

# Kata Containers registered as 'kata-runtime' in daemon.json
output = client.containers.run(
    'python:3.12-slim',
    'python -c "import platform; print(platform.node())"',
    runtime='kata-runtime',   # each container = a VM
    mem_limit='256m',
    network_disabled=True,
    auto_remove=True
)
print(output.decode())  # unique VM hostname

Het juiste isolatieniveau kiezen

De juiste sandbox hangt af van je dreigingsmodel en latentiebudget:

  • Docker (runc): snel, weinig extra belasting, gedeelde kernel — geschikt voor vertrouwde of licht gefilterde code
  • gVisor (runsc): filtering van systeemaanroepen, hetzelfde imageformaat, geringe extra belasting — een goede balans
  • Firecracker/Kata: volledige VM-isolatie, opstarten in 50 ms — voor niet-vertrouwde gebruikerscode op grote schaal

Tabel: beveiliging versus opstartlatentie

De diepte van de isolatie en de opstartsnelheid zijn omgekeerd evenredig. Kies op basis van de aanvaardbare latentie voor de toepassing van je agent.

# Isolation vs Latency summary:
#
# Runtime          | Isolation     | Startup  | Overhead
# -----------------|---------------|----------|----------
# runc (Docker)    | Namespace      | ~100ms   | ~0%
# gVisor (runsc)   | Syscall filter | ~300ms   | ~15-30%
# Kata Containers  | Full VM        | ~500ms   | ~10%
# Firecracker      | Full VM        | ~50ms    | ~5%
# QEMU KVM         | Full VM        | ~1-2s    | ~5%
#
# For interactive agent tools: gVisor is usually the sweet spot.
# For high-throughput batch jobs: Firecracker snapshots.

ISOLATION_OPTIONS = {
    'runc (Docker)':   {'isolation': 'Namespace',      'startup': '~100ms', 'overhead': '~0%'},
    'gVisor (runsc)':  {'isolation': 'Syscall filter',  'startup': '~300ms', 'overhead': '~15-30%'},
    'Kata Containers': {'isolation': 'Full VM',         'startup': '~500ms', 'overhead': '~10%'},
    'Firecracker':     {'isolation': 'Full VM',         'startup': '~50ms',  'overhead': '~5%'},
    'QEMU KVM':         {'isolation': 'Full VM',        'startup': '~1-2s',  'overhead': '~5%'},
}

for runtime, info in ISOLATION_OPTIONS.items():
    print(f"{runtime:<17} | {info['isolation']:<14} | startup {info['startup']:<7} | overhead {info['overhead']}")

Sandboxes vooraf opwarmen

Een VM koud starten voor elke agentaanvraag voegt latentie toe. Productiesystemen warmen vooraf een pool met inactieve sandboxomgevingen op. Wanneer er een aanvraag binnenkomt, wordt een opgewarmde sandbox toegewezen, gebruikt en daarna vernietigd (nooit hergebruikt).

import queue, threading

SANDBOX_POOL_SIZE = 5
pool = queue.Queue()

def pre_warm():
    'Start a sandbox and put it in the pool.'
    container = client.containers.create(
        'python:3.12-slim',
        'tail -f /dev/null',
        runtime='runsc',
        mem_limit='256m',
        network_disabled=True
    )
    container.start()
    pool.put(container)

# Pre-warm the pool at startup
for _ in range(SANDBOX_POOL_SIZE):
    threading.Thread(target=pre_warm, daemon=True).start()

def claim_sandbox():
    return pool.get(timeout=5)  # blocks until one is ready

Snapshots en herstel voor schaalbaarheid

Firecracker ondersteunt het maken van snapshots van een actieve VM op schijf. De snapshot bevat de geheugentoestand, de apparaatstatus en de CPU-registers. Herstellen vanuit een snapshot duurt ongeveer 10 ms — veel sneller dan koud opstarten.

Met dit patroon kun je één keer een Python-interpreter initialiseren, er een snapshot van maken en die voor elke aanvraag herstellen.

# Firecracker snapshot workflow:
# 1. Boot microVM, run Python interpreter, wait for REPL ready
# 2. Pause VM
# 3. Create snapshot
#    PUT /snapshot/create { snapshot_path, mem_file_path }
# 4. For each request:
#    PUT /snapshot/load { snapshot_path, mem_file_path }
#    # VM resumes from paused state with Python already loaded
#    # Send code via stdin/virtio-serial, read output
# 5. Discard VM after request (never reuse)

print('Snapshot restore: ~10ms vs 50ms cold boot for Firecracker')

Welk component voegt gVisor in tussen de container en de hostkernel?

Het isolatiemodel van gVisor is afhankelijk van een specifiek component dat systeemaanroepen onderschept. Inzicht in deze architectuur is essentieel om de beveiligingsgaranties ervan te kunnen beoordelen.

Samenvatting van VM-isolatie

Ga voor het uitvoeren van agentcode met hoge beveiliging verder dan standaard Docker met gVisor (onderschepping van systeemaanroepen, weinig extra belasting) of Firecracker (volledige VM, opstarten in 50 ms, ongeveer 5 MB extra geheugen).

De afweging is altijd isolatiediepte versus opstartlatentie. Vooraf opgewarmde pools en VM-snapshots kunnen in productie het grootste deel van de latentie terugwinnen.

Gratis beginnen

Leer AI-agenten met een AI-tutor — gratis

Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.

Cursussen
60
Lessen
239

Veelgestelde vragen

Is de les “VM-isolatie voor zeer veilige codeagents” gratis?

Ja — de volledige tekst van “VM-isolatie voor zeer veilige codeagents” kun je hier gratis op het web lezen. Als je interactief wilt oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is, en de rest van de cursus AI-agenten wilt ontgrendelen, kun je upgraden naar CoddyKit PRO. De cursus AI-agenten bevat in totaal 4 lessen.

Wat leer ik in “VM-isolatie voor zeer veilige codeagents”?

gVisor, Firecracker-microVM's en isolatie op hardwareniveau voor agents. Je oefent met AI-agenten door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.

Heb ik ervaring nodig om met AI-agenten te beginnen?

Ervaring vooraf is niet nodig. AI-agenten op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 2 van 4.

Hoe lang duurt de les “VM-isolatie voor zeer veilige codeagents”?

De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.

Kan ik code schrijven en uitvoeren in deze les over AI-agenten?

Ja. Elke les over AI-agenten bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.

Alle lessen in deze cursus

  1. Agent-sandboxen op basis van Docker
  2. VM-isolatie voor zeer veilige codeagents
  3. E2B- en cloud-sandboxdiensten
  4. Beveiligingsbeleid voor code-uitvoering
← Terug naar AI-agenten