Система аудита

Определение

Система аудита - это встроенный в платформу Боцман механизм для автоматической фиксации и анализа действий пользователей, системных событий и процессов, в виде аудит-сообщений.

Аудит-сообщения содержат всю необходимую информацию о событиях, подлежащих аудиту. Аудит-сообщения сохраняются в аудит-логах.

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

Заметка

По-умолчанию система аудита отключена.

Система предоставляет возможность выбрать один из трёх вариантов хранения аудит-логов:

1. Защищённые системные журналы;
2. Loki;
3. VictoriaLogs.

Что бы запустить систему аудита необходимо выбрать и настроить способ хранения аудит-логов.

Настройка выбора способа хранения аудит-логов

Для включения системы аудита необходимо перейти в раздел More Resources (Дополнительные Ресурсы) -> Bootsman.Addons -> Configs управляющего кластера платформы Боцман и внести изменения в конфигурации аддонов Rancher и Dex:

1. Открыть конфигурацию аддона Rancher (config с именем "cluster-name-rancher").
   Добавить в конфигурацию переменные: F_AUDIT, AUDIT_DB_TARGET, AUDIT_DB_CONN, задав им значения из таблицы ниже.
2. Открыть конфигурацию аддона Dex (config с именем "cluster-name-dex").
   Добавить в конфигурацию переменные: audit.target и audit.connection, задав им те же значения, что и в переменных AUDIT_DB_TARGET, AUDIT_DB_CONN из предыдущего пункта.

Переменная	Значение
F_AUDIT	"On" - аудит система включена "Off" или отсутствует - аудит система выключена
AUDIT_DB_TARGET	log - аудит-сообщения сохраняются в системные журналы loki - аудит-сообщения сохраняются в Loki, доступ к ним осуществляется через приложение Grafana victoria - аудит-сообщения сохраняются в VictoriaLogs, доступ к ним осуществляется через приложение VictoriaLogs
AUDIT_DB_CONN	путь к приложению для доступа к логам (при AUDIT_DB_TARGET= log значение AUDIT_DB_CONN игнорируется)

Дождитесь пока аддоны Rancher и Dex переинициализируются (отследить выполнение можно в меню Workload(Рабочие процессы) -> Deployments).

Примеры конфигурации

Конфигурация аддона Rancher:

spec:
  values:
    auditLog:
      image:
        repository: harbor.bootsman.host/bootsman-nimbus/common-artifacts/mirrored-bci-micro
    bootstrapPassword: password
    clustername: example-name-cluster
    extraEnv:
      - name: F_AUDIT
        value: 'On'
      - name: AUDIT_DB_TARGET
        value: victoria
      - name: AUDIT_DB_CONN
        value: http://victoria-logs-victoria-logs-single-server.victoria-logs:9428

Конфигурация аддона Dex:

spec:
  values:
    config:
      audit:
        target: victoria
        connection: 'http://victoria-logs-victoria-logs-single-server.victoria-logs:9428'

Внимание

Для использования Loki или Victoria в качестве хранилища логов аудита, необходимо что бы эти модули были запущены в управляющем кластере.

Заметка

При хранении аудит-сообщений в защищённых системных журналах доступ к аудит-логам определяет и настраивает администратор системы.

Хранение аудит-логов в защищенных системных журналах

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

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

• Доступ к платформе «Боцман» с правами на редактирование кластера;
• Способом хранения аудит-логов выбраны защищенные системные журналы;
• Понимание структуры политик аудита Kubernetes;
• Наличие системного журналирования (rsyslog или syslog-ng) на узлах кластера для сбора логов.

Конфигурация кластера

1. В интерфейсе платформы «Боцман» выберите раздел Manage (Управление)
2. Найдите целевой кластер, для которого требуется включить аудит, и нажмите Edit(Редактировать)

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

1. В секции Control Plane Provider: Kubeadm активируйте переключатель добавления Files(Файлы)
2. В открывшемся окне параметров укажите Path(Путь) и Value(Значение):

Path(Путь):

/etc/kubernetes/policies/audit.yaml

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

2. Для каталога логов

• 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

1. Создайте и отредактируйте конфигурационный файл:

vi /etc/rsyslog.d/50-audit.conf

2. Задайте параметры:

# Следим за файлом /var/log/kube-audit/audit.log
input(type="imfile"
      File="/var/log/kube-audit/audit.log"
      Tag="k8s-audit"
      Facility="local6"
      Severity="info")
# Для сохранения логов локально:
# local6.*    /var/log/kubernetes-audit.log
# Для отправки логов по сети:
# local6.*    @192.168.1.100:514 (1)

1. Укажите IP-адрес сервиса сборки логов

Перезапуск rsyslog

Перезапустите rsyslog для применения параметров, используя команду:

systemctl restart rsyslog

Проверка работы аудита

Что бы убедиться в коррректной работе системы аудита выполните следующие действия:

1. Убедитесь, что файл /var/log/kube-audit/audit.log создан на узлах и в него пишутся записи, выполнив команду:

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

2. Выполните тестовое действие (например, создайте pod) и проверьте появление соответствующей записи в логе
3. Проверьте, что rsyslog перенаправляет логи в целевой файл или на удалённый сервер

Заключение

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

При необходимости изменения политик аудита достаточно отредактировать содержимое файла /etc/kubernetes/policies/audit.yaml в секции Control Plane Provider: Kubeadm -> Files(Файл) конфигурации кластера — изменения применятся автоматически.