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"

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

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

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

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

Наступні прапорці використовуються тільки в режимі batch (стандартно для бекенду log пакетна обробка вимкнена, і коли пакетну обробку вимкнено, всі прапорці, повʼязані з пакетною обробкою, ігноруються):

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

Примітка:

Примітка: