Kubernetes Audit

Kubernetes Audit #

Продолжаем серию статей по Kubernetes в новом формате.

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

Оглавление

• Что такое аудит
• Политика аудита
• Параметры фильтрации
• Уровни логирования
• Стадии omitStages
• Подавление системного шума
• Фильтрация по пользователям
• Защита чувствительных данных
• Детализация для важных API
• Настройка API-сервера
• Заключение
• Бонус: пример Yandex Cloud

Что такое аудит

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

Аудит-события формируются согласно политике, описанной в конфигурационном файле. Каждое событие содержит:

• временную метку.
• идентификатор пользователя (если есть).
• запрашиваемый ресурс и действие.
• результат (успех/отказ).
• уникальный auditID, по которому можно отследить цепочку вызовов.

Сами события можно направить в файл, на удалённый webhook или в систему логирования.

Политика аудита

Политика аудита — это YAML-файл, описывающий набор правил, определяющих, какие события нужно логировать и с какой степенью детализации. Каждое правило состоит из условий (фильтров) и уровня логирования level, который задаёт объём сохраняемой информации.

API-сервер обрабатывает список правил сверху вниз и применяет первое подходящее. Если ни одно правило не сработает, применяется поведение по умолчанию или пропуск события.

Параметры фильтрации

Ниже перечислены атрибуты, которые можно использовать для настройки фильтрации событий:

Параметр	Описание	Пример значения
level	Уровень детализации	None, Metadata, Request, RequestResponse
users, userGroups	Фильтрация по пользователю или группе	system:serviceaccount:default:my-app
verbs	Операции над ресурсами	get, list, watch, create, update, patch, delete, deletecollection, proxy, redirect, head
resources	Целевые объекты Kubernetes	pods, configmaps
namespaces	Ограничение по namespace	default, kube-system
nonResourceURLs	Запросы к системным путям вне API-объектов	/metrics, /healthz
omitStages	Исключение стадий обработки	RequestReceived, ResponseStarted, ResponseComplete, Panic

Уровни логирования

Значение	Описание
None	Не логировать событие вообще
Metadata	Логируются только метаданные запроса (пользователь, ресурс, verb и т.п.)
Request	Логируются метаданные и тело запроса. Ответ не логируется
RequestResponse	Логируются метаданные, тело запроса и тело ответа

Стадии omitStages

Стадия	Описание
RequestReceived	Запрос получен API-сервером, но ещё не обработан
ResponseStarted	Началась отправка ответа клиенту
ResponseComplete	Запрос полностью завершён
Panic	Обработка запроса завершилась с фатальной ошибкой

Примеры политик аудита

Эти примеры помогут вам начать настройку аудита в Kubernetes. Они покрывают основные сценарии и позволяют адаптировать политику под ваши нужды.

Подавление системного шума

к сведению

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

Описание	Пример
Подавление шума от kube-apiserver Не нужно, если вы хотите видеть все технические запросы самого API-сервера (например, для глубокого аудита внутренних процессов). Обычно эти события не нужны для анализа пользовательских действий.
Подавление шума от kube-controller-manager Не нужно, если требуется полный аудит работы контроллеров (например, для отладки их логики). В большинстве случаев эти события только засоряют аудит.
Подавление шума от kube-scheduler Не нужно, если вы анализируете работу планировщика. Для большинства пользователей эти события не представляют интереса.
Подавление шума от kubelet Не нужно, если требуется аудит всех действий kubelet и нод. Обычно эти события нужны только для диагностики проблем с нодами.

Фильтрация по пользователям

к сведению

Фильтрация событий по пользователям и группам позволяет сосредоточиться на действиях, которые имеют значение для безопасности кластера. Например использование системных групп, таких как system:masters у которых есть полный доступ к кластеру.

Описание	Пример
Логирование действий группы system:masters

Защита чувствительных данных

Важно!

Защита чувствительных данных важна в Kubernetes, особенно если вы не используете внешние решения для управления секретами, такие как HashiCorp Vault или Sealed Secrets.

Описание	Пример
Логирование действий с секретами и токенами.

Детализация для важных API

Важно!

Также в Kubernetes предостаточно ресурсов, которые могут быть использованы для эскалации привилегий — например, ролевые политики (RBAC), workload-ресурсы (Deployments, Pods) и Admission-ресурсы. Логирование действий над этими ресурсами позволяет отслеживать изменения и выявлять потенциальные угрозы безопасности.

Описание	Пример
Логирование действий над ролевой политикой. Сценарии: аудит изменений RBAC для расследования эскалации прав, выявления несанкционированных изменений ролей и доступа.
Логирование действий над workload. Сценарии: аудит изменений деплойментов, расследование инцидентов с запуском/удалением подов, отслеживание ручных вмешательств в workload.
Логирование действий над Admission ресурсами. Сценарии: отладка и аудит Admission Webhook, расследование проблем с политиками валидации/мутации, контроль за изменениями admission-правил.

Настройка API-сервера

Для активации аудита укажите путь к файлу политики:

--audit-policy-file=/etc/kubernetes/audit-policy.yaml
--audit-log-path=/var/log/kubernetes/audit/audit.log

Обратите внимание!

Хочу обратить ваше внимание, что конфигурационные файлы политик загружаются в API-сервер только при его запуске. Поэтому, если вы измените политику, вам нужно будет перезапустить API-сервер, чтобы изменения вступили в силу.

Заключение

Аудит Kubernetes — мощный инструмент безопасности. Грамотная настройка политик позволяет отслеживать действия пользователей и сервисов, минимизировать утечки данных и сосредоточиться на критически важных событиях. Примеры политик в статье — отправная точка, но аудит всегда пишется под требования вашей компании и инфраструктуры.

Базовые рекомендации

• Подавляйте системный шум (например, от внутренних компонентов)
• Фильтруйте по пользователям и группам
• Логируйте только метаданные для чувствительных данных (секреты, токены)
• Детализируйте только важные API (CRD, Admission, Webhook)
• Декомпозируйте политки на модули для удобства управления
• Используйте omitStages для снижения объёма логов
• Регулярно пересматривайте и обновляйте политику в зависимости от изменений в кластере
• Тестируйте политику на тестовом кластере перед применением в продакшн
• Используйте инструменты для анализа и визуализации аудита (например, ELK Stack, Loki, Grafana)

Бонус: пример Yandex Cloud

Пример политики Yandex Cloud — хороший старт для создания собственной политики аудита.

Описание	Пример
Логирование действий над ролевой политикой.