Тепловые карты безопасности Kubernetes

Когда в инфраструктуре десятки production-кластеров Kubernetes, сотни namespace и тысячи подов, классический security-сканинг перестаёт работать. Отчёты генерируются, нарушения фиксируются, но когда вы открываете очередной дашборд, вы видите просто список. Плоский, без приоритетов, без контекста.

Куда идти первому? Какой команде нужна помощь? Где риск критичен, а где просто шум?

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

Что такое тепловая карта безопасности

Тепловая карта — это визуальное представление состояния кластеров, где каждая ячейка отражает уровень риска или количество нарушений. В отличие от плоского списка, карта позволяет:

1. Видеть приоритеты — где концентрация проблем выше
2. Сравнивать команды — кто в «красной зоне», кто уже привёл дела в порядок
3. Отслеживать динамику — как меняется состояние от недели к неделе
4. Определять точки роста — куда направить ресурсы команды безопасности

Ключевая идея: безопасность должна быть видимой и измеримой. Когда проблема визуализирована, с ней проще работать — и технически, и организационно.

Откуда берутся данные

Тепловая карта не появляется сама по себе. Это результат сбора и агрегации данных из нескольких источников.

Источники данных:

1. Policy Reports — результаты работы admission controller. Основной источник данных о нарушениях в кластерах.
2. Trivy Operator — сканирование уязвимостей в образах, работающих в кластерах.
3. Runtime-телеметрия — данные от Tetragon или Falco об аномалиях и подозрительной активности.
4. Внутренние сканы — кастомные проверки через Kyverno-политики.

Размерности агрегации:

1. Кластер
2. Команда-владелец (определяется через namespace)
3. Тип политики / правило
4. Критичность
5. Временной срез

Пайплайн данных:

Кластер → Сборщик → Центральный Prometheus + Loki → Grafana → Дашборд

В каждом кластере работает агент, который собирает данные и отправляет в центральное хранилище. Prometheus отвечает за метрики, Loki — за логи. Grafana визуализирует и предоставляет drill-down: от общего парка кластеров → к конкретному кластеру → к команде → к конкретному нарушению.

Обновление дашборда — каждые 5 минут. Алерты на дрифт (резкое изменение показателей) уходят в команду безопасности.

Как это выглядит на практике

Первый запуск тепловой карты часто приносит неприятные открытия. Кластер, в котором не было деплоев полгода, может содержать десятки нарушений: привилегированные поды, hostNetwork, открытые дашборды, сервис-аккаунты с правами cluster-admin.

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

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

Что показывает карта:

1. По кластерам — общая картина парка, видно «горячие точки»
2. По командам — рейтинг покрытия baseline-политик, без палок и наказаний
3. По правилам — какие типы нарушений встречаются чаще всего

Отдельно стоит сказать про геймификацию. Когда команды видят, что их кластер «красный», а у соседей «зелёный», появляется естественная мотивация исправить ситуацию. Работает лучше, чем тикеты и эскалации.

Обнаружение аномалий: чего не видно в манифестах

Admission controller ловит нарушения на этапе деплоя — но только новые. То, что уже работает в кластерах, остаётся вне зоны видимости. И здесь на помощь приходит runtime-телеметрия.

Как это работает:

1. Сбор данных — метрики, логи, события безопасности стекаются в центральное хранилище
2. Нормализация — данные приводятся к единому формату
3. Обогащение — добавляется контекст: namespace, команда, критичность, playbook
4. Детект — правила срабатывают на отклонения: всплеск активности, нетипичное время, массовое чтение секретов
5. Алерт — уведомление уходит в мессенджер с полным контекстом

Пример аномалии:

Атакующий получил доступ к ноде и начал массово читать токены сервис-аккаунтов. В логах это выглядит как сотни запросов за секунды. Без автоматики это можно заметить только постфактум. С автоматикой — алерт приходит через 9 секунд, с указанием пода и полного пути к файлу.

Например, такой подход — сочетание admission control, runtime-детекта и визуализации — реализован в облачной платформе MWS Cloud Platform. Тепловые карты там строятся на данных Kyverno, Trivy и Tetragon, а аномалии детектируются в реальном времени.

Трекинг и культура: без этого карта не работает

Тепловая карта — это технология. Но технология не работает в вакууме. Нужны процессы:

1. Алерт при новом High Severity — команда получает уведомление в мессенджер, тикет заводится автоматически.
2. Рейтинг команд — процент покрытия baseline-политик. Не для наказания, а для прозрачности.
3. Квартальные ревью — с лидами команд обсуждаем, что появилось, что закрыто, чем помочь.
4. Экземпшены с TTL — если команда не может исправить нарушение сейчас, оформляется исключение с владельцем и сроком жизни. Просроченный экземпшен — закрытие и уведомление владельца.

Важный принцип: прозрачность вместо наказаний. Когда команда понимает, зачем нужна политика, и видит прогресс — она сама начинает двигаться в нужную сторону.

Что это даёт бизнесу

Тепловая карта — это не только технический инструмент. Это ещё и артефакт для чейндж-менеджмента и коммуникации с руководством.

1. Видимость — руководство видит реальное состояние безопасности, а не абстрактные отчёты
2. Приоритизация — ресурсы направляются туда, где риск максимален
3. Динамика — можно отслеживать прогресс по неделям и месяцам
4. Ответственность — у каждого кластера есть владелец, у каждого нарушения — команда

В контексте облачной платформы это особенно важно. Когда у вас десятки кластеров и сотни команд, ручное управление безопасностью невозможно. Нужна автоматизация и визуализация.

Тепловые карты безопасности — это переход от реактивного сканирования к проактивному управлению рисками. Они делают безопасность видимой, измеримой и управляемой.

Если вы строите облачную инфраструктуру на Kubernetes и хотите, чтобы безопасность была не «тормозом», а частью процесса — начните с визуализации. Соберите данные, постройте карты, определите приоритеты. И помните: цель не в том, чтобы все ячейки были зелёными любой ценой, а в том, чтобы вы понимали, где находитесь и куда движетесь.