Изоляция в VM для защищённых агентов, работающих с кодом
gVisor, microVMs Firecracker и изоляция на уровне оборудования для агентов.
«Изоляция в VM для защищённых агентов, работающих с кодом» — бесплатный урок AI Agents на CoddyKit. Это урок 2 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения AI Agents, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс AI Agents содержит 4 уроков всего.
Помимо Docker: усиленная изоляция
Стандартные контейнеры Docker используют общее ядро с хостом. Эксплойт ядра внутри контейнера может обеспечить выход на хост. Для выполнения кода с высокими требованиями к безопасности необходимы более надежные уровни изоляции.
Два основных подхода: gVisor (прокси ядра в пользовательском пространстве) и Firecracker (легковесные MicroVMs).
Как работает gVisor
gVisor размещает компонент пользовательского пространства под названием Sentry между контейнером и ядром хоста. Системные вызовы контейнера направляются в Sentry, который реализует безопасное подмножество вызовов на Go, а не обращается к настоящему ядру.
Среда выполнения называется runsc (запуск контейнера в песочнице).
# 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
Когда код внутри контейнера вызывает open(), read() или socket(), gVisor перехватывает системный вызов и решает, разрешить его, эмулировать или заблокировать.
Чувствительные системные вызовы, такие как ptrace, и создание необработанных сокетов по умолчанию блокируются, что закрывает распространенные пути эксплуатации.
# 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')Компромисс между производительностью gVisor
Каждый системный вызов проходит через Sentry, а не напрямую к ядру. Это добавляет около 10–30% накладных расходов при больших нагрузках на ввод-вывод. Для вычислений, ограниченных производительностью CPU, накладные расходы значительно меньше.
Время запуска сопоставимо с обычным Docker — миллисекунды.
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.3sMicroVMs Firecracker
Firecracker использует совершенно другой подход: он запускает каждую рабочую нагрузку в полноценной виртуальной машине с собственным ядром. VM запускается примерно за 50 мс и использует всего около 5 МБ дополнительной памяти.
Поскольку у VM полностью отдельное ядро, общая поверхность атаки ядра отсутствует.
# 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')Модель безопасности Firecracker
VM Firecracker по своей конструкции имеют минимальную поверхность атаки. VMM предоставляет только 5 типов устройств (virtio-net, virtio-block, последовательный порт, RTC, клавиатура). Нет USB, шины PCI и BIOS.
Каждая VM изолирована на уровне гипервизора — эксплойт ядра внутри VM не может получить доступ к хосту.
# 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: объединение обоих подходов
Kata Containers используют легковесную VM (можно использовать Firecracker или QEMU), но предоставляют стандартный интерфейс контейнеров OCI. Вы выполняете обычные команды Docker, а Kata прозрачно обрабатывает уровень VM.
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Выбор подходящего уровня изоляции
Подходящая песочница зависит от Вашей модели угроз и допустимой задержки:
- Docker (runc): быстро, низкие накладные расходы, общее ядро — подходит для доверенного или слегка отфильтрованного кода
- gVisor (runsc): фильтрация системных вызовов, тот же формат образов, умеренные накладные расходы — хороший баланс
- Firecracker/Kata: полная изоляция VM, запуск за 50 мс — для непроверенного пользовательского кода при больших нагрузках
Таблица безопасности и задержки запуска
Глубина изоляции и скорость запуска обратно пропорциональны. Выбирайте решение с учетом допустимой задержки для сценария использования Вашего агента.
# 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']}")
Предварительный прогрев песочниц
Холодный запуск VM для каждого запроса агента увеличивает задержку. В промышленных системах заранее запускают пул простаивающих песочниц. Когда поступает запрос, свободная прогретая песочница получается, используется, а затем уничтожается и никогда не используется повторно.
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Снимки и восстановление для масштабирования
Firecracker поддерживает создание снимка работающей VM на диске. Снимок сохраняет состояние памяти, состояние устройств и регистры CPU. Восстановление из снимка занимает около 10 мс — гораздо быстрее холодного запуска.
Этот подход позволяет один раз заранее инициализировать интерпретатор Python, создать его снимок и восстанавливать его для каждого запроса.
# 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')Какой компонент gVisor размещается между контейнером и ядром хоста?
Модель изоляции gVisor зависит от конкретного компонента, который перехватывает системные вызовы. Понимание этой архитектуры важно для оценки гарантий безопасности.
Итоги по изоляции VM
Для выполнения кода агента с высокими требованиями к безопасности переходите от стандартного Docker к gVisor (перехват системных вызовов, низкие накладные расходы) или Firecracker (полноценная VM, запуск за 50 мс, около 5 МБ дополнительных расходов).
Компромисс всегда заключается между глубиной изоляции и задержкой запуска. Пулы предварительно прогретых песочниц и снимки VM позволяют компенсировать большую часть затрат на задержку в промышленных системах.
Часто задаваемые вопросы
Урок «Изоляция в VM для защищённых агентов, работающих с кодом» бесплатный?
Да — полный текст урока «Изоляция в VM для защищённых агентов, работающих с кодом» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс AI Agents, подпишись на CoddyKit PRO. Курс AI Agents содержит 4 уроков всего.
Чему я научусь в уроке «Изоляция в VM для защищённых агентов, работающих с кодом»?
gVisor, microVMs Firecracker и изоляция на уровне оборудования для агентов. Ты практикуешь AI Agents с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.
Нужен ли мне опыт, чтобы начать AI Agents?
Предыдущий опыт не требуется. AI Agents на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 2 из 4.
Сколько времени занимает урок «Изоляция в VM для защищённых агентов, работающих с кодом»?
Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.
Можно ли писать и запускать код в этом уроке AI Agents?
Да. Каждый урок AI Agents включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.
Все уроки этого курса
- Песочницы агентов на основе Docker
- Изоляция в VM для защищённых агентов, работающих с кодом
- E2B и облачные сервисы песочниц
- Политики безопасности для выполнения кода