Аудит

Аудит Kubernetes забезпечує безпеку шляхом створення хронологічного набору записів, які документують послідовність дій у кластері. Кластер аудитує дії, що генеруються користувачами, застосунками, які використовують API Kubernetes, а також самою панеллю управління.

Аудит дозволяє адміністраторам кластера відповісти на такі питання:

• що сталося?
• коли це сталося?
• хто це ініціював?
• на чому це сталося?
• де це було помічено?
• звідки це було ініційовано?
• куди це направлялося?

Записи аудиту починають свій життєвий цикл всередині компонента kube-apiserver. Кожен запит на кожному етапі його виконання генерує подію аудиту, яка потім передається до попередньої обробки відповідно до певної політики та записується в бекенд. Політика визначає, що буде записано, а бекенд зберігає записи. Поточні реалізації бекендів включають файли логів та вебхуки.

Кожний запит може бути записаний з асоційованим stage. Визначені етапи:

• RequestReceived — Етап для подій, що генеруються, як тільки обробник аудиту отримує запит, і до того, як він передає його вниз по ланцюжку обробників.
• ResponseStarted — Після надсилання заголовків відповіді, але перед відправленням тіла відповіді. Цей етап генерується лише для тривалих запитів (наприклад, watch).
• ResponseComplete — Тіло відповіді завершено і більше байтів не буде відправлено.
• Panic — Події, що генеруються при виникненні паніки.

Функція логування аудиту збільшує витрати памʼяті сервера API, оскільки для кожного запиту зберігається певний контекст, необхідний для аудитування. Витрати памʼяті залежать від конфігурації логування аудиту.

Політика аудиту

Політика аудиту визначає правила того, які події повинні бути записані та які дані вони повинні містити. Структура обʼєкта політики аудиту визначена в групі API audit.k8s.io. Коли подія обробляється, її порівнюють зі списком прав по черзі. Перший збіг прав встановлює рівень аудиту події. Визначені рівні аудиту:

• None — не записувати події, які відповідають цьому правилу.
• Metadata — записувати метадані запиту (користувач, часова відмітка, ресурс, дія тощо), але не тіло запиту чи відповіді.
• Request — записувати метадані події та тіло запиту, але не тіло відповіді. Це не застосовується до запитів на ресурси.
• RequestResponse — записувати метадані події, тіло запиту та відповіді. Це не застосовується до запитів на ресурси.

Ви можете передати файл з політикою до kube-apiserver, використовуючи прапорець --audit-policy-file. Якщо прапорець пропущено, жодні події не записуються. Зверніть увагу, що поле rules обовʼязково повинно бути вказано у файлі політики аудиту. Політика з нульовою кількістю (0) прав вважається неприпустимою.

Нижче наведено приклад файлу політики аудиту:

audit/audit-policy.yaml

apiVersion: audit.k8s.io/v1 # Це обовʼязково.
kind: Policy
# Не генерувати події аудиту для всіх запитів на етапі RequestReceived.
omitStages:
  - "RequestReceived"
rules:
  # Логувати зміни у вузлах на рівні RequestResponse
  - level: RequestResponse
    resources:
    - group: ""
      # Ресурс "pods" не відповідає запитам на будь-який підресурс вузлів,
      # що відповідає політиці RBAC.
      resources: ["pods"]
  # Логувати "pods/log", "pods/status" на рівні Metadata
  - level: Metadata
    resources:
    - group: ""
      resources: ["pods/log", "pods/status"]

  # Не логувати запити на configmap під назвою "controller-leader"
  - level: None
    resources:
    - group: ""
      resources: ["configmaps"]
      resourceNames: ["controller-leader"]

  # Не логувати watch-запити "system:kube-proxy" на endpoints або services
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
    - group: "" # Основна група API
      resources: ["endpoints", "services"]

  # Не логувати автентифіковані запити до певних URL-шляхів, що не є ресурсами.
  - level: None
    userGroups: ["system:authenticated"]
    nonResourceURLs:
    - "/api*" # Зіставлення з шаблоном.
    - "/version"

  # Логувати тіло запиту на зміни configmap у kube-system.
  - level: Request
    resources:
    - group: "" # Основна група API
      resources: ["configmaps"]
    # Це правило застосовується тільки до ресурсів в просторі імен "kube-system".
    # Порожній рядок "" можна використовувати для вибору ресурсів без простору імен.
    namespaces: ["kube-system"]

  # Логувати зміни configmap і secret у всіх інших просторах імен на рівні Metadata.
  - level: Metadata
    resources:
    - group: "" # Основна група API
      resources: ["secrets", "configmaps"]

  # Логувати всі інші ресурси в основній і розширюваній групах на рівні Request.
  - level: Request
    resources:
    - group: "" # Основна група API
    - group: "extensions" # Версія групи НЕ повинна включатися.

  # Загальне правило для логування всіх інших запитів на рівні Metadata.
  - level: Metadata
    # Довгострокові запити, такі як watches, які підпадають під це правило,
    # не генерують подію аудиту на етапі RequestReceived.
    omitStages:
      - "RequestReceived"

Ви можете використовувати мінімальну політику аудиту для логування всіх запитів на рівні Metadata:

# Записати всі запити на рівні Metadata.
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

Якщо ви створюєте власний профіль аудиту, ви можете скористатися профілем аудиту для Google Container-Optimized OS як вихідною точкою. Ви можете перевірити сценарій configure-helper.sh, який генерує файл політики аудиту. Більшість файлу політики аудиту можна побачити, дивлячись безпосередньо на цей сценарій.

Ви також можете звернутися до посилання на конфігурацію Policy для отримання деталей про визначені поля.

Бекенди аудиту

Події аудиту зберігаються в зовнішньому сховищі за допомогою бекендів аудиту. Стандартно kube-apiserver надає два бекенди:

• Файловий бекенд, який записує події у файлову систему.
• Бекенд Webhook, який відправляє події на зовнішній HTTP API.

У всіх випадках події аудиту слідують структурі, визначеній API Kubernetes в групі API audit.k8s.io.

[
  {
    "op": "replace",
    "path": "/spec/parallelism",
    "value": 0
  },
  {
    "op": "remove",
    "path": "/spec/template/spec/containers/0/terminationMessagePolicy"
  }
]

Бекенд логів

Бекенд логів записує події аудиту у файл у форматі JSONlines. Ви можете налаштувати бекенд логів за допомогою наступних прапорців kube-apiserver:

• --audit-log-path вказує шлях до файлу логу, який бекенд логів використовує для запису подій аудиту. Відсутність цього прапорця вимикає бекенд логів; - означає стандартний вивід
• --audit-log-maxage визначає максимальну кількість днів для зберігання старих файлів логів аудиту
• --audit-log-maxbackup визначає максимальну кількість файлів логів аудиту для зберігання
• --audit-log-maxsize визначає максимальний розмір в мегабайтах файлу логів аудиту до його ротації

Якщо панель управління вашого кластера працює з kube-apiserver як з Pod, не забудьте змонтувати hostPath до місця розташування файлу політики та файлу логів, щоб записи аудиту були збережені. Наприклад:

  - --audit-policy-file=/etc/kubernetes/audit-policy.yaml
  - --audit-log-path=/var/log/kubernetes/audit/audit.log

потім змонтуйте томи:

...
volumeMounts:
  - mountPath: /etc/kubernetes/audit-policy.yaml
    name: audit
    readOnly: true
  - mountPath: /var/log/kubernetes/audit/
    name: audit-log
    readOnly: false

і нарешті налаштуйте hostPath:

...
volumes:
- name: audit
  hostPath:
    path: /etc/kubernetes/audit-policy.yaml
    type: File

- name: audit-log
  hostPath:
    path: /var/log/kubernetes/audit/
    type: DirectoryOrCreate

Бекенд Webhook

Бекенд аудиту webhook надсилає події аудиту до віддаленого веб-API, яке вважається формою Kubernetes API, включаючи засоби автентифікації. Ви можете налаштувати бекенд webhook за допомогою наступних прапорців kube-apiserver:

• --audit-webhook-config-file вказує шлях до файлу з конфігурацією webhook. Конфігурація webhook фактично є спеціалізованим kubeconfig.
• --audit-webhook-initial-backoff вказує час очікування після першого невдалого запиту перед повторною спробою. Наступні запити повторюються з експоненційною затримкою.

Файл конфігурації webhook використовує формат kubeconfig для вказування віддаленої адреси служби та облікових даних, які використовуються для підключення до неї.

Пакетна обробка подій

Обидва типи бекенд систем, як логів, так і webhook, підтримують пакетну обробку. Використаємо webhook як приклад, ось перелік доступних прапорців. Щоб отримати такий же прапорець для логів, замініть webhook на log у назві прапорця. Стандартно пакетна обробка увімкнена для webhook і вимкнена для log. Так само, типово, обмеження пропускної здатності увімкнено в webhook і вимкнене в log.

• --audit-webhook-mode визначає стратегію буферизації. Одна з наступних:
  • batch — буферизувати події та асинхронно обробляти їх пакетами. Це стандартне значення.
  • blocking — блокувати відповіді сервера API на обробці кожної окремої події.
  • blocking-strict — те саме, що й blocking, але коли відбувається збій під час логування аудиту на етапі RequestReceived, весь запит до kube-apiserver зазнає збою.

Наступні прапорці використовуються тільки в режимі batch:

• --audit-webhook-batch-buffer-size визначає кількість подій для буферизації перед пакетною обробкою. Якщо швидкість надходження подій переповнює буфер, події відкидаються.
• --audit-webhook-batch-max-size визначає максимальну кількість подій в одному пакеті.
• --audit-webhook-batch-max-wait визначає максимальний час очікування перед безумовною буферизацією подій у черзі.
• --audit-webhook-batch-throttle-qps визначає максимальну середню кількість пакетів, що генеруються за секунду.
• --audit-webhook-batch-throttle-burst визначає максимальну кількість пакетів, які генеруються в той же момент, якщо дозволений QPS раніше не використовувався повністю.

Налаштування параметрів

Параметри повинні бути встановлені з урахуванням навантаження на API-сервер.

Наприклад, якщо kube-apiserver отримує 100 запитів кожну секунду, і кожен запит проходить аудит лише на етапах ResponseStarted та ResponseComplete, вам слід розрахувати приблизно 200 подій аудиту, які генеруються кожну секунду. Припускаючи, що в пакеті може бути до 100 подій, вам слід встановити рівень обмеження принаймні у 2 запити на секунду. Припускаючи, що система може потребувати до 5 секунд для запису подій, вам слід встановити розмір буфера для зберігання подій протягом до 5 секунд; це означає: 10 пакетів або 1000 подій.

Проте в більшості випадків стандартні значення параметрів повинні бути достатніми, і вам не потрібно хвилюватися про їх ручне встановлення. Ви можете переглянути наступні метрики Prometheus, які експонує kube-apiserver, а також логи, щоб контролювати стан підсистеми аудиту.

• Метрика apiserver_audit_event_total містить загальну кількість експортованих подій аудиту.
• Метрика apiserver_audit_error_total містить загальну кількість подій, які були втрачені через помилку під час експортування.

Обмеження розміру запису в лозі

Обидва бекенди і логів, і webhook підтримують обмеження розміру подій, які записуються. Наприклад, ось список прапорців, доступних для бекенду логів:

• audit-log-truncate-enabled визначає, чи ввімкнене обрізання подій та пакетів.
• audit-log-truncate-max-batch-size максимальний розмір у байтах пакета, який надсилається до бекенду.
• audit-log-truncate-max-event-size максимальний розмір у байтах аудитивної події, яка надсилається до бекенду.

Типово обрізання вимкнено як у webhook, так і у log. Адміністратор кластера повинен встановити audit-log-truncate-enabled або audit-webhook-truncate-enabled, щоб увімкнути цю функцію.

Що далі

• Дізнайтеся про анотації аудиту мутуючих вебхуків.
• Дізнайтеся більше про типи ресурсів Event та Policy з Довідки налаштування аудиту.