# Kubernetes (k8s) via webhook

<p class="callout info">Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и **НЕ** является официальной рекомендацией вендора.</p>

<p class="callout warning">Данный способ является экспериментальным. Рекомендуемый способ приведен в статье **[k8s via rsyslog](https://kb.kuma-community.ru/books/podkliucenie-istocnikov/page/kubernetes-k8s-via-rsyslog)**</p>

### Общее

Настройка логирования Kubernetes (k8s) выполняется путем модификации kube-apiserver. Подробное описание механизма аудита k8s приведено на официальном **[сайте](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/)**. Данная инструкция предназначена для настройки аудита k8s для последующей передачи логов в KUMA.

---

### Настройка k8s

1\. Необходимо подключиться к ноде k8s с ролью control plane

2\. На ноде создаем директорию, куда будет помещена политика аудита

```bash
sudo mkdir /etc/kubernetes/audit/
```

3\. В созданной директории создаем файл с политикой аудита `/etc/kubernetes/audit/audit-policy.yaml` любым удобным способом. Содержимое файла может варьироваться от целей логирования, ниже приведен пример политики с официального сайта.

<p class="callout info">Будьте внимательны, конфигурации в k8s как правило задаются в виде файлов YAML, которые чувствительны к отступам. Валидируйте файлы перед их применением во избежание ошибок.</p>

<details id="bkmrk-%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80-%D0%BF%D0%BE%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B8-%D0%B0%D1%83%D0%B4%D0%B8"><summary>Пример политики аудита k8s</summary>

```yaml
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"

```

</details>4\. В этой же директории создаем файл `/etc/kubernetes/audit/audit-webhook.yaml` любым удобным способом. Пример содержимого файла приведен ниже:

```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. Перед этим настоятельно рекомендуется сделать резервную копию конфигурации, например, следующей командой из вашей рабочей директории:

```bash
sudo cp /etc/kubernetes/manifests/kube-apiserver.yaml .
```

6\. Вносим изменение в kube-apiserver с помощью команды:

```
sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
```

7\. В секции `spec.containers.command` указываем следующие флаги, соблюдая отступы:

```yaml
- --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` - путь к политике аудита.

<details id="bkmrk-%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80-%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B8"><summary>Настройка секции spec.containers.command</summary>

![image.png](https://kb.kuma-community.ru/uploads/images/gallery/2024-10/scaled-1680-/S5Timage.png)

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

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

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

```

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

<details id="bkmrk-%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0-%D1%81%D0%B5%D0%BA%D1%86%D0%B8%D0%B8-vol"><summary>Настройка секции volumes</summary>

![image.png](https://kb.kuma-community.ru/uploads/images/gallery/2024-10/scaled-1680-/dQsimage.png)

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

```yaml
 - mountPath: /etc/kubernetes/audit/
      name: k8s-audit
      readOnly: true

```

<details id="bkmrk-%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0-%D1%81%D0%B5%D0%BA%D1%86%D0%B8%D0%B8-vol-1"><summary>Настройка секции volumeMounts</summary>

![image.png](https://kb.kuma-community.ru/uploads/images/gallery/2024-10/scaled-1680-/QS2image.png)

</details>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](https://github.com/KUMA-Community/kuma_content/tree/main/rules/app/kubernetes)

Документация по настройке аудита k8s: [https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/)