AI-agenter · leksjon

VM-isolasjon for kodeagenter med høye sikkerhetskrav

gVisor, Firecracker-mikro-VM-er og isolasjon på maskinvarenivå for agenter.

Leksjon 2 av 413 trinn

VM-isolasjon for kodeagenter med høye sikkerhetskrav er en gratis leksjon i AI-agenter på CoddyKit. Dette er leksjon 2 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i AI-agenter, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i AI-agenter inneholder totalt 4 leksjoner.

Utover Docker: sterkere isolasjon

Standard Docker-containere deler vertskjernen. Et utnyttelsesforsøk mot kjernen inne i containeren kan bryte seg ut til vertsmaskinen. For kjøring av kode med høye sikkerhetskrav kreves sterkere isolasjonslag.

To hovedtilnærminger er: gVisor (proxy for kjernen i brukerområdet) og Firecracker (lette mikroVM-er).

Slik fungerer gVisor

gVisor setter inn en komponent i brukerområdet kalt Sentry mellom containeren og vertskjernen. Systemkallene fra containeren går til Sentry, som implementerer et sikkert delsett på nytt i Go, i stedet for å bruke den virkelige kjernen.

Kjøretiden kalles runsc (run sandboxed container).

# 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())

Avskjæring av systemkall i gVisor

Når kode inne i containeren kaller open(), read() eller socket(), fanger gVisor opp systemkallet og avgjør om det skal tillates, emuleres eller avvises.

Sensitive systemkall som ptrace eller oppretting av rå socketer blokkeres som standard, noe som tetter vanlige utnyttelsesveier.

# 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')

Ytelsesavveining i gVisor

Hvert systemkall går gjennom Sentry i stedet for direkte til kjernen. Dette gir ~10–30 % overhead for arbeidsbelastninger med mye I/O. For CPU-bundne beregninger er overheaden mye mindre.

Oppstartstiden ligner på vanlig Docker — millisekunder.

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-mikroVM-er

Firecracker bruker en helt annen tilnærming: Hver arbeidsbelastning kjører i en full virtuell maskin med egen kjerne. VM-en starter på ~50 ms og bruker bare ~5 MB ekstra minne.

Fordi VM-er har en helt separat kjerne, finnes det ingen angrepsflate med delt kjerne.

# 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')

Sikkerhetsmodell for Firecracker

Firecracker-VM-er har en minimal angrepsflate som standard. VMM-en eksponerer bare fem enhetstyper (virtio-net, virtio-block, serial, RTC, keyboard). Ingen USB, ingen PCI-buss, ingen BIOS.

Hver VM er isolert på hypervisornivå — et utnyttelsesforsøk mot kjernen inne i VM-en kan ikke nå verten.

# 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: kombinerer begge

Kata Containers bruker en lett VM (kan bruke Firecracker eller QEMU), men eksponerer standardgrensesnittet for OCI-containere. De kjører vanlige Docker-kommandoer; Kata håndterer VM-laget i bakgrunnen.

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

Velge riktig isolasjonsnivå

Riktig sandkasse avhenger av trusselmodellen og latensbudsjettet:

  • Docker (runc): rask, lite overhead, delt kjerne — egnet for klarert kode eller kode med enkel filtrering
  • gVisor (runsc): filtrering av systemkall, samme imageformat, moderat overhead — en god balanse
  • Firecracker/Kata: full VM-isolasjon, oppstart på 50 ms — for uklarert brukerkode i stor skala

Tabell over sikkerhet kontra oppstartsforsinkelse

Isolasjonsdybde og oppstartshastighet står i omvendt forhold til hverandre. Velg basert på hvilken forsinkelse som er akseptabel for agentens bruksområde.

# 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']}")

Forvarming av sandkasser

Kald oppstart av en VM for hver agentforespørsel gir ekstra forsinkelse. Produksjonssystemer forvarmer et utvalg inaktive sandkasser. Når en forespørsel kommer, tas en oppvarmet sandkasse i bruk, brukes og destrueres deretter (den gjenbrukes aldri).

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

Øyeblikksbilder og gjenoppretting for skalering

Firecracker støtter å lagre et øyeblikksbilde av en kjørende VM på disk. Øyeblikksbildet fanger minnetilstand, enhetstilstand og CPU-registre. Gjenoppretting fra et øyeblikksbilde tar ~10 ms — mye raskere enn en kald oppstart.

Dette mønsteret lar Dem initialisere en Python-tolk én gang, ta et øyeblikksbilde av den og gjenopprette den for hver forespørsel.

# 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')

Hvilken komponent setter gVisor inn mellom containeren og vertskjernen?

Isolasjonsmodellen til gVisor er avhengig av en bestemt komponent som fanger opp systemkall. Det er viktig å forstå denne arkitekturen for å kunne vurdere sikkerhetsgarantiene.

Oppsummering av VM-isolasjon

For kjøring av agentkode med høye sikkerhetskrav bør De gå utover standard Docker og bruke gVisor (avskjæring av systemkall, lite overhead) eller Firecracker (full VM, oppstart på 50 ms, ~5 MB overhead).

Avveiningen er alltid isolasjonsdybde kontra oppstartsforsinkelse. Forvarmede utvalg og VM-øyeblikksbilder kan gjenvinne det meste av forsinkelseskostnaden i produksjon.

Gratis å komme i gang

Lær deg AI-agenter med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs
60
Leksjoner
239

Ofte stilte spørsmål

Er leksjonen «VM-isolasjon for kodeagenter med høye sikkerhetskrav» gratis?

Ja – hele teksten i «VM-isolasjon for kodeagenter med høye sikkerhetskrav» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av AI-agenter-kurset, kan du oppgradere til CoddyKit PRO. Kurset i AI-agenter inneholder totalt 4 leksjoner.

Hva lærer jeg i «VM-isolasjon for kodeagenter med høye sikkerhetskrav»?

gVisor, Firecracker-mikro-VM-er og isolasjon på maskinvarenivå for agenter. Du øver på AI-agenter med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med AI-agenter?

Ingen tidligere erfaring er nødvendig. AI-agenter på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.

Hvor lang tid tar leksjonen «VM-isolasjon for kodeagenter med høye sikkerhetskrav»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne AI-agenter-leksjonen?

Ja. Alle AI-agenter-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

  1. Agent-sandkasser basert på Docker
  2. VM-isolasjon for kodeagenter med høye sikkerhetskrav
  3. E2B og skytjenester for sandkasser
  4. Sikkerhetspolicyer for kodekjøring
← Tilbake til AI-agenter