Tetragon на нодах Kubernetes: тестируем eBPF-детекцию для КИИ-периметра

Два года назад разговор об eBPF в контексте безопасности выглядел примерно как разговор о Rust на совещании с финансовым директором - технически интересно, но как это вообще связано с нашими задачами. В 2025-м Falco и Tetragon добрались до того уровня зрелости, когда их уже нельзя игнорировать при проектировании мониторинга безопасности Kubernetes-нод. Мы взяли Tetragon на тест в рамках аудита защищённости инфраструктуры - один из клиентов с КИИ-объектами дал добро на лабораторный стенд с последующим пилотом на не самых критичных продакшн-нодах.

Почему Tetragon, а не Falco

Falco - старше, стабильнее, у него больше готовых rule-сетов. Но Tetragon интересен другим: он работает не на уровне перехвата событий через audit-подсистему ядра, а прямо в ядре через eBPF-программы. Это значит, что атакующий, который уже получил привилегии на ноде, не может просто отключить агент в userspace и продолжить работу незамеченным - eBPF-программа продолжает работать независимо от состояния агента в пространстве пользователя.

Кроме того, Tetragon позволяет не просто детектировать события, но и блокировать их прямо в ядре через TracingPolicy с действием SIGKILL. Это двусторонний инструмент: наблюдение и реакция в одном. Для КИИ-периметра, где время реакции на инцидент нормировано, это потенциально важно.

Falco тоже умеет в eBPF-драйвер, но политики реакции у него слабее. Выбор был прагматичным: тестируем то, что сейчас активнее развивается по части enforcement.

Стенд и методология

Кластер на Deckhouse - три мастера, шесть воркер-нод, всё на Astra Linux SE 1.8. Tetragon установили через Helm-чарт, TracingPolicy написали сами под наш threat model: нас интересовали подозрительные execve (неожиданные бинари в контейнерах), попытки ptrace, открытие /proc/*/mem, network syscall за пределами разрешённых портов из конкретных неймспейсов.

Нагрузочный тест запускали параллельно с security-тестами: синтетические запросы через k6, плюс реальный фоновый трафик от staging-приложений. Смотрели на CPU overhead на воркер-ноде и задержку добавляемую на системные вызовы.

Что с overhead

Честно: меньше, чем ожидали, но не ноль.

На idle-нодах overhead практически не заметен. eBPF-программы спят, пока нет интересных syscall.

Под нагрузкой с активными TracingPolicy - плюс 2-4% CPU на воркер-ноде. Это при политике, которая смотрит на execve, open, connect и несколько proc-операций. Если добавить tracing на read/write по конкретным файловым путям - overhead растёт заметно, особенно на I/O-интенсивных рабочих нагрузках. Там мы видели плюс 8-12% - уже ощутимо.

Вывод: политики надо писать точечно. Широкий tracing всего подряд - это путь к деградации производительности. TracingPolicy должна покрывать именно то, что в threat model, а не «давайте залогируем всё на всякий случай».

Для КИИ-периметра, где часть нод работает на железе не первой свежести, 2-4% - это приемлемо. 8-12% - уже разговор с заказчиком и оптимизация политик.

Качество сигнала

Здесь приятный сюрприз. Tetragon даёт богатый контекст в каждом событии: PID, namespace, pod name, image, пользователь внутри контейнера, полный путь к бинарю, аргументы. Когда в логах появляется событие «внутри пода с image=nginx неожиданно запустился /usr/bin/python3 с аргументами, похожими на reverse shell» - это уже не просто строка в audit.log, а контекстуализированный сигнал, который можно сразу направить аналитику.

Ложных срабатываний на старте было много - в основном из-за того, что initContainer-ы и sidecar-ы делают вещи, которые выглядят подозрительно, если не знать контекст. Потребовалась неделя настройки: allowlist для конкретных образов, исключения для known-good паттернов. После этого S/N-отношение стало рабочим.

Интеграция с MaxPatrol SIEM

Tetragon экспортирует события в JSON через gRPC или в файл. Для MaxPatrol SIEM мы выбрали подачу через syslog-форвардер: Tetragon -> Vector -> syslog -> MaxPatrol collector. Vector здесь выступает буфером и позволяет обогатить события метаданными кластера до отправки.

Основная работа - написать нормализатор событий Tetragon для MaxPatrol. Формат JSON от Tetragon достаточно структурирован, нормализатор получился компактным. Важный момент: MaxPatrol корреляционные правила нужно написать самостоятельно - готовых правил под Tetragon в базе нет. Мы написали базовый набор под наши TracingPolicy: execve в prod-неймспейсах из неожиданных бинарей, ptrace между контейнерами, исходящие соединения из неймспейсов без egress-политик.

Алерты в MaxPatrol появляются с задержкой 10-15 секунд от события - для большинства инцидентов приемлемо, для реактивного блокирования (если нужно остановить атаку за секунды) лучше использовать встроенный enforcement Tetragon, не ждать SIEM.

Где стоим сейчас

Пилот на продакшн-нодах идёт третью неделю. Принципиальных проблем нет, но несколько наблюдений:

• Версионирование TracingPolicy нужно с самого начала. Политики меняются по мере настройки, без git-истории через неделю не помнишь, что и зачем менял.
• Tetragon не заменяет network policy - он детектирует попытки, но если в кластере нет NetworkPolicy, lateral movement всё равно возможен до момента срабатывания алерта.
• Документация у Tetragon растёт быстро, но примеры для prod-сценариев надо искать в issues и slack - официальные примеры пока покрывают базовые сценарии.

Инструмент рабочий. Для КИИ-периметра overhead приемлем при аккуратно написанных политиках, интеграция с MaxPatrol SIEM реализуема без экзотики. Главная инвестиция - время на настройку и написание корреляционных правил: это не «поставил и работает», но и ожидать другого от eBPF-based runtime security в 2025-м было бы наивно.