Аудит-политика Kubernetes: чек-лист против типовых слепых зон в правилах

Правила аудита в Kubernetes — один из ключевых, но часто недооценённых механизмов безопасности. Они определяют, какие действия в кластере будут зафиксированы, а какие останутся незамеченными. Проблема в том, что политика, как правило, настраивается один раз при первичном развертывании и в дальнейшем почти не пересматривается целиком. В результате конфиг превращается в набор исторических исключений, где новые компоненты добавляются «по мере необходимости», а глубинная логика давно устарела. Особенно показателен пример с конфигурацией на ~580 строк, собранной из нескольких источников и основанной на Kubernetes Threat Matrix. При детальном перечитывании такого файла всплывают не точечные ошибки, а системные проблемы подхода: слепые зоны, в которых события либо не логируются вовсе, либо фиксируются в таком объёме, что полезная информация тонет в шуме.

Подробности

Аудит-политика Kubernetes строится на правилах, которые группируют события по уровням детализации — от None до RequestResponse. Ключевая сложность — корректно определить, какие именно субъекты и действия должны попадать в лог, а какие нет. Типовые слепые зоны, выявленные в ходе ревью: - **Избыточное доверие к системным компонентам.** Часто правила исключают из аудита сервисные аккаунты системных пространств имён (kube-system, kube-public), считая их заведомо безопасными. При этом скомпрометированный под такой аккаунт процесс получает возможность действовать скрытно. - **Недостаточное покрытие операций с секретами.** Правила могут логировать чтение Secret, но пропускать операции получения списков (list), обновления или создания — а это вектор для горизонтального перемещения. - **Игнорирование операций exec и port-forward.** Подключение к работающему контейнеру через exec по своей опасности сопоставимо с получением shell-доступа, однако нередко не отделено от прочих под-операций. - **Некорректная обработка anonymous-запросов.** Если анонимный доступ разрешён, а политика аудита его не выделяет в отдельную категорию, следы атак со стороны неаутентифицированных пользователей будут нечитаемы. - **Устаревшие правила и исключения.** Комментарии «трёхлетней давности», неактуальные для текущего состава компонентов, — главный источник ложного чувства безопасности. Отдельная боль — уровень детализации. Правила уровня Metadata позволяют фиксировать сам факт запроса без тела и ответа — это компактно, но не даёт материала для расследования. RequestResponse, напротив, полезен при работе с секретами, но создаёт огромные объёмы данных, которые требуют настройки хранилища и фильтрации.

Что делать

Чек-лист, который стоит применять при написании или ревью аудит-политики: 1. **Пересматривайте политику целиком** минимум раз в квартал, а не только добавляйте исключения для новых компонентов. Старые правила нередко теряют актуальность. 2. **Проверяйте покрытие для системных аккаунтов** — не исключайте пространства имён без дополнительного обоснования. 3. **Выделяйте в отдельные правила** чувствительные операции: чтение и изменение Secret, ConfigMap с данными доступа, операции exec, attach, port-forward. 4. **Разделяйте anonymous-запросы в отдельный уровень аудита** — если анонимный доступ используется, он должен быть максимально прозрачен. 5. **Соотносите уровни детализации с чувствительностью.** Для операций с секретами используйте RequestResponse, для массовых операций — Metadata, чтобы избежать шума. 6. **Сверяйтесь с актуальными источниками угроз**, такими как Kubernetes Threat Matrix, — это помогает находить сценарии, о которых вы могли не подумать. 7. **Ведите реестр исключений с указанием владельца и срока действия** — это не даст правилам превратиться в застывший слой исторических комментариев. Системный подход к ревизии позволит не только сократить объём бесполезных логов, но и обнаружить события, которые сейчас проходят незамеченными. Главное — помнить: аудит-политика такой же код, как и любой другой, её нужно поддерживать, ревьюить и развивать вместе с инфраструктурой.

Источник: Хабр — Информационная безопасность