Система аудита
Определение
Система аудита - это встроенный в платформу Боцман механизм для автоматической фиксации и анализа действий пользователей, системных событий и процессов, в виде аудит-сообщений.
Аудит-сообщения содержат всю необходимую информацию о событиях, подлежащих аудиту. Аудит-сообщения сохраняются в аудит-логах.
Аудит-логи позволяют отслеживать действия, выполняемые в кластере Kubernetes, и фиксировать обращения к API серверу. Включение аудита необходимо для обеспечения безопасности, соответствия требованиям информационной безопасности и упрощения расследования инцидентов.
Заметка
По-умолчанию система аудита отключена.
Система предоставляет возможность выбрать один из трёх вариантов хранения аудит-логов:
- Защищённые системные журналы;
- Loki;
- VictoriaLogs.
Что бы запустить систему аудита необходимо выбрать и настроить способ хранения аудит-логов.
Настройка выбора способа хранения аудит-логов
Для включения системы аудита необходимо перейти в раздел More Resources (Дополнительные Ресурсы) -> Bootsman.Addons -> Configs управляющего кластера платформы Боцман и внести изменения в конфигурации аддонов Dex и Rancher:
- Открыть конфигурацию аддона
Dex(configс именем "cluster-name-dex").
Добавить в конфигурацию переменные:audit.enable,audit.targetиaudit.endpoint, задав им значения из таблицы ниже. - Открыть конфигурацию аддона
Rancher(configс именем "cluster-name-rancher").
Добавить в конфигурацию переменную:audit.enable, задав ей значения из таблицы ниже.
| Переменная | Значение |
|---|---|
| audit.enable | "true" - аудит система включена "false" или отсутствует - аудит система выключена |
| audit.target | stdout - аудит-сообщения сохраняются в системные журналы loki - аудит-сообщения сохраняются в Loki, доступ к ним осуществляется через приложение Grafana victoria - аудит-сообщения сохраняются в VictoriaLogs, доступ к ним осуществляется через приложение VictoriaLogs |
| audit.endpoint | путь к приложению для доступа к логам (при audit.target= stdout значение audit.endpoint игнорируется) |
Дождитесь пока аддоны Rancher и Dex переинициализируются (отследить выполнение можно в меню Workload(Рабочие процессы) -> Deployments).
Примеры конфигурации
Конфигурация аддона Dex:
spec:
values:
audit:
enable: true
target: victoria
connection: 'http://victoria-logs-victoria-logs-single-server.victoria-logs:9428'
Конфигурация аддона Rancher:
Внимание
Для использования Loki или Victoria в качестве хранилища логов аудита, необходимо что бы эти модули были запущены в управляющем кластере.
Заметка
При хранении аудит-сообщений в защищённых системных журналах доступ к аудит-логам определяет и настраивает администратор системы.
Хранение аудит-логов в защищенных системных журналах
В данной инструкции описан порядок включения системы аудита в кластере с использованием защищенных системных журналов, в качестве хранилища.
Все изменения вносятся в конфигурацию целевого кластера и автоматически применяются на всех его узлах, сохраняясь при re-roll развертываниях.
Предварительные требования
- Доступ к платформе «Боцман» с правами на редактирование кластера;
- Способом хранения аудит-логов выбраны защищенные системные журналы;
- Понимание структуры политик аудита Kubernetes;
- Наличие системного журналирования (rsyslog или syslog-ng) на узлах кластера для сбора логов.
Конфигурация кластера
- В интерфейсе платформы «Боцман» выберите раздел Manage (Управление)
- Найдите целевой кластер, для которого требуется включить аудит, и нажмите Edit(Редактировать)
Настройка Control Plane Provider
- В секции Control Plane Provider: Kubeadm активируйте переключатель добавления Files(Файлы)
- В открывшемся окне параметров укажите Path(Путь) и Value(Значение):
Path(Путь):
Value:
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

Настройка 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 (если необходимо) |
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
Настройка extraVolumes
Чтобы файл политики и каталог для логов были доступны в контейнере API сервера, необходимо смонтировать соответствующие тома в кластере.
В блоке Kubernetes API Server configuration активируйте переключатель extraVolumes и добавьте 2 записи:
1. Для политики аудита
- Host path: /etc/kubernetes/policies
- Mount path: /etc/kubernetes/policies
- Read only: true
- Для каталога логов
- Host path:
/var/log/kube-audit - Mount path:
/var/log/kube-audit - Read only:
false
Заметка
При активном переключателе Read only нельзя будет редактировать политику аудита. Для внесения изменений необходимо отключить Read only.
Сохранение конфигурации
После заполнения всех полей нажмите Apply(Сохранить). Платформа применит изменения на всех узлах в составе кластера.
Настройка сбора логов (rsyslog / syslog-ng)
Для централизованного сбора и ротации аудит-логов необходимо настроить системное журналирование на каждом узле. В примере будет использоваться rsyslog.
Создание конфигурационного файла rsyslog
- Создайте и отредактируйте конфигурационный файл:
- Задайте параметры:
- Укажите IP-адрес сервиса сборки логов
Перезапуск rsyslog
Перезапустите rsyslog для применения параметров, используя команду:
Проверка работы аудита
Что бы убедиться в коррректной работе системы аудита выполните следующие действия:
1. Убедитесь, что файл /var/log/kube-audit/audit.log создан на узлах и в него пишутся записи, выполнив команду:
3. Проверьте, что
rsyslog перенаправляет логи в целевой файл или на удалённый сервер
Заключение
После выполнения описанных шагов аудит-логи будут включены для всего кластера, а конфигурация сохранится при любых операциях обновления или перекатки узлов. Настройка системного журналирования обеспечивает долговременное хранение и централизованный сбор логов.
При необходимости изменения политик аудита достаточно отредактировать содержимое файла /etc/kubernetes/policies/audit.yaml в секции Control Plane Provider: Kubeadm -> Files(Файл) конфигурации кластера — изменения применятся автоматически.



