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

Короткий ответ

Нужно проверить флаги --audit-log-path и --audit-policy-file на kube-apiserver и содержимое audit policy — часто аудит либо вовсе не включён, либо политика логирует только на уровне Metadata без тела запроса для критичных ресурсов; политику нужно настроить дифференцированно: подробный уровень (RequestResponse) для чувствительных ресурсов (Secrets, RBAC) и более лёгкий (Metadata) для остальных, чтобы не перегружать хранилище.

Как это работает подробнее

kube-apiserver пишет аудит-события согласно Audit Policy — конфигурации, определяющей, какие запросы логировать и с каким уровнем детализации (None/Metadata/Request/RequestResponse). Без явно заданной политики аудит по умолчанию может быть выключен (особенно в self-managed кластерах) или управляться отдельно в managed-сервисах (EKS/GKE/AKS имеют свои механизмы включения аудита через облачную консоль/API).

Пример кода

security-example-460.yamlКопировать

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
      - group: "rbac.authorization.k8s.io"
        resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
  - level: Metadata
    omitStages: ["RequestReceived"]

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

• Практика. для расследуемости действий (кто изменил/удалил ресурс) достаточно уровня Metadata (кто, что, когда), а детальный RequestResponse нужен для особо чувствительных ресурсов, где важно видеть изменённые данные (например, изменения RBAC-ролей); логи выгружают во внешнее неизменяемое хранилище (не на диск самого control plane, который может быть утрачен), настраивают retention согласно требованиям compliance.
• Проверка. Ожидаемое поведение: после применения политики и перезапуска kube-apiserver с --audit-policy-file и --audit-log-path изменения RBAC-ролей и Secret теперь полностью логируются с деталями запроса; проверить можно, выполнив тестовое изменение RoleBinding и найдя соответствующую подробную запись в файле аудит-лога.

Подводные камни

• Ошибка. включать RequestResponse для всех ресурсов без исключений, что резко увеличивает объём логов и нагрузку на API-сервер; хранить аудит-лог только локально на master-узле без выгрузки во внешнюю систему, рискуя потерять его при сбое узла; не пересматривать политику при добавлении новых чувствительных CRD в кластер.