Аудит
Для диагностики операций с API, например, в случае неожиданного поведения компонентов управляющего слоя, в Kubernetes предусмотрен режим журналирования операций с API. Этот режим можно настроить путем создания правил Audit Policy, а результатом работы аудита будет лог-файл /var/log/kube-audit/audit.log со всеми интересующими операциями. Более подробно можно почитать в разделе Auditing в документации Kubernetes.
Базовые политики аудита
В кластерах Deckhouse по умолчанию созданы базовые политики аудита:
- логирование операций создания, удаления и изменения ресурсов;
- логирование действий, совершаемых от имени сервисных аккаунтов из системных пространств имён:
kube-system,d8-*; - логирование действий, совершаемых с ресурсами в системных пространствах имён:
kube-system,d8-*.
Отключение базовых политик
Отключить сбор логов по базовым политикам можно установив флаг basicAuditPolicyEnabled в false.
Пример включения возможности аудита в kube-apiserver, но без базовых политик Deckhouse:
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
name: control-plane-manager
spec:
version: 1
settings:
apiserver:
auditPolicyEnabled: true
basicAuditPolicyEnabled: false
Можно воспользоваться патчем:
d8 k patch mc control-plane-manager --type=strategic -p '{"settings":{"apiserver":{"auditPolicyEnabled":true, "basicAuditPolicyEnabled": false}}}'
Пользовательские политики аудита
Модуль control-plane manager автоматизирует настройку kube-apiserver для добавления пользовательских политик аудита. Чтобы такие дополнительные политики заработали, нужно удостовериться, что аудит включён в секции параметров apiserver и создать секрет с политикой аудита:
-
Включите параметр
auditPolicyEnabledв настройках модуля:apiVersion: deckhouse.io/v1alpha1 kind: ModuleConfig metadata: name: control-plane-manager spec: version: 1 settings: apiserver: auditPolicyEnabled: trueВключить можно редактированием ресурса, либо с помощью патча:
d8 k patch mc control-plane-manager --type=strategic -p '{"settings":{"apiserver":{"auditPolicyEnabled":true}}}' -
Создайте Secret
kube-system/audit-policyс YAML-файлом политик, закодированным в Base64:apiVersion: v1 kind: Secret metadata: name: audit-policy namespace: kube-system data: audit-policy.yaml: <base64>Для примера
audit-policy.yamlможно привести правило для логирования всех изменений в метаданных:apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: Metadata omitStages: - RequestReceivedС примерами и информацией о правилах политик аудита можно ознакомиться в:
- Официальной документации Kubernetes.
- Нашей статье на Habr.
- Коде скрипта-генератора, используемого в GCE.
В текущей реализации не валидируется содержимое дополнительных политик.
Если в audit-policy.yaml в политике будут указаны неподдерживаемые опции или будет допущена опечатка, то apiserver не запустится, что приведёт к недоступности управляющего слоя.
В таком случае для восстановления потребуется вручную убрать параметры --audit-log-* в манифесте /etc/kubernetes/manifests/kube-apiserver.yaml и перезапустить apiserver следующей командой:
crictl stopp $(crictl pods --name=kube-apiserver -q)
После перезапуска будет достаточно времени, чтобы удалить ошибочный секрет:
d8 k -n kube-system delete secret audit-policy
Как работать с журналом аудита?
Предполагается наличие на master-узлах сборщика логов (например, log-shipper, promtail, filebeat), который будет отправлять записи из файла в централизованное хранилище:
/var/log/kube-audit/audit.log
Параметры ротации файла журнала предустановлены и их изменение не предусмотрено:
- Максимальное занимаемое место на диске
1000 МБ. - Максимальная глубина записи
30 дней.
Учитывайте, что «максимальная глубина записи» не означает «гарантированная». Интенсивность записи в журнал зависит от настроек дополнительных политик и количества запросов к apiserver, поэтому фактическая глубина хранения может быть сильно меньше 7 дней, например, 30 минут. Это нужно принимать во внимание при настройке сборщика логов и при написании политик аудита.
Вывод аудит-лога в стандартный вывод
Если в кластере настроен сборщик логов с подов, можно собирать аудит лог, выведя его в стандартный вывод. Для этого в настройках модуля установите значение Stdout в параметре apiserver.auditLog.output.
Пример включения аудита с выводом в stdout:
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
name: control-plane-manager
spec:
version: 1
settings:
apiserver:
auditPolicyEnabled: true
auditLog:
output: Stdout
Можно воспользоваться патчем:
d8 k patch mc control-plane-manager --type=strategic -p '{"settings":{"apiserver":{"auditPolicyEnabled":true, "auditLog":{"output":"Stdout"}}}}'
После рестарта kube-apiserver, в его логе можно увидеть события аудита:
d8 k -n kube-system logs $(d8 k -n kube-system get po -l component=kube-apiserver -oname | head -n1)
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"38a26239-7f3e-402f-8c56-2fb57a3fe49d","stage":"ResponseComplete","requestURI": ...