Представьте, что вы наконец-то выстроили надежный периметр вокруг своих контейнеров, сканируете образы и настраиваете политики в соответствии с общепринятыми стандартами безопасности. И кажется, все под контролем. Но что, если атака началась в уже запущенном контейнере? Как обнаружить, что прямо сейчас легитимный микросервис крадет ваши данные или майнит криптовалюту?

В данном случае на классические средства защиты рассчитывать не приходится: они охраняют контейнеры снаружи и не видят, что происходит внутри. А большинство инструментов для выявления угроз в среде выполнения — сложные и дорогие. Тем не менее выход есть: недавно специалисты команды PT Container Security из Positive Technologies представили рынку первое в России открытое решение для защиты рантайма контейнерных сред — Runtime Radar. Подробнее о нем в нашей статье рассказывают руководитель разработки Никита Ладошкин и эксперт Виталий Шишкин (@JCD3nt0n).

Иллюзия безопасности: почему мониторинг рантайма — это необходимость

Давайте сначала сравним защиту контейнерной среды с комплексной системой безопасности крупного делового района, а затем разберем подробнее логику работы нашего нового продукта.

Представим, что наш кластер Kubernetes — это квартал с множеством отдельных бизнес‑центров (контейнеров). Во всех зданиях стоят прочные двери и умные замки (тщательный харденинг хостов, кластера, сетей), а на входе охрана проверяет каждого посетителя (сканирование образов на уязвимости). Казалось бы, безопасность на высоте — но даже это не гарантирует стопроцентной защищенности. Злоумышленник может найти лазейку (например, ошибку в настройках) и проникнуть внутрь одного из зданий. Внешняя охрана этого не увидит.

Именно поэтому нужна внутренняя служба безопасности. Прямо в стены и коммуникации зданий (в ядро операционной системы) встраиваются высокоэффективные, почти невидимые датчики (технология eBPF). Специальный сотрудник (Tetragon) в реальном времени отслеживает данные, полученные с них (какую программу запустили, к какому файлу обратились, какое сетевое соединение установили). Вся эта информация стекается в единый центр управления (интерфейс Runtime Radar), где умная система знает шаблоны привычного поведения офисных работников и бьет тревогу в случае выявления аномалий (запуск вредоносного скрипта, несанкционированный доступ к данным или скрытое сетевое подключение). А полная хронология событий позволяет восстановить цепочку атаки для расследования.

Таким образом, современные контейнерные среды требуют эшелонированной защиты — ее фундамент составляют безопасная сборка и конфигурация. А предотвращать угрозы в реальном времени помогает непрерывное наблюдение за работой контейнеров. Благодаря нашему решению с открытым кодом даже небольшие команды могут быстро внедрить базовый контроль над контейнерной инфраструктурой без приобретения дорогостоящих продуктов.

Фундамент для защиты рантайма контейнеров

Единственный способ достоверно увидеть все, что происходит внутри контейнеров, — заглянуть в ядро операционной системы, где обрабатываются ключевые события. Для этой задачи продукт использует два де‑факто стандартных в индустрии инструмента: технологию eBPF и агент Tetragon.

Extended Berkeley Packet Filter, eBPF — это технология ядра Linux, которая позволяет безопасно запускать специальные программы для глубокого анализа работы системы без перезагрузки или изменения кода приложений. Благодаря eBPF мы видим любое низкоуровневое событие и можем отследить, какая именно программа запустила процесс, к какому файлу она обратилась и с каким сетевым портом установила соединение.

Сам по себе eBPF — это механизм, и, чтобы его использовать, нужен агент. Tetragon — один из наиболее популярных open‑source‑агентов, который как раз и превращает возможности eBPF в структурированные данные. Tetragon настраивает, какие именно события ядра собирать. Более того, он автоматически обогащает их контекстом Kubernetes: сразу видно, в каком поде, неймспейсе и на какой ноде произошло событие. Это критически важно, потому что без контекста невозможно понять, нормально ли поведение контейнера или это атака.

Tetragon невероятно гибок: отслеживать можно практически любое действие в системе. Однако в этом и кроется его сложность. Специалист должен сам определить, какие события собирать, как их фильтровать от шума и интерпретировать. В противном случае без правильно настроенных фильтров возникнет риск перегрузки узла, а без продуманной логики детектирования можно пропустить угрозы. Все это существенно замедляет и усложняет внедрение полноценного мониторинга рантайма в контейнерных средах.

Runtime Radar: готовое решение на мощном фундаменте

Именно необходимость в глубокой экспертизе для настройки eBPF и Tetragon и послужила причиной создания нашего инструмента. Мы взяли мощную базу и решили ключевые проблемы ее администрирования.

Внедрение продукта занимает считаные минуты и не создает операционной нагрузки для сотрудников. Развертывание решения в кластере Kubernetes выполняется одной командой Helm и не требует месяцев настройки: система начинает собирать события и анализировать их на предмет угроз сразу после установки. Ниже представлена команда для развертывания решения в кластере Kubernetes.

helm install runtime-radar -n runtime-radar --create-namespace oci://ghcr.io/runtime-radar/runtime-radar:v0.1.0 \
  --set 'global.ownCsUrl=https://your-domain.com:32000' \
  --set 'global.keys.publicAccessTokenSalt=INIT-DO-NOT-USE' \
  --set 'global.keys.encryption=INIT-DO-NOT-USE' \
  --set 'auth-center.administrator.username=admin' \
  --set 'auth-center.administrator.password=Password' 
  --set 'reverse-proxy.service.type=NodePort' \
  --set 'reverse-proxy.service.nodePorts.http=32000'

Пользователи Runtime Radar получают предварительно настроенный набор источников данных. Согласно предустановленным политикам, система фокусируется на релевантных для безопасности операциях и отсекает весь фоновый шум.

Поскольку сам по себе Tetragon лишь собирает события, мы добавили к нему высокопроизводительный движок анализа и библиотеку готовых детекторов. Другими словами, в наше решение уже встроена экспертиза по обнаружению атак: Runtime Radar выявляет подозрительную активность разного рода — от запуска реверс-шеллов до получения несанкционированного доступа к чувствительным данным.

Пользователи также могут писать собственные детекторы на языке Go. Это позволяет адаптировать систему под специфику конкретного стека технологий и искать угрозы, характерные для определенных сервисов и процессов, обеспечивая максимальное покрытие. Пример кода детектора — ниже.

func (d Detector) Detect(ctx context.Context, req *api.DetectReq) (*api.DetectResp, error) {
	// Detector info added to DetectResp because detector info is always correlated to response, thus
	// to avoid +1 Wasm call on detect.
	resp := &api.DetectResp{
		Id:          ID,
		Name:        Name,
		Description: Description,
		Version:     Version,
		Author:      Author,
		Contact:     Contact,

		// Default response indicates that nothing detected (this is redundant and put here just for reference,
		// as Severity == api.DetectResp_NONE == 0 when omitted (default zero value)).
		Severity: api.DetectResp_NONE,
	}

	event := req.GetEvent().GetEvent()

	switch ev := event.(type) {
	case *tetragon.GetEventsResponse_ProcessExec:
		// Nothing here
	case *tetragon.GetEventsResponse_ProcessExit:
		// Nothing here
	case *tetragon.GetEventsResponse_ProcessKprobe:
		kprobe := ev.ProcessKprobe
		functionName := kprobe.GetFunctionName()

		if strings.HasSuffix(functionName, "sys_io_uring_setup") {
			resp.Severity = api.DetectResp_MEDIUM // <-- threat detected

			return resp, nil
		}

		return resp, nil

	case *tetragon.GetEventsResponse_ProcessTracepoint:
		// Nothing here
	}

	return resp, nil
}

Кроме того, Runtime Radar превращает анализ инцидентов из многочасового квеста по логам в быстрое и понятное расследование. Остановимся на этом подробнее.

Не только детектирование: как Runtime Radar помогает расследовать атаки

Классическая проблема при расследовании атак в Kubernetes — отсутствие полной и связной картины событий. Стандартные логи часто не помогают ответить на ключевые вопросы: как злоумышленник попал внутрь, что именно он делал, какие данные были затронуты. Наш продукт решает эту проблему, позволяя в несколько кликов восстановить полную цепочку событий.

Интерфейс решения позволяет:

• фильтровать события по времени, неймспейсу, имени пода и сработавшим детекторам — чтобы быстро сфокусироваться на ключевых моментах атаки;

• видеть цепочки процессов — чтобы понимать, как одна подозрительная операция (например, запуск командной оболочки) привела к другой (чтение переменных среды, доступ к базе данных).

Приведем пример типового расследования. Представим, что произошла утечка данных из кластера. Вместо того чтобы просматривать тысячи записей, аналитик:

1. Указывает в интерфейсе период, когда был зафиксирован инцидент.

2. Выбирает фильтр «Только события с детекторами» — система сразу показывает подозрительные активности.

3. Находит событие «Подозрительный запуск командной оболочки» в конкретном поде.

4. Изучает цепочку: видит, что после запуска оболочки был выполнен запрос к переменным среды, а затем — подключение к базе данных с использованием извлеченных учеток.

При этом для баланса между детализацией и нагрузкой можно настроить, какие события сохранять. Так, в режиме «Только угрозы» записываются исключительно события, по которым сработали детекторы. Это экономит ресурсы и упрощает анализ. Однако для глубокой форензики можно получать все собранные события через Public API.

Production ready: как Runtime Radar работает в сложных инфраструктурах

При внедрении рантайм‑защиты в реальную инфраструктуру команды сталкиваются с тремя ключевыми вызовами: это централизованное управление сложной средой, интеграция с существующими процессами и обеспечение отказоустойчивости под нагрузкой. Архитектура Runtime Radar позволяет справиться с каждым из них.

Единое управление множеством кластеров

Наше решение освобождает специалистов от администрирования каждого кластера по отдельности. Компонент Cluster Manager позволяет подключать, настраивать и мониторить несколько независимых Kubernetes‑окружений (dev, stage, prod, разные облака) из единого веб‑интерфейса. Для каждого из них можно задать индивидуальные политики безопасности, что обеспечивает гибкость и соответствие требованиям разных сред.

Глубокая интеграция с экосистемой безопасности

Обнаружение угроз должно незамедлительно запускать процессы реагирования. Runtime Radar поддерживает широкий спектр стандартных протоколов и механизмов интеграции. Так, через сервис Notifier можно гибко настраивать отправку алертов в SIEM‑решение и в системы управления логами (через syslog), мессенджеры и тикет‑сервисы (через webhook), а также на электронную почту (через SMTP). Адаптировать формат сообщений под внутренние стандарты компании можно с помощью Go template.

Отказоустойчивость и масштабирование под нагрузку

Архитектура продукта изначально рассчитана на работу в высоконагруженных продакшен‑средах.

Микросервисная архитектура позволяет горизонтально масштабировать критически важные компоненты (например, движок обработки событий) и запускать их в нескольких репликах. Это гарантирует, что отказ отдельного пода не остановит мониторинг.

Для обработки больших объемов информации мы рекомендуем развертывать базы данных (ClickHouse, PostgreSQL) вне основного кластера, на выделенных виртуальных машинах. Это не только повышает доступность данных, но и снимает нагрузку с рабочих нод Kubernetes.

Внутреннее взаимодействие микросервисов организовано через обратный прокси‑сервер, повышающий надежность сетевых вызовов. А гибкая настройка лимитов ресурсов (CPU, памяти) для каждого компонента позволяет предотвратить их аварийную остановку и обеспечить стабильную работу при пиковой нагрузке.

Open source как основа для доверия и развития

Инструменты для мониторинга рантайма имеют высочайший уровень доступа к системе. И часто команды, отвечающие за надежность и безопасность инфраструктуры, не готовы внедрять black‑box‑решения. К тому же DevOps‑инженеры привыкли дорабатывать и кастомизировать инструменты под свои задачи. Runtime Radar создан с открытым исходным кодом (лицензия Apache 2.0) в ответ на требования рынка к прозрачности и гибкости.

Кроме того, контейнерные инфраструктуры и кластеры Kubernetes невероятно разные и отличаются своей спецификой. Покрыть все возможные корнер‑кейсы силами только одного вендора достаточно сложно. Мы в Positive Technologies верим, что защита контейнеров — наша общая задача, а наращивание экспертизы силами комьюнити — наиболее эффективный путь.

И, наконец, наш открытый продукт делает защиту рантайма доступнее для широкого круга пользователей. Если у команд есть запрос на комплексное обеспечение безопасности контейнеризированных приложений во время их сборки, развертывания и выполнения, то стоит рассмотреть PT Container Security, частью которого и является Runtime Radar.

Выводы

В современных динамичных и сложных контейнерных средах даже при максимально безопасной настройке существует риск взлома через мисконфигурацию или неучтенную уязвимость. Поэтому такие классические методы, как харденинг кластера, сканирование образов и CI/CD проверки, необходимы, но недостаточны. Критически важный эшелон защиты — мониторинг рантайма. Открытое решение Positive Technologies обнаруживает атаки внутри контейнеров в реальном времени и предоставляет удобные инструменты для расследования инцидентов. Runtime Radar актуален как для enterprise‑сегмента, так и для небольших команд.

Проект открыт для использования и развития на GitHub. Присоединяйтесь к сообществу!