Аудит событий API Kubernetes

Процедура аудита (Kubernetes auditing) позволяет отслеживать обращения к API-серверу и анализировать события, происходящие в кластере. Аудит может быть полезен для отладки неожиданных сценариев поведения, а также для соблюдения требований безопасности.

Kubernetes поддерживает настройку аудита через механизм Audit policy, который позволяет задавать правила логирования интересующих операций. Результаты аудита по умолчанию записываются в лог-файл /var/log/kube-audit/audit.log.

Встроенные политики аудита

В Deckhouse Virtualization Platform (DVP) по умолчанию разворачивается набор встроенных политик аудита. Они фиксируют следующие категории событий:

Общие события:

• Создание и удаление узлов кластера (объектов Node);
• Создание, изменение и удаление ресурсов во всех системных пространствах имён (kube-system, d8-*);
• Запросы от сервисных аккаунтов из системных пространств имён (kube-system, d8-*);
• Массовые запросы (LIST) ко всем ресурсам (для диагностики высокого потребления ресурсов API-сервером);
• Операции с ресурсами модуля virtualization;
• Действия в пространстве имён d8-virtualization;
• Операции с объектами ModuleConfig;
• Запросы от пользователей, не прошедших аутентификацию (логируются только события уровня Metadata).

События, подлежащие регистрации в соответствии с требованиями ФСТЭК к средствам контейнеризации:

• Создание, изменение и удаление объектов Pod;
• Использование тегов образов контейнеров, отличных от формата @sha256;
• Создание и удаление объектов ServiceAccount, в том числе в системных пространствах имён;
• Создание, изменение и удаление объектов Role и ClusterRole;
• Создание, изменение и удаление объектов ClusterRoleBinding;
• Использование команд attach и exec к Pod, а также добавление ephemeral-контейнеров (запросы и модификация объектов pods/exec, pods/attach, pods/ephemeralcontainers).

События, которые намеренно не фиксируются политикой аудита (из-за высокой частоты обновления соответствующих объектов):

• Операции с объектами типов Endpoints, EndpointSlice и Event;
• Операции с объектами Lease (выбор лидера raft в компонентах платформы);
• Действия с ConfigMap, используемыми для выбора лидера raft (cert-manager-cainjector-leader-election, cert-manager-controller, ingress-nginx и др.);
• Операции с объектами VerticalPodAutoscalerCheckpoints;
• Операции PATCH для объектов VerticalPodAutoscaler, выполняемые сервисным аккаунтом d8-vertical-pod-autoscaler-recommender;
• Операции с объектами UpmeterHookProbes;
• Любые операции в пространстве имён d8-upmeter.

Эти политики активны по умолчанию. Чтобы отключить их, установите параметр basicAuditPolicyEnabled в значение false.

Пример:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: control-plane-manager
spec:
  version: 1
  settings:
    apiserver:
      auditPolicyEnabled: true
      basicAuditPolicyEnabled: false

Настройка собственной политики аудита

Чтобы создать расширенную политику аудита API Kubernetes, выполните следующие шаги:

1. Включите параметр auditPolicyEnabled в настройках модуля control-plane-manager:

   apiVersion: deckhouse.io/v1alpha1
   kind: ModuleConfig
   metadata:
     name: control-plane-manager
   spec:
     version: 1
     settings:
       apiserver:
         auditPolicyEnabled: true
   

2. Создайте 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
   

   Источники с подробной информацией по настройке возможного содержимого файла audit-policy.yaml:

   • официальная документация Kubernetes;
   • статья из блога компании «Флант» на Habr;
   • код скрипта-генератора, используемого в GCE.

Работа с лог-файлом аудита

Предполагается, что на master-узлах кластера Deckhouse установлен инструмент для отслеживания лог-файла /var/log/kube-audit/audit.log: log-shipper, promtail или filebeat.

Параметры ротации логов в файле предустановлены и не подлежат изменению:

• максимальный размер файла: 1000 МБ;
• максимальная глубина записи: 30 дней.

В зависимости от настроек политики и объема запросов к API-серверу количество записей может быть очень большим. В таких условиях глубина хранения может составлять менее 30 минут.

В случае возникновения проблем с запуском API-сервера выполните следующие шаги:

1. Вручную удалите параметры --audit-log-* из манифеста /etc/kubernetes/manifests/kube-apiserver.yaml;

2. Перезапустите API-сервер с помощью следующей команды:

   docker stop $(docker ps | grep kube-apiserver- | awk '{print $1}')
      
   # Альтернативный вариант (в зависимости от используемого CRI).
   crictl stopp $(crictl pods --name=kube-apiserver -q)
   

3. После перезапуска исправьте Secret или удалите его с помощью следующей команды:

   d8 k -n kube-system delete secret audit-policy
   

Перенаправление лог-файла аудита в stdout

По умолчанию лог аудита сохраняется в файл /var/log/kube-audit/audit.log на master-узлах. При необходимости вы можете перенаправить его вывод в stdout процесса kube-apiserver вместо файла, установив параметр apiserver.auditLog.output модуля control-plane-manager в значение Stdout:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: control-plane-manager
spec:
  version: 1
  settings:
    apiserver:
      auditPolicyEnabled: true
      auditLog:
        output: Stdout

В этом случае лог будет доступен в stdout контейнера kube-apiserver.

Далее, используя встроенный механизм логирования в DVP, вы можете настроить сбор и отправку логов в собственную систему безопасности.