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

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

image.png

9. Далее в том же файле создаем соответствующий том и точку монтирования для политик

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

- hostPath:
      path: /etc/kubernetes/audit/
      type: DirectoryOrCreate
    name: k8s-audit

Здесь /etc/kubernetes/audit/ - путь к директории с политикой аудита и настройками webhook

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

image.png

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

 - mountPath: /etc/kubernetes/audit/
      name: k8s-audit
      readOnly: true
Настройка секции volumeMounts

image.png

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

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

Настройка KUMA

Для создания коллектора KUMA необходимо в веб-консоли KUMA перейти на вкладку Ресурсы – Коллекторы и нажать на кнопку Добавить коллектор. Также можно на вкладке Ресурсы выбрать пункт Подключить источник. В обоих случая откроется мастер подключения источников событий.

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

Back to top