Aislamiento mediante máquinas virtuales para agentes de código de alta seguridad
gVisor, microVM de Firecracker y aislamiento a nivel de hardware para agentes.
Aislamiento mediante máquinas virtuales para agentes de código de alta seguridad es una lección gratuita de AI Agents en CoddyKit. Esta es la lección 2 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de AI Agents, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de AI Agents incluye 4 lecciones en total.
Más allá de Docker: un aislamiento más sólido
Los contenedores estándar de Docker comparten el kernel del host. Un exploit del kernel dentro del contenedor puede escapar al host. Para ejecutar código con un alto nivel de seguridad, se requieren capas de aislamiento más sólidas.
Hay dos enfoques principales: gVisor (proxy de kernel en el espacio de usuario) y Firecracker (microVM ligeras).
Cómo funciona gVisor
gVisor inserta un componente en el espacio de usuario llamado Sentry entre el contenedor y el kernel del host. Las llamadas al sistema del contenedor llegan a Sentry, que vuelve a implementar un subconjunto seguro en Go, en lugar de utilizar el kernel real.
El runtime se llama 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())Interceptación de llamadas al sistema de gVisor
Cuando el código dentro del contenedor llama a open(), read() o socket(), gVisor intercepta la llamada al sistema y decide si debe permitirla, emularla o denegarla.
Las llamadas al sistema sensibles, como ptrace o la creación de sockets sin formato, están bloqueadas de forma predeterminada, lo que cierra vectores de ataque habituales.
# 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')Compromiso de rendimiento de gVisor
Cada llamada al sistema pasa por Sentry en lugar de dirigirse directamente al kernel. Esto añade una sobrecarga aproximada del 10-30 % en cargas de trabajo con un uso intensivo de E/S. En los cálculos limitados por CPU, la sobrecarga es mucho menor.
El tiempo de inicio es similar al de Docker normal: unos milisegundos.
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.3sMicroVM de Firecracker
Firecracker adopta un enfoque completamente diferente: ejecuta cada carga de trabajo en una máquina virtual completa con su propio kernel. La máquina virtual se inicia en unos 50 ms y utiliza solo unos 5 MB de memoria adicional.
Como las máquinas virtuales tienen un kernel completamente separado, no existe una superficie de ataque de kernel compartido.
# 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')Modelo de seguridad de Firecracker
Las máquinas virtuales de Firecracker tienen una superficie de ataque mínima por diseño. El VMM expone solo 5 tipos de dispositivos (virtio-net, virtio-block, serial, RTC, keyboard). No hay USB, bus PCI ni BIOS.
Cada máquina virtual está aislada a nivel del hipervisor; un exploit del kernel dentro de la máquina virtual no puede alcanzar el host.
# 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: combinación de ambos
Kata Containers utiliza una máquina virtual ligera (puede usar Firecracker o QEMU), pero expone la interfaz de contenedor OCI estándar. Puede ejecutar comandos normales de Docker; Kata gestiona la capa de la máquina virtual de forma transparente.
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 hostnameElección del nivel de aislamiento adecuado
El sandbox adecuado depende de su modelo de amenazas y de su presupuesto de latencia:
- Docker (runc): rápido, con poca sobrecarga y kernel compartido; adecuado para código de confianza o con un filtrado ligero
- gVisor (runsc): filtrado de llamadas al sistema, el mismo formato de imagen y una sobrecarga moderada; ofrece un buen equilibrio
- Firecracker/Kata: aislamiento completo mediante máquina virtual e inicio en 50 ms; para código de usuario no confiable a escala
Tabla de seguridad frente a latencia de inicio
La profundidad del aislamiento y la velocidad de inicio son inversamente proporcionales. Elija en función de la latencia aceptable para el caso de uso de su agente.
# 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 precalentados
Iniciar una máquina virtual en frío para cada solicitud del agente añade latencia. Los sistemas de producción precalientan un conjunto de sandboxes inactivos. Cuando llega una solicitud, se asigna un sandbox precalentado, se utiliza y después se destruye (nunca se reutiliza).
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 readyInstantáneas y restauración para escalar
Firecracker permite guardar en disco una instantánea de una máquina virtual en ejecución. La instantánea captura el estado de la memoria, el estado de los dispositivos y los registros de la CPU. Restaurarla desde la instantánea tarda unos 10 ms, mucho menos que un inicio en frío.
Este patrón permite inicializar un intérprete de Python una sola vez, guardar una instantánea y restaurarlo para cada solicitud.
# 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')¿Qué componente inserta gVisor entre el contenedor y el kernel del host?
El modelo de aislamiento de gVisor depende de un componente específico que intercepta las llamadas al sistema. Comprender esta arquitectura es fundamental para evaluar sus garantías de seguridad.
Resumen del aislamiento mediante VM
Para ejecutar código de agentes con un alto nivel de seguridad, vaya más allá del Docker estándar y utilice gVisor (interceptación de llamadas al sistema y poca sobrecarga) o Firecracker (máquina virtual completa, inicio en 50 ms y unos 5 MB de memoria adicional).
El compromiso siempre se da entre profundidad del aislamiento y latencia de inicio. Los conjuntos precalentados y las instantáneas de máquinas virtuales pueden recuperar gran parte del coste de latencia en producción.
Preguntas frecuentes
¿La lección «Aislamiento mediante máquinas virtuales para agentes de código de alta seguridad» es gratis?
Sí — el texto completo de «Aislamiento mediante máquinas virtuales para agentes de código de alta seguridad» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de AI Agents, actualiza a CoddyKit PRO. El curso de AI Agents incluye 4 lecciones en total.
¿Qué aprenderé en «Aislamiento mediante máquinas virtuales para agentes de código de alta seguridad»?
gVisor, microVM de Firecracker y aislamiento a nivel de hardware para agentes. Practicas AI Agents con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar AI Agents?
No se requiere experiencia previa. AI Agents en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 2 de 4.
¿Cuánto tiempo toma la lección «Aislamiento mediante máquinas virtuales para agentes de código de alta seguridad»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de AI Agents?
Sí. Cada lección de AI Agents incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Sandboxes de agentes basados en Docker
- Aislamiento mediante máquinas virtuales para agentes de código de alta seguridad
- E2B y servicios de sandbox en la nube
- Políticas de seguridad para la ejecución de código