Включение audit-логов в платформе «Боцман» и подключение их к SIEM MaxPatrol 10

В данной инструкции описан порядок включения аудит-логов Kubernetes в кластере под управлением платформы «Боцман» и настройки отправки этих логов в SIEM MaxPatrol 10 с использованием Vector.

Когда это пригодится

Требование службы информационной безопасности — централизованный сбор и хранение аудит-логов Kubernetes
Необходимость анализа событий безопасности в SIEM-системе MaxPatrol 10
Расследование инцидентов с использованием данных аудита API-сервера

Предварительные требования

Платформа «Боцман» версии >= 3.1.0
Доступ к веб-интерфейсу платформы с правами на редактирование кластера
Доступ к консоли управления MaxPatrol 10 с правами на создание задач сбора данных
Развёрнутый и настроенный модуль Victoria Logs в управляющем кластере (см. Victoria Logs)
Понимание структуры политик аудита Kubernetes
Сетевой доступ от узлов кластера до syslog-коллектора MaxPatrol 10

Шаг 1. Включение аудит-логов Kubernetes

Все изменения вносятся в конфигурацию целевого кластера и автоматически применяются на всех его узлах, сохраняясь при перекатке (re-roll).

Внимание!

Процедура применения настроек аудита схожа с процедурой обновления версии Kubernetes и подразумевает пересоздание узлов кластера. Перед началом работ убедитесь, что кластер работает в отказоустойчивой конфигурации (3 и более master-узлов), и ознакомьтесь с процедурой обновления версии Kubernetes.

После применения политики и перекатки всех машин временную ноду можно будет удалить.

1.1. Переход в управление кластером

В веб-интерфейсе платформы выберите раздел Управление. Найдите целевой кластер, для которого требуется включить аудит, и нажмите Редактировать.

1.2. Настройка Control Plane Provider

В секции Control Plane Provider выберите тип Kubeadm и выполните следующие настройки.

1.2.1. Добавление файла политики аудита

В поле Files добавьте запись, указав путь к манифесту политик аудита и само содержимое манифеста.

Path:

bash

/etc/kubernetes/policies/audit.yaml

Value:

yaml

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - "RequestReceived"
rules:
  # Игнорируем стандартные системные запросы к endpoints в kube-system
  - level: None
    users:
      - system:kube-controller-manager
      - system:kube-scheduler
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: "" # core
        resources: ["endpoints"]
  # Игнорируем запросы на эндпоинты мониторинга и версионирования
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
      - /livez*
      - /readyz*
  # Логируем метаданные для секретов и конфиг-карт, а также tokenreviews
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Логируем запросы и ответы для операций, изменяющих состояние
  - level: RequestResponse
    verbs: ["create", "patch", "update", "delete", "deletecollection"]
  # Логируем запросы (без ответов) для чтения
  - level: Request
    verbs: ["get", "watch", "list"]
  # По умолчанию логируем запросы и ответы
  - level: RequestResponse

Пример заполнения: kubeadm kubeadm

Подробнее о настройке файла политики — в разделе Система аудита.

1.3. Настройка Kubernetes API Server

В блоке Kubernetes API Server configuration активируйте переключатель extraArgs, добавьте и задайте параметры:

Key (ключ)	Value (значение)
`audit-log-maxage`	`1`
`audit-log-maxbackup`	`2`
`audit-log-path`	`/var/log/kube-audit/audit.log`
`audit-policy-file`	`/etc/kubernetes/policies/audit.yaml`
`cloud-provider`	`external` (если необходимо)

Пример заполнения: api_server_conf

YAML:

yaml

extraArgs:
  audit-log-maxage: '1'
  audit-log-maxbackup: '2'
  audit-log-path: /var/log/kube-audit/audit.log
  audit-policy-file: /etc/kubernetes/policies/audit.yaml
  cloud-provider: external

Подробнее — в разделе Система аудита.

1.4. Настройка extraVolumes

Чтобы файл политики и каталог для логов были доступны в контейнере API-сервера, необходимо смонтировать соответствующие тома.

В блоке Kubernetes API Server configuration активируйте переключатель extraVolumes и добавьте 2 записи:

Для политики аудита:
Поле Значение
Host path /etc/kubernetes/policies/audit.yaml
Mount path /etc/kubernetes/policies/audit.yaml
Read only true
Для каталога логов:
Поле Значение
Host path /var/log/kube-audit
Mount path /var/log/kube-audit
Read only false

Поле	Значение
Host path	`/etc/kubernetes/policies/audit.yaml`
Mount path	`/etc/kubernetes/policies/audit.yaml`
Read only	`true`

Поле	Значение
Host path	`/var/log/kube-audit`
Mount path	`/var/log/kube-audit`
Read only	`false`

Пример заполнения: extravolumes

Примечание

При активном переключателе Read only нельзя будет редактировать политику аудита. Для внесения изменений необходимо отключить Read only.

1.5. Сохранение конфигурации

После заполнения всех полей нажмите Сохранить. Платформа применит изменения на всех узлах в составе кластера.

Шаг 2. Настройка коллектора в MaxPatrol 10

Перед отправкой логов необходимо создать задачу сбора данных в MaxPatrol 10:

Войдите в консоль MaxPatrol 10.
Перейдите в раздел Сбор данных → Задачи.
Нажмите Создать задачу.

Заполните параметры:

Поле	Значение
Название	Например, `K8s Audit Logs`
Тип	`SysLog`
Адрес	Укажите IP-адрес или DNS-имя, по которому будет доступен коллектор
Порт	Укажите TCP-порт для приёма логов (например, `514`)

Нажмите Сохранить и запустить.

Пример страницы создания задачи: maxpatrol_tasks maxpatrol_tasks_2

Запомните адрес и порт коллектора — они понадобятся при настройке Vector на следующем шаге.

Шаг 3. Настройка Vector для отправки логов в SIEM

Отправка аудит-логов в MaxPatrol 10 осуществляется через компонент Vector, входящий в состав модуля Victoria Logs.

В веб-интерфейсе платформы перейдите в раздел More Resources (Дополнительные Ресурсы) → Bootsman.Addons → Configs.
Найдите конфигурацию аддона victoria-logs для вашего кластера (именование: {CLUSTER_NAME}-victoria-logs).
Откройте её для редактирования.
В секции spec.values.vector добавьте или дополните customConfig:

yaml

spec:
  values:
    vector:
      customConfig:
        sources:
          k8s_audit:
            type: file
            include:
              - /var/log/kube-audit/audit*.log
            read_from: beginning
        transforms:
          prepare_syslog:
            type: remap
            inputs:
              - k8s_audit
            source: |
              audit = string!(.message)
              host = get_env_var!("VECTOR_SELF_NODE_NAME")
              ts = format_timestamp!(now(), format: "%b %e %T", timezone: "UTC")
              .message = "<190>" + ts + " " + host + " kube " + audit
        sinks:
          siem_syslog:
            type: socket
            mode: tcp
            encoding:
              codec: raw_message
              syslog:
                rfc: rfc3164
            inputs:
              - prepare_syslog
            address: "<IP_КОЛЛЕКТОРА>:<ПОРТ>"

Где:
- `<IP_КОЛЛЕКТОРА>` — адрес коллектора MaxPatrol 10, указанный на шаге 2.
- `<ПОРТ>` — TCP-порт коллектора MaxPatrol 10.

Совет

Если в customConfig уже есть другие источники, преобразования или приёмники (например, для штатной работы Victoria Logs), просто добавьте секции k8s_audit, prepare_syslog и siem_syslog к существующим, не удаляя их.

Нажмите Применить и дождитесь перезапуска Pod'ов Vector.

Шаг 4. Проверка работы

4.1. Проверка записи аудит-логов на узлах

На любом master-узле кластера выполните:

bash

tail -f /var/log/kube-audit/audit.log

Выполните тестовое действие (например, создайте Pod):

bash

kubectl run test-audit --image=nginx

Убедитесь, что в файле /var/log/kube-audit/audit.log появилась соответствующая запись audit-события.

4.2. Проверка отправки логов в MaxPatrol 10

В консоли MaxPatrol 10 перейдите в раздел Сбор данных → Задачи.
Выберите созданную задачу сбора логов.
В меню справа нажмите Перейти к собранным событиям.
Убедитесь, что события из кластера Kubernetes отображаются в ленте событий.

Пример просмотра собранных событий: maxpatrol_events maxpatrol_events_2

Примечание

Если события не появляются — проверьте сетевую связность от узлов кластера до коллектора MaxPatrol 10 (команда nc -zv <IP_КОЛЛЕКТОРА> <ПОРТ>). Также убедитесь, что в MaxPatrol 10 установлены актуальные Пакеты экспертизы для корректной обработки syslog-сообщений.

Частые ошибки

Симптом	Вероятная причина	Решение
Файл `/var/log/kube-audit/audit.log` не создаётся	Не настроены `extraArgs` или `extraVolumes` в конфигурации кластера	Проверьте настройки в разделе Система аудита
В логах Vector нет событий `k8s_audit`	Vector не имеет доступа к файлам аудит-логов	Убедитесь, что Vector работает в режиме `Agent` на master-узлах
В MaxPatrol 10 не появляются события	Неверный адрес или порт коллектора, блокировка фаерволом	Проверьте `address` в конфигурации Vector и сетевую доступность
События приходят в MaxPatrol 10, но непарсятся	Неподходящий формат syslog	Убедитесь, что в `encoding.syslog.rfc` указан `rfc3164` и Пакеты экспертизы установлены

Заключение

После выполнения всех шагов аудит-логи Kubernetes будут включены для всего кластера, а Vector будет отправлять их в SIEM MaxPatrol 10 для централизованного хранения и анализа. Конфигурация сохраняется при любых операциях обновления или перекатки узлов.

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

Yandex Cloud

VK Cloud

VSphere

Brest

VMmanager

Ролевая модель

Baremetal

Модули хранения данных

Модули мониторинга

Multus CNI

SR-IOV

Включение audit-логов в платформе «Боцман» и подключение их к SIEM MaxPatrol 10

Когда это пригодится

Предварительные требования

Шаг 1. Включение аудит-логов Kubernetes

1.1. Переход в управление кластером

1.2. Настройка Control Plane Provider

1.2.1. Добавление файла политики аудита

1.3. Настройка Kubernetes API Server

1.4. Настройка extraVolumes

1.5. Сохранение конфигурации

Шаг 2. Настройка коллектора в MaxPatrol 10

Шаг 3. Настройка Vector для отправки логов в SIEM

Шаг 4. Проверка работы

4.1. Проверка записи аудит-логов на узлах

4.2. Проверка отправки логов в MaxPatrol 10

Частые ошибки

Заключение

Включение audit-логов в платформе «Боцман» и подключение их к SIEM MaxPatrol 10 ​

Когда это пригодится ​

Предварительные требования ​

Шаг 1. Включение аудит-логов Kubernetes ​

1.1. Переход в управление кластером ​

1.2. Настройка Control Plane Provider ​

1.2.1. Добавление файла политики аудита ​

1.3. Настройка Kubernetes API Server ​

1.4. Настройка extraVolumes ​

1.5. Сохранение конфигурации ​

Шаг 2. Настройка коллектора в MaxPatrol 10 ​

Шаг 3. Настройка Vector для отправки логов в SIEM ​

Шаг 4. Проверка работы ​

4.1. Проверка записи аудит-логов на узлах ​

4.2. Проверка отправки логов в MaxPatrol 10 ​

Частые ошибки ​

Заключение ​

Включение audit-логов в платформе «Боцман» и подключение их к SIEM MaxPatrol 10

Когда это пригодится

Предварительные требования

Шаг 1. Включение аудит-логов Kubernetes

1.1. Переход в управление кластером

1.2. Настройка Control Plane Provider

1.2.1. Добавление файла политики аудита

1.3. Настройка Kubernetes API Server

1.4. Настройка extraVolumes

1.5. Сохранение конфигурации

Шаг 2. Настройка коллектора в MaxPatrol 10

Шаг 3. Настройка Vector для отправки логов в SIEM

Шаг 4. Проверка работы

4.1. Проверка записи аудит-логов на узлах

4.2. Проверка отправки логов в MaxPatrol 10

Частые ошибки

Заключение