Skip to main content

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

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-webhook-config-file=/etc/kubernetes/audit/audit-policy.webhook.yaml
- --audit-log-path=/var/log/kubernetes/audit/audit.logwebhook-mode=batch
- --audit-webhook-batch-max-size=1

Где /etc/kubernetes/audit/audit-policy.yaml - путь к политике аудита, а /var/log/kubernetes/audit/audit.log - путь к файлу для записи логов.

8. Дополнительно можно определить другие параметры логирования, такие как размер файла логов и количество файлов (подробное описание параметров можно найти тут):

- --audit-log-maxsize=500
- --audit-log-maxbackup=3
Настройка секции spec.containers.command

image.pngimage.png

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-logk8s-audit

Здесь /etc/kubernetes/audit/audit-policy.yaml - путь к директории с политикеой аудита, а /var/log/kubernetes/audit/audit.log - путь к файлу для записи лнастрогов.йками webhook

Настройка секции volumes

image.pngimage.png

11. В секцию volumeMounts добавляем следующее соблюдая отступы:

 - mountPath: /etc/kubernetes/audit/audit-policy.yaml
      name: k8s-audit
      readOnly: true
- mountPath: /var/log/kubernetes/audit/
  name: audit-log
  readOnly: false
Настройка секции volumeMounts

image.pngimage.png

12. Сохраняем все внесенные в файл измнения.

Т.к. была изменена конфигурация kube-apiserver, то под будет пересоздан, что может потребовать примерно до 1 минуты времени. Если под не смог подняться, необходимо проверить все внесенные изменения на предмет ошибок и опечаток, а также изучить логи по пути /var/log/pods/

Если все было сделано правильно, то под kube-apiserver поднимется и в директории /var/log/kubernetes/audit/ появится файл audit.log и начнет наполняться логами k8s.

Настройка RsyslogKUMA

Настройки ниже приведены дДля 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. После сохранения изменений в файле необходимо в веб-консоли KUMA перезйти на вкладку Ресурсы – Коллекторы и нажать на кнопкуст Добавить коллектор. Также можно на вкладке Ресурсы выбрать пункт Подключить источник. В обоих случая откроется мастерв подключения источников Rsyslogсобытий.

Для сбора логов данных способом необходимо выбрать тип Транспорта http а в качестве URL указать адрес и порт, комторые были задандоы ранее в фай:
ле audit-webhook.yaml.

systemctl restart rsyslog.service
Back to top