0Pricing
AI Agents · Урок

Изоляция в 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.3s

MicroVMs 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 — локальная установка не требуется.

Все уроки этого курса

  1. Песочницы агентов на основе Docker
  2. Изоляция в VM для защищённых агентов, работающих с кодом
  3. E2B и облачные сервисы песочниц
  4. Политики безопасности для выполнения кода
← Назад к AI Agents