Аудит-политика Kubernetes: чек-лист для поиска типовых слепых зон
Аудит Kubernetes нередко настраивают один раз - во время создания кластера, - а затем годами дополняют отдельными исключениями. В результате конфигурация разрастается, обрастает устаревшими комментариями и перестаёт быть понятной даже тем, кто её когда-то писал. Вместо управляемого инструмента безопасности появляется набор исторических компромиссов.
Полноценный аудит-политики нужен не только для проверки синтаксиса. Важно понять, какие действия действительно фиксируются, какие намеренно исключены, не скрываются ли опасные операции за слишком широкими правилами и не конфликтуют ли отдельные секции между собой.
Как работает Audit Policy
Аудит-политика Kubernetes состоит из правил. Каждое правило определяет, какие запросы необходимо сопоставить:
- с какими пользователями или группами они связаны;
- какой сервисный аккаунт выполняет действие;
- какой используется verb;
- к какому ресурсу обращаются;
- какой уровень детализации нужно применить.
Уровень аудита может варьироваться от `None`, при котором событие не записывается, до `RequestResponse`, сохраняющего запрос и ответ API-сервера целиком, включая тела сообщений.
Критически важно помнить: правила обрабатываются сверху вниз, а для запроса применяется первое совпадение. Если широкое исключение расположено раньше узкого правила для чувствительного ресурса, до последнего дело не дойдёт. Поэтому основная проблема при ревью часто связана не с отдельными строками, а с их порядком.
Принцип № 1: отделяйте полезные события от шума
В рабочем кластере большая часть запросов приходится на операции `get`, `list` и `watch`. Их постоянно выполняют kubelet, контроллеры, операторы, системы мониторинга и сетевые компоненты. Если записывать весь такой трафик с высокой детализацией, журналы быстро разрастаются, а поиск подозрительного действия превращается в анализ огромного объёма однотипных событий.
Разумный подход - исключать только заведомо безопасные потоки и делать это максимально точно. В правиле желательно указывать одновременно:
- конкретного пользователя или сервисный аккаунт;
- допустимые verbs;
- перечень ресурсов;
- при необходимости - группу API и namespace.
Например, если компонент штатно только отслеживает состояние объектов, исключение должно ограничиваться чтением и наблюдением. Нельзя автоматически отключать аудит для всех действий, выполняемых этим аккаунтом.
Ловушка № 1: исключение без verbs и resources
Опасный вариант выглядит примерно так: правило исключает сервисный аккаунт, но не ограничивает его конкретными операциями и объектами. Формально оно может быть добавлено ради снижения шума от `get/list/watch`, однако фактически скрывает любые действия данного аккаунта.
Если позже ему выдадут права на изменение ресурсов, мутации также перестанут попадать в аудит. То же произойдёт при ошибке в RBAC или компрометации токена: злоумышленник сможет выполнять операции, оставаясь вне поля зрения журналирования.
Практическое правило простое: каждое исключение должно явно фиксировать разрешённые verbs. Если компонент сегодня выполняет только чтение, это нужно отразить в политике. Завтра его поведение может измениться, но новое действие тогда не исчезнет из аудита автоматически.
Ловушка № 2: комментарии не соответствуют логике
Комментарии в YAML не влияют на работу API-сервера, но напрямую влияют на качество сопровождения. Особенно опасны ситуации, когда рядом с правилом написано "критически важное событие", а само правило устанавливает уровень `None`.
Такая ошибка не ломает конфигурацию, но вводит инженеров в заблуждение. Через несколько месяцев другой специалист может ориентироваться на комментарий, а не на фактическое поведение правила, и потратить значительное время на выяснение, почему нужные события отсутствуют.
Комментарии следует проверять так же внимательно, как и саму логику. Они должны объяснять назначение исключения, ограничения по ресурсам и причину выбранного уровня аудита. Если причина больше не актуальна, комментарий необходимо удалить или переписать.
Ловушка № 3: правила от старых миграций
Инфраструктура Kubernetes постоянно меняется: заменяются CNI, ingress-контроллеры, операторы и системы мониторинга. После миграции старые исключения нередко остаются в политике.
Например, сетевой компонент был заменён, но правило для его прежнего сервисного аккаунта продолжает находиться в конфигурации. На текущую работу оно не влияет, если такого аккаунта уже нет, однако создаёт несколько проблем:
- увеличивает объём и сложность файла;
- мешает понимать реальную модель аудита;
- усложняет ревью;
- может неожиданно начать действовать, если в будущем появится аккаунт с тем же именем.
Полезно регулярно сопоставлять пользователей и сервисные аккаунты, указанные в исключениях, с объектами, реально существующими в кластере. Для этого можно использовать стандартный просмотр сервисных аккаунтов во всех namespace и затем удалить неактуальные записи.
Принцип № 2: для чувствительных данных выбирайте минимально необходимый уровень
Аудит не должен превращаться в копию всех секретных данных, проходящих через API. Для большинства чувствительных объектов разумным базовым уровнем является `Metadata`: он позволяет узнать, кто, когда и с каким объектом работал, не сохраняя содержимое запроса и ответа.
Это особенно важно для:
- Secret;
- ConfigMap с паролями и токенами;
- объектов, содержащих персональные данные;
- ресурсов с внутренними ключами и сертификатами.
Хранение тел запросов может привести к утечке данных в систему логирования, резервные копии или аналитическую платформу. Поэтому перед использованием `Request` или `RequestResponse` следует оценить, действительно ли содержимое объекта необходимо для расследования.
Принцип № 3: RequestResponse применяйте только там, где это оправдано
Максимальная детализация полезна для отдельных операций, например при исследовании критических изменений в RBAC, настройках доступа или жизненном цикле некоторых системных объектов. Но включать её глобально не стоит.
Высокий уровень аудита увеличивает:
- объём журналов;
- нагрузку на API-сервер;
- требования к хранилищу;
- риск попадания секретов в логи;
- стоимость обработки и хранения событий.
Перед включением `RequestResponse` нужно определить срок хранения, права доступа к журналам, правила маскирования и порядок удаления данных. Логи аудита сами являются чувствительным активом и должны защищаться не слабее, чем основные системные ресурсы.
Принцип № 4: порядок правил должен быть намеренным
Любая политика должна читаться сверху вниз как последовательность приоритетов. Обычно в начале размещают специальные исключения, затем правила для важных ресурсов, а в конце - общий fallback для остальных запросов.
При ревью полезно задавать для каждого правила три вопроса:
1. Какие запросы оно сопоставляет?
2. Не перекрывает ли его более ранняя секция?
3. Не делает ли оно недостижимыми правила, расположенные ниже?
Особое внимание следует уделять универсальным правилам с пустыми или слишком широкими полями `users`, `resources`, `verbs` и `namespaces`. Такие конструкции могут незаметно закрыть аудит большого класса операций.
Дополнительные проверки для качественного ревью
Сверяйте политику с RBAC
Аудит-политика и RBAC решают разные задачи, но их нужно анализировать совместно. Если сервисному аккаунту выдали новые права, убедитесь, что действия, которые он теперь может выполнять, не попадают под старое исключение.
Отдельно проверяйте операции изменения доступа
Создание и изменение Role, ClusterRole, RoleBinding и ClusterRoleBinding должно хорошо отслеживаться. Эти ресурсы напрямую влияют на полномочия в кластере, поэтому отключать их аудит без веской причины опасно.
Контролируйте операции с токенами и секретами
Даже если содержимое объектов не записывается, факт обращения к ним должен оставаться видимым. Важно фиксировать пользователя, время, namespace, имя ресурса и результат операции.
Не забывайте о неуспешных запросах
Ошибки авторизации, запреты доступа и неожиданные `forbidden`-операции могут быть ранними признаками разведки или неверной настройки прав. Исключения, предназначенные для снижения шума, не должны скрывать неудачные попытки выполнения опасных действий.
Проверяйте результат на реальном трафике
После изменения политики необходимо протестировать несколько сценариев: обычное чтение, изменение ресурса, отказ в доступе, работу системного компонента и обращение к чувствительному объекту. Ожидаемый уровень аудита следует сравнить с фактическими событиями в журнале.
Мини-чек-лист
Перед публикацией изменений убедитесь, что:
- правила идут в осмысленном порядке;
- исключения ограничены конкретными verbs и ресурсами;
- нет широких правил `None` для системных аккаунтов;
- комментарии соответствуют фактической логике;
- удалены записи от старых компонентов;
- чувствительные объекты не логируются с лишним содержимым;
- `RequestResponse` используется точечно;
- изменения RBAC и доступ к секретам фиксируются;
- неуспешные запросы не теряются;
- политика проверена на реальном трафике;
- доступ к журналам аудита ограничен;
- настроены хранение, ротация и контроль объёма логов.
Хорошая Audit Policy - это не максимально подробная конфигурация. Её задача - сохранить значимые события, не утонув в техническом шуме, и при этом не оставить опасных исключений, через которые критические действия исчезают из наблюдения. Регулярное ревью, проверка порядка правил и сопоставление политики с реальными правами кластера позволяют превратить аудит из формального файла в рабочий инструмент обнаружения и расследования инцидентов.