Cloud/Container/VM
- Настройка аудита VMware ESXi и vCenter
- Kubernetes (k8s) via Rsyslog
- Kubernetes (k8s) via webhook
- Docker via syslog
Настройка аудита VMware ESXi и vCenter
VMware ESXi
Через веб-интерфейс
Проверьте корректность настроек времени и часового пояса, проверить синхронизацию с NTP-сервером (принять во внимание, что ОС VMware ESXi работает только по UTC).
Выполнить резервное копирование конфигурации ESXi-хоста.
Через web-интерфейс подключиться к ESXi-хосту используя учетную запись root.
В главном меню в разделе навигации развернуть вкладку Host и перейти по пути: Host – Manage – Advanced Settings.
В окне поиска набрать Syslog.global.LogHost, выбрать параметр Syslog.global.LogHost и отредактировать его.
Укажите протокол, адрес и порт коллектора KUMA и нажмите Save.
Далее перейдите на вкладку Networking – Firewall rules.
Найдите правило syslog, выделите его (можно воспользоваться поиском) и включите его, нажав на Actions – Enable.
Через SSH
Настройку аудита можно выполнить через SSH. Включить доступ по SSH на ESXi-хосте, перейти по пунктам: Host – Actions – Services – Enable Secure Shell (SSH).
Подключитесь к ESXi-хосту по SSH используя учетную запись root (например через Putty).
- Наберите команду:
esxcli system syslog config set --loghost=udp://192.168.1.250:514
(конфигурирование подключения к syslog-серверу, ip-адрес в команде не является легитимным и указан исключительно для примера). - Наберите команду:
esxcli network firewall ruleset set --ruleset-id=syslog --enabled=true
(включение разрешающего правила фильтрации для syslog). - Наберите команду:
esxcli network firewall refresh
(обновление настроек межсетевого экрана ESXi-хоста). - Наберите команду:
esxcli system syslog config get
(проверка настроек syslog-службы ESXi-хоста):
- Набрать команду:
esxcli system syslog reload
(перезагрузка syslog-службы ESXi-хоста). - Авторизоваться на ESXi-хосте, через его web-интерфейс под учетной записью с административными правами и отключить доступ по SSH (примечание: Согласно рекомендациям VMware, доступы по SSH и к ESXi-shell нужны только во время диагностических и аварийных работ).
(Опционально) Если необходимо отправлять события Syslog на другой порт назначения, необходимо добавить правило для МЭ ESXi, для этого зайдите на хост по SSH.
Создайте файл (используются классические Linux команды) со следующим содержимым, например для порта 5140 (назовем файл syslogPort-5140.xml):
<!-- /etc/vmware/firewall/syslogPort-5140.xml -->
<!-- remote syslog configuration -->
<ConfigRoot>
<service>
<id>syslogPort-5140</id>
<rule id='0000'>
<direction>outbound</direction>
<protocol>udp</protocol>
<porttype>dst</porttype>
<port>5140</port>
</rule>
<rule id='0001'>
<direction>outbound</direction>
<protocol>tcp</protocol>
<porttype>dst</porttype>
<port>5140</port>
</rule>
<enabled>false</enabled>
<required>false</required>
</service>
</ConfigRoot>
Для использования этого правила выполните команды ниже, и активируйте его:
cp syslogPort-5140.xml /etc/vmware/firewall/
esxcli network firewall unload
esxcli network firewall load
VMware vCenter
Сделайте snapshot или выполните резервное копирование vCenter.
Через web-браузер подключитесь к vCenter Server Appliance Management Inteface (VAMI) используя административную учетную запись (например, administrator@vsphere.local).
Наберите в web-браузере: https://vcenter.test.local:5480 и ввести административные учетные данные (имя vcenter.test.local не является легитимным и указан для примера).
Убедитесь в корректности настроек времени в разделе Time (часовой пояс указан в качестве примера, а тип синхронизации в «Филиале» будет индивидуально зависеть от указанных местных настроек).
Перейти в раздел Syslog, чтобы настроить Forwarding. Нажать кнопку CONFIGURE, укажите протокол, адрес и порт коллектора KUMA и нажмите Save.
Отправьте тестовое сообщение:
Kubernetes (k8s) via Rsyslog
Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.
Общее
Настройка логирования Kubernetes (k8s) выполняется путем модификации kube-apiserver. Подробное описание механизма аудита k8s приведено на официальном сайте. Данная инструкция предназначена для настройки аудита k8s для последующей передачи логов в KUMA.
Настройка k8s
1. Необходимо подключиться к ноде k8s с ролью control plane
2. На ноде создаем директорию, куда будет помещена политика аудита
sudo mkdir /etc/kubernetes/audit/
3. В созданной директории создаем файл с политикой аудита /etc/kubernetes/audit/audit-policy.yaml
любым удобным способом. Содержимое файла может варьироваться от целей логирования, ниже приведен пример политики с официального сайта.
Будьте внимательны, конфигурации в k8s как правило задаются в виде файлов YAML, которые чувствительны к отступам. Валидируйте файлы перед их применением во избежание ошибок.
Пример политики аудита k8s
apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Don't generate audit events for all requests in RequestReceived stage.
omitStages:
- "RequestReceived"
rules:
# Log pod changes at RequestResponse level
- level: RequestResponse
resources:
- group: ""
# Resource "pods" doesn't match requests to any subresource of pods,
# which is consistent with the RBAC policy.
resources: ["pods"]
# Log "pods/log", "pods/status" at Metadata level
- level: Metadata
resources:
- group: ""
resources: ["pods/log", "pods/status"]
# Don't log requests to a configmap called "controller-leader"
- level: None
resources:
- group: ""
resources: ["configmaps"]
resourceNames: ["controller-leader"]
# Don't log watch requests by the "system:kube-proxy" on endpoints or services
- level: None
users: ["system:kube-proxy"]
verbs: ["watch"]
resources:
- group: "" # core API group
resources: ["endpoints", "services"]
# Don't log authenticated requests to certain non-resource URL paths.
- level: None
userGroups: ["system:authenticated"]
nonResourceURLs:
- "/api*" # Wildcard matching.
- "/version"
# Log the request body of configmap changes in kube-system.
- level: Request
resources:
- group: "" # core API group
resources: ["configmaps"]
# This rule only applies to resources in the "kube-system" namespace.
# The empty string "" can be used to select non-namespaced resources.
namespaces: ["kube-system"]
# Log configmap and secret changes in all other namespaces at the Metadata level.
- level: Metadata
resources:
- group: "" # core API group
resources: ["secrets", "configmaps"]
# Log all other resources in core and extensions at the Request level.
- level: Request
resources:
- group: "" # core API group
- group: "extensions" # Version of group should NOT be included.
# A catch-all rule to log all other requests at the Metadata level.
- level: Metadata
# Long-running requests like watches that fall under this rule will not
# generate an audit event in RequestReceived.
omitStages:
- "RequestReceived"
4. Далее создаем директорию, в которую будут записаны логи аудита k8s
sudo mkdir -p /var/log/kubernetes/audit/
5. Далее необходимо будет внести изменения в конфигурацию пода kube-apiserver. Перед этим настоятельно рекомендуется сделать резервную копию конфигурации, например, следующей командой из вашей рабочей директории:
sudo cp /etc/kubernetes/manifests/kube-apiserver.yaml .
6. Вносим изменение в kube-apiserver с помощью команды:
sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
7. В секции spec.containers.command
указываем следующие флаги, соблюдая отступы:
- --audit-policy-file=/etc/kubernetes/audit/audit-policy.yaml
- --audit-log-path=/var/log/kubernetes/audit/audit.log
Где /etc/kubernetes/audit/audit-policy.yaml
- путь к политике аудита, а /var/log/kubernetes/audit/audit.log
- путь к файлу для записи логов.
8. Дополнительно можно определить другие параметры логирования, такие как размер файла логов и количество файлов (подробное описание параметров можно найти тут):
- --audit-log-maxsize=500
- --audit-log-maxbackup=3
Настройка секции spec.containers.command
9. Далее в том же файле создаем соответствующие тома и точки монтирования для политики и директории для хранения логов
10. В секцию volumes
добавляем следующее соблюдая отступы:
- hostPath:
path: /etc/kubernetes/audit/audit-policy.yaml
type: File
name: audit
- hostPath:
path: /var/log/kubernetes/audit/
type: DirectoryOrCreate
name: audit-log
Здесь /etc/kubernetes/audit/audit-policy.yaml
- путь к политике аудита, а /var/log/kubernetes/audit/audit.log
- путь к файлу для записи логов.
Настройка секции volumes
11. В секцию volumeMounts
добавляем следующее соблюдая отступы:
- mountPath: /etc/kubernetes/audit/audit-policy.yaml
name: audit
readOnly: true
- mountPath: /var/log/kubernetes/audit/
name: audit-log
readOnly: false
Настройка секции volumeMounts
12. Сохраняем все внесенные в файл измнения.
Т.к. была изменена конфигурация kube-apiserver, то под будет пересоздан, что может потребовать примерно до 1 минуты времени. Если под не смог подняться, необходимо проверить все внесенные изменения на предмет ошибок и опечаток, а также изучить логи по пути /var/log/pods/
Если все было сделано правильно, то под kube-apiserver поднимется и в директории /var/log/kubernetes/audit/ появится файл audit.log и начнет наполняться логами k8s.
Настройка Rsyslog
Настройки ниже приведены для deb-систем.
1. Установка rsyslog
apt install rsyslog
2. Включение и запуск службы rsyslog
systemctl enable rsyslog.service
systemctl start rsyslog.service
3. Создание файла конфигурации для отправки через rsyslog файла лога k8s
nano /etc/rsyslog.d/k8s.conf
Пример содержимого файла с отправкой по TCP:
$ModLoad imfile
$InputFileName /var/log/kubernetes/audit/audit.log
$InputFileTag tag_k8s_log:
$InputFileStateFile k8s_log
$InputFileSeverity info
$InputFileFacility local6
$InputRunFileMonitor
local6.* @@10.10.10.10:7777
Где 10.10.10.10 - адрес коллектора KUMA, 7777 - порт коллектора KUMA
Для отправки событий по протоколу UDP последнюю строчку следует заменить на:
local6.* @10.10.10.10:7777
4. После сохранения изменений в файле необходимо перезапустить сервис Rsyslog командой:
systemctl restart rsyslog.service
Настройка коллектора KUMA
После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий k8s
.
1. На шаге Транспорт укажите тип и порт в соответствии с настройками на стороне Kubernetes.
2. На шаге Парсинг событий выберите нормализатор k8s via syslog.
3. На шаге Маршрутизация проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения:
- Хранилище. Для отправки обработанных событий в хранилище.
- Коррелятор. Для отправки обработанных событий в коррелятор.
Если точки назначения Хранилище и Коррелятор не добавлены, создайте их.
4. На шаге Проверка параметров нажмите Сохранить и создать сервис.
5. Скопируйте появившуюся команду для установки коллектора KUMA.
Полезные ссылки
Пакет контента для k8s: https://github.com/KUMA-Community/kuma_content/tree/main/rules/app/kubernetes
Документация по настройке аудита k8s: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
Kubernetes (k8s) via webhook
Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.
Данный способ является экспериментальным. Рекомендуемый способ приведен в статье k8s via rsyslog
Общее
Настройка логирования Kubernetes (k8s) выполняется путем модификации kube-apiserver. Подробное описание механизма аудита k8s приведено на официальном сайте. Данная инструкция предназначена для настройки аудита k8s для последующей передачи логов в KUMA.
Настройка k8s
1. Необходимо подключиться к ноде k8s с ролью control plane
2. На ноде создаем директорию, куда будет помещена политика аудита
sudo mkdir /etc/kubernetes/audit/
3. В созданной директории создаем файл с политикой аудита /etc/kubernetes/audit/audit-policy.yaml
любым удобным способом. Содержимое файла может варьироваться от целей логирования, ниже приведен пример политики с официального сайта.
Будьте внимательны, конфигурации в k8s как правило задаются в виде файлов YAML, которые чувствительны к отступам. Валидируйте файлы перед их применением во избежание ошибок.
Пример политики аудита k8s
apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Don't generate audit events for all requests in RequestReceived stage.
omitStages:
- "RequestReceived"
rules:
# Log pod changes at RequestResponse level
- level: RequestResponse
resources:
- group: ""
# Resource "pods" doesn't match requests to any subresource of pods,
# which is consistent with the RBAC policy.
resources: ["pods"]
# Log "pods/log", "pods/status" at Metadata level
- level: Metadata
resources:
- group: ""
resources: ["pods/log", "pods/status"]
# Don't log requests to a configmap called "controller-leader"
- level: None
resources:
- group: ""
resources: ["configmaps"]
resourceNames: ["controller-leader"]
# Don't log watch requests by the "system:kube-proxy" on endpoints or services
- level: None
users: ["system:kube-proxy"]
verbs: ["watch"]
resources:
- group: "" # core API group
resources: ["endpoints", "services"]
# Don't log authenticated requests to certain non-resource URL paths.
- level: None
userGroups: ["system:authenticated"]
nonResourceURLs:
- "/api*" # Wildcard matching.
- "/version"
# Log the request body of configmap changes in kube-system.
- level: Request
resources:
- group: "" # core API group
resources: ["configmaps"]
# This rule only applies to resources in the "kube-system" namespace.
# The empty string "" can be used to select non-namespaced resources.
namespaces: ["kube-system"]
# Log configmap and secret changes in all other namespaces at the Metadata level.
- level: Metadata
resources:
- group: "" # core API group
resources: ["secrets", "configmaps"]
# Log all other resources in core and extensions at the Request level.
- level: Request
resources:
- group: "" # core API group
- group: "extensions" # Version of group should NOT be included.
# A catch-all rule to log all other requests at the Metadata level.
- level: Metadata
# Long-running requests like watches that fall under this rule will not
# generate an audit event in RequestReceived.
omitStages:
- "RequestReceived"
4. В этой же директории создаем файл /etc/kubernetes/audit/audit-webhook.yaml
любым удобным способом. Пример содержимого файла приведен ниже:
apiVersion: v1
kind: Config
preferences: {}
clusters:
- name: kube-auditing
cluster:
server: http://10.10.10.10:7777/input
users: []
contexts:
- name: default-context
context:
cluster: kube-auditing
user: ""
current-context: default-context
Где 10.10.10.10 - адрес коллектора KUMA, а 7777 - порт коллектора. Все прочие параметры из примера можно оставлять без изменений.5. Далее создаем директорию, в которую будут записаны логи аудита k8s
5. Далее необходимо будет внести изменения в конфигурацию пода kube-apiserver. Перед этим настоятельно рекомендуется сделать резервную копию конфигурации, например, следующей командой из вашей рабочей директории:
sudo cp /etc/kubernetes/manifests/kube-apiserver.yaml .
6. Вносим изменение в kube-apiserver с помощью команды:
sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
7. В секции spec.containers.command
указываем следующие флаги, соблюдая отступы:
- --audit-webhook-config-file=/etc/kubernetes/audit/audit-webhook.yaml
- --audit-webhook-mode=batch
- --audit-webhook-batch-max-size=1
Где /etc/kubernetes/audit/audit-policy.yaml
- путь к политике аудита.
Настройка секции spec.containers.command
9. Далее в том же файле создаем соответствующий том и точку монтирования для политик
10. В секцию volumes
добавляем следующее соблюдая отступы:
- hostPath:
path: /etc/kubernetes/audit/
type: DirectoryOrCreate
name: k8s-audit
Здесь /etc/kubernetes/audit/
- путь к директории с политикой аудита и настройками webhook
Настройка секции volumes
11. В секцию volumeMounts
добавляем следующее соблюдая отступы:
- mountPath: /etc/kubernetes/audit/
name: k8s-audit
readOnly: true
Настройка секции volumeMounts
12. Сохраняем все внесенные в файл измнения.
Т.к. была изменена конфигурация kube-apiserver, то под будет пересоздан, что может потребовать примерно до 1 минуты времени. Если под не смог подняться, необходимо проверить все внесенные изменения на предмет ошибок и опечаток, а также изучить логи по пути /var/log/pods/
Настройка коллектора KUMA
После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий k8s
.
1. На шаге Транспорт укажите тип и порт в соответствии с настройками на стороне Kubernetes (audit-webhook.yaml)
.
2. На шаге Парсинг событий выберите нормализатор k8s via webhook.
3. На шаге Маршрутизация проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения:
- Хранилище. Для отправки обработанных событий в хранилище.
- Коррелятор. Для отправки обработанных событий в коррелятор.
Если точки назначения Хранилище и Коррелятор не добавлены, создайте их.
4. На шаге Проверка параметров нажмите Сохранить и создать сервис.
5. Скопируйте появившуюся команду для установки коллектора KUMA.
Полезные ссылки
Пакет контента для k8s: https://github.com/KUMA-Community/kuma_content/tree/main/rules/app/kubernetes
Документация по настройке аудита k8s: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
Docker via syslog
Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.
Общее
Настройка логирования Docker выполняется путем модификации /etc/docker/daemon.json
, либо точечно для каждого контейнера через указание соответствующих параметров при запуске. В данной статье будет рассмотрен первый вариант.
Настройка Docker
1. Необходимо подключиться к ноде Docker
2. На ноде создать файл конфигурации /etc/docker/daemon.json
, либо внести изменения в существующий. Пример файла конфигурации представлен ниже.
{
"log-driver": "syslog",
"log-opts": {
"syslog-address": "tcp://10.10.10.10:6688",
"tag": "{{.ID}}/{{.Name}}",
"syslog-format": "rfc5424"
}
}
Где, 10.10.10.10
- адрес коллектора KUMA, 66888
- порт коллектора KUMA. При необходимости можно также переопределить протокол передачи, формат логов и тегирование. Подробности см. по ссылке в конце статьи.
3. После внесения изменения в файл необходимо перезапустить службу Docker'а:
systemctl restart docker.service
В результате внесенных изменений события от Docker будут перенаправляться на сервис коллектора KUMA в соответствии с указанными параметрами.
Альтернативно можно настроить логирование на стороне Docker в файл и перенаправлять его содержимое через rsyslog или путем монтирования папки/установки агента KUMA.
Настройка коллектора KUMA
После того как параметры передачи событий настроены, требуется создать коллектор в веб-интерфейсе KUMA для событий Docker
.
1. На шаге Транспорт укажите тип и порт в соответствии с настройками на стороне Docker.
2. На шаге Парсинг событий выберите нормализатор [OOTB] Syslog.
В дальнейшем можно использовать кастомные парсеры в зависимости от приложений, работающих в контейнерах Docker.
3. На шаге Маршрутизация проверьте, что в набор ресурсов коллектора добавлены следующие точки назначения:
- Хранилище. Для отправки обработанных событий в хранилище.
- Коррелятор. Для отправки обработанных событий в коррелятор.
Если точки назначения Хранилище и Коррелятор не добавлены, создайте их.
4. На шаге Проверка параметров нажмите Сохранить и создать сервис.
5. Скопируйте появившуюся команду для установки коллектора KUMA.
Полезные ссылки
Документация по настройке syslog в Docker: https://docs.docker.com/engine/logging/drivers/syslog/