Модуль 5.2: Спостережуваність безпеки

Складність: [СЕРЕДНЯ] — базові знання. Час на проходження: 25–30 хвилин. Передумови: Модуль 5.1: Безпека образів. Цей модуль передбачає Kubernetes 1.35 або новіший і використовує k як скорочену форму команди після того, як ви визначите alias k=kubectl у своєму шелі.

Результати навчання

Після завершення цього модуля ви зможете:

Оцінювати конфігурації аудит-логування на повноту захоплення подій, важливих для безпеки.
Проєктувати взаємопов’язані сигнали спостережуваності серед логів, метрик, подій та сповіщень середовища виконання для виявлення загроз у Kubernetes.
Діагностувати прогалини моніторингу, через які скомпрометовані робочі навантаження, привілейоване використання API або викрадення даних залишалися б невиявленими.
Впроваджувати робочий процес розслідування інцидентів, що пов’язує аудит-логи, сповіщення середовища виконання та мережеву телеметрію.

Чому цей модуль важливий

Гіпотетичний сценарій: регіональна платіжна компанія виявила, що зловмисник скористався скомпрометованим сервісним акаунтом, щоб переглянути виробничі Secret, виконати exec у довготривалому контейнері та відкрити тихе вихідне з’єднання до репліки бази даних. У кластері були засоби запобігання: образи сканувалися, було ввімкнено Pod Security Admission, а розробники не мали прямого доступу рівня cluster-admin. Інцидент усе одно тривав достатньо довго, щоб обійтися дорого, тому що команда не могла швидко відповісти на базову послідовність питань: хто торкався Secret, який под запустив шел, який простір імен надіслав незвичний трафік і чи модифікувала та сама ідентичність RBAC раніше того тижня.

Фінансовий вплив був спричинений не так одним невдалим засобом контролю, як повільним відновленням картини. Інженери збирали фрагменти з аудит-логів API-сервера, логів вузлів, логів застосунків, експортів хмарного фаєрвола та з чат-каналу, куди сповіщення середовища виконання надсилалися без виклику будь-кого на пейджер. Кожне джерело розповідало частину правди, але ніхто не спроєктував ці сигнали як систему розслідування. До того часу, коли компанія зрозуміла шлях від використання облікових даних до активності в контейнері та доступу до бази даних, реагування вже розрослося до сповіщення клієнтів, перевірки відповідності вимогам і кількох тижнів зміцнення платформи.

Спостережуваність безпеки — це дисципліна про те, як зробити цей шлях видимим ще до інциденту. Вона не замінює запобігання, контроль допуску, принцип найменших привілеїв чи безпеку образів; вона показує вам, чи ці засоби контролю обходяться, використовуються неправильно або тихо відмовляють. KCSA очікує, що ви будете міркувати про аудит-логування Kubernetes, виявлення під час виконання, потоки подій, метрики та маршрутизацію сповіщень як про взаємодоповнювальні рівні. У цьому модулі ви побудуєте практичну ментальну модель того, що логувати, скільки деталей зберігати і як пов’язувати сигнали, щоб підозрілий запит до API ставав придатним до дії розслідуванням, а не рядком, похованим у сховищі.

Стовпи спостережуваності безпеки

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

Найважливіший проєктний крок — прив’язати кожен сигнал до питання про загрозу. Якщо питання звучить “Чи надавав хтось cluster-admin?”, то аудит-лог API-сервера є основним джерелом, бо зміни RBAC є об’єктами API Kubernetes. Якщо питання звучить “Чи запускався шел усередині скомпрометованого контейнера?”, то детектор середовища виконання, як-от Falco чи Tetragon, є кращим джерелом, бо ця дія може взагалі не торкатися API-сервера. Якщо питання звучить “Чи перемістив под дані до незвичного призначення?”, то стають потрібними мережева телеметрія та метрики вихідного трафіку. Хороша спостережуваність називає ці межі, а не вдає, що один інструмент бачить усе.

┌─────────────────────────────────────────────────────────────┐
│              SECURITY OBSERVABILITY                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  LOGS                                                      │
│  ├── API server audit logs                                 │
│  ├── Container application logs                            │
│  ├── Node-level system logs                                │
│  └── Component logs (kubelet, etcd, etc.)                  │
│                                                             │
│  METRICS                                                   │
│  ├── API request rates and errors                          │
│  ├── Resource usage (CPU, memory, network)                 │
│  ├── Authentication/authorization failures                 │
│  └── Custom security metrics                               │
│                                                             │
│  EVENTS                                                    │
│  ├── Kubernetes events (pod events, etc.)                  │
│  ├── Security-specific events                              │
│  ├── Policy violations                                     │
│  └── Runtime security alerts                               │
│                                                             │
│  TRACES                                                    │
│  ├── Request flow through services                         │
│  ├── API call chains                                       │
│  └── Distributed transaction tracking                      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Логи багаті на докази, але дорогі. Вони можуть зберігати ідентичності, посилання на об’єкти, шляхи запитів, коди відповідей, а іноді й тіла запитів, що робить їх цінними під час розслідувань і перевірок відповідності. Компроміс — це обсяг і чутливість: детальні логи коштують грошей для зберігання, уповільнюють пошук і можуть містити інформацію, яка заслуговує на такий самий захист, як і ресурси, що логуються. Тому зріла команда платформи уникає обох крайнощів. Вона не логує нічого і не логує наосліп кожне тіло відповіді для кожного ресурсу назавжди.

Метрики слабші як судові докази, але сильніші як індикатори раннього попередження. Сплеск невдалих автентифікацій, раптовий потік запитів create для подів або незвична частота відхилених рішень авторизації можуть не доводити компрометацію, проте вони можуть спрямувати тих, хто реагує, до правильних логів, перш ніж закриються вікна збереження. Метрики також допомагають відрізнити одну дивну подію від патерну. Один відхилений запит може бути одруком; сотні від нової вихідної ідентичності наводять на думку про зондування, зламану автоматизацію або зловживання обліковими даними.

Події перебувають між цими світами. Kubernetes Events пояснюють збої планування, помилки витягування образів, відмови політик і зміни життєвого циклу, тоді як інструменти безпеки часто видають власні об’єкти подій або вебхук-сповіщення. Вони корисні, бо говорять мовою платформи, але зазвичай недовговічні й не призначені для довготривалих записів. Якщо ваш процес реагування на інциденти залежить від подій, ви маєте пересилати їх до тривкого сховища. Інакше найкорисніший контекст може зникнути ще до того, як хтось розпочне розслідування.

Трейси менш центральні у спостережуваності безпеки KCSA, ніж аудит-логи чи сповіщення середовища виконання, але вони стають корисними в насичених сервісами середовищах. Трейс може показати, що зовнішній запит пройшов через інгрес, сервіс оформлення замовлення, платіжний адаптер та клієнт бази даних, перш ніж видати помилку. Коли трейси несуть ідентичність робочого навантаження та метадані простору імен, вони можуть пов’язувати поведінку застосунку з інфраструктурними сигналами. Це допомагає тим, хто реагує, вирішити, чи відповідає підозріла подія Kubernetes реальному трафіку користувачів, фоновій автоматизації чи активності, керованій зловмисником.

Зупиніться та спрогнозуйте: якщо кластер має ідеальне аудит-логування API-сервера, але не має видимості середовища виконання чи мережі, які частини компрометації контейнера залишаються невидимими? Відповідь має включати все, що відбувається після того, як робоче навантаження вже працює: шел, що читає змінні середовища, менеджер пакетів, що завантажує інструментарій, процес, що сканує внутрішні сервіси, або пряме з’єднання з базою даних, яке ніколи не викликає API Kubernetes.

Аудит-логування Kubernetes

Аудит-логування Kubernetes записує запити, коли вони проходять через API-сервер. Ця позиція є потужною, бо майже кожна навмисна зміна стану кластера протікає через API-сервер: оновлення RBAC, читання Secret, створення подів, видалення просторів імен, рішення допуску та запити exec — усі мають форму API. Вона також обмежена, бо аудит-лог бачить активність API, а не довільну поведінку процесів усередині вже активного контейнера. Сприймайте його як реєстр площини управління, а не як повноцінний сенсор хоста чи застосунку.

Політика аудиту вирішує, які запити логуються і на якому рівні. Рівень — це регулятор точності. Metadata записує, хто зробив запит, на який ресурс він був націлений, коли це сталося, звідки він надійшов і чи був успішним. Request додає тіло запиту, що корисно для операцій створення та патчів, бо ви можете побачити, які поля змінилися. RequestResponse додає також тіло відповіді, що може бути безцінним для деяких розслідувань, але небезпечним для чутливих ресурсів, бо може помістити повернуті дані до сховища логів.

┌─────────────────────────────────────────────────────────────┐
│              AUDIT LOG LEVELS                               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  None       - Don't log                                    │
│  Metadata   - Log request metadata only                    │
│  Request    - Log metadata + request body                  │
│  RequestResponse - Log metadata + request + response       │
│                                                             │
│  AUDIT STAGES:                                             │
│  RequestReceived  - When request first arrives             │
│  ResponseStarted  - After response headers sent            │
│  ResponseComplete - After response body sent               │
│  Panic            - On panic                               │
│                                                             │
│  WHAT TO LOG:                                              │
│  • Anonymous / unauthenticated API access                  │
│  • Secrets access                                          │
│  • RBAC changes                                            │
│  • Pod creation/deletion                                   │
│  • Privileged operations                                   │
│  • Exec into containers                                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Наведена нижче політика навмисно зміщена в бік безпеки. Вона логує анонімний доступ, доступ до Secret, активність exec і attach, зміни RBAC та мутації подів детальніше, ніж звичайні читання. Ширша видимість невдалих автентифікацій для відомих користувачів зазвичай потребує логів API-сервера, метрик автентифікації або аудит-слідів провайдера ідентичності — не одного аудит-правила. Цей порядок важливий, бо правила політики аудиту обчислюються по черзі. Широке правило Metadata, розміщене занадто рано, може випадково завадити пізнішим високоцінним правилам набути чинності. Коли ви оцінюєте політику аудиту, читайте її як політику фаєрвола: згори донизу, питаючи, яке правило перехопить запит першим.

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Log anonymous / unauthenticated API access at metadata level
  - level: Metadata
    users: ["system:anonymous"]
    verbs: ["*"]

  # Log all secret access with request body
  - level: Request
    resources:
    - group: ""
      resources: ["secrets"]

  # Log exec into pods with request and response
  - level: RequestResponse
    resources:
    - group: ""
      resources: ["pods/exec", "pods/attach"]

  # Log RBAC changes
  - level: RequestResponse
    resources:
    - group: "rbac.authorization.k8s.io"
      resources: ["*"]

  # Log pod operations
  - level: Request
    resources:
    - group: ""
      resources: ["pods"]
    verbs: ["create", "delete", "patch", "update"]

  # Default: log metadata for everything else
  - level: Metadata
    omitStages:
    - "RequestReceived"

Зупиніться й подумайте: якщо ви логуєте кожен запит на рівні RequestResponse, ви захоплюєте найбільше деталей, але також створюєте друге високоцінне сховище даних, повне чутливого вмісту. Краще питання не “Як нам максимізувати логи?”, а “Які питання розслідування потребують тіл, а на які можна відповісти з метаданих?”. Читання Secret часто потребує обережного поводження, бо тіла відповідей можуть містити значення, тоді як зміни RBAC і специфікації подів часто виправдовують багатшу деталізацію, бо змінені поля пояснюють вплив на безпеку.

Аудит-подія стає корисною, коли ті, хто реагує, знають, які поля перевіряти першими. Поля user.username та user.groups ідентифікують автентифікованого принципала, sourceIPs показує, звідки, здавалося б, надійшов запит, objectRef ідентифікує ресурс, а responseStatus.code повідомляє, чи спроба була успішною. Поле requestURI особливо корисне для субресурсів, як-от pods/exec, бо субресурс часто розповідає підозрілішу історію, ніж сам батьківський об’єкт. Простий запит get pod є звичайним; exec у виробничий под заслуговує на увагу.

┌─────────────────────────────────────────────────────────────┐
│              AUDIT LOG ENTRY                                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  {                                                         │
│    "kind": "Event",                                        │
│    "apiVersion": "audit.k8s.io/v1",                       │
│    "level": "Request",                                     │
│    "auditID": "abc-123-def",                              │
│    "stage": "ResponseComplete",                            │
│    "requestURI": "/api/v1/namespaces/prod/secrets/db-credentials",│
│    "verb": "get",                                          │
│    "user": {                                               │
│      "username": "alice@example.com",                      │
│      "groups": ["developers"]                              │
│    },                                                      │
│    "sourceIPs": ["10.0.0.5"],                             │
│    "objectRef": {                                          │
│      "resource": "secrets",                                │
│      "namespace": "prod",                                  │
│      "name": "db-credentials"                              │
│    },                                                      │
│    "responseStatus": { "code": 200 },                      │
│    "requestReceivedTimestamp": "2024-01-15T10:30:00Z",    │
│    "stageTimestamp": "2024-01-15T10:30:00Z"               │
│  }                                                         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Наведений вище приклад може швидко відповісти на кілька питань щодо інциденту. Він каже, що користувач, схожий на людину, отримав доступ до виробничого Secret, запит був успішним, а джерело, схоже, було внутрішньою адресою. Сам по собі він не доводить зловмисного наміру. Розробник може мати легітимну роль “розбити скло” (break-glass), завдання автоматизації може уособлювати користувача, або проксі може приховувати справжню адресу клієнта. Саме тому аналіз аудиту слід поєднувати з контекстом RBAC, логами провайдера ідентичності, тікетами змін, телеметрією середовища виконання та базовими лініями нормальної поведінки.

Для перевірок із командного рядка під час лабораторної роботи чи навчання з реагування на інциденти визначте alias k=kubectl, а потім скористайтеся k auth can-i get secrets --as system:serviceaccount:prod:checkout. Ця команда не доводить, що до Secret було отримано доступ, але вона допомагає оцінити, чи мала ідентичність дозвіл, потрібний для виконання доступу, показаного в аудит-лозі. У реальних розслідуваннях перевірки дозволів найсильніші, коли поєднуються з фактичною аудит-подією, бо RBAC міг змінитися після того, як стався підозрілий запит.

Гіпотетичний сценарій: одна команда платформи виявила, що її політика аудиту логувала зміни RBAC на рівні Metadata, а не Request. Під час перевірки компрометації ті, хто реагував, бачили, що ClusterRoleBinding було пропатчено, але не бачили, який суб’єкт було додано, бо тіло запиту було відсутнє, а об’єкт уже встигли змінити знову. Команда зрештою змогла відновити зміну з історії GitOps, але затримка виявила хибу проєктування. Для ресурсів мутації з високим впливом самих метаданих може бути достатньо, щоб сказати вам, що щось сталося, але не достатньо, щоб зберегти деталі, які пояснюють, чому це мало значення.

Моніторинг безпеки середовища виконання

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

Falco — поширений інструмент безпеки середовища виконання з відкритим кодом, бо він спостерігає за системними викликами й збагачує сповіщення контекстом Kubernetes. Важлива ідея не в тому, що кожен кластер має використовувати саме Falco; важлива ідея в тому, що детектор середовища виконання може бачити інший клас поведінки, ніж API-сервер. Він може помітити, що /bin/sh з’явився в контейнері, який зазвичай запускає єдиний вебпроцес, або що процес прочитав чутливий шлях, або що мережева утиліта виконалася всередині робочого навантаження, яке не мало б її мати.

┌─────────────────────────────────────────────────────────────┐
│              FALCO RUNTIME SECURITY                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  WHAT IS FALCO?                                            │
│  • CNCF runtime security project                           │
│  • Monitors system calls in real-time                      │
│  • Detects anomalous behavior                              │
│  • Kubernetes-aware (pod context)                          │
│                                                             │
│  HOW IT WORKS:                                             │
│  Kernel → eBPF (modern driver) or legacy kernel module →  │
│           Falco → Rules → Alerts                           │
│                                                             │
│  DETECTS:                                                  │
│  • Shell spawned in container                              │
│  • Sensitive file access (/etc/shadow)                     │
│  • Network connections from unexpected processes           │
│  • Privilege escalation attempts                           │
│  • Container escape techniques                             │
│  • Crypto mining behavior                                  │
│                                                             │
│  OUTPUT OPTIONS:                                           │
│  • Syslog, stdout                                          │
│  • HTTP webhook                                            │
│  • Slack, email alerts                                     │
│  • SIEM integration                                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Правила середовища виконання потребують налаштування, бо нормальна поведінка різниться залежно від робочого навантаження. Шел усередині недовговічного налагоджувального пода може бути очікуваним під час запланованого вікна обслуговування, тоді як той самий шел усередині контейнера платіжного API є вкрай підозрілим. Менеджер пакетів у завданні збірки може бути рутинним, тоді як менеджер пакетів у виробничому образі середовища виконання наводить на думку про дрейф або інструментарій зловмисника. Мета не в нулі сповіщень; мета — у сповіщеннях, які несуть достатньо контексту робочого навантаження, серйозності та інформації про маршрутизацію, щоб створити швидке й правильне реагування.

# Detect shell spawned in container
- rule: Terminal shell in container
  desc: A shell was spawned in a container
  condition: >
    spawned_process and
    container and
    shell_procs and
    proc.tty != 0
  output: >
    Shell spawned in container
    (user=%user.name container=%container.name
     shell=%proc.name pod=%k8s.pod.name)
  priority: WARNING

# Detect sensitive file access
- rule: Read sensitive file in container
  desc: Sensitive file read in container
  condition: >
    open_read and
    container and
    sensitive_files
  output: >
    Sensitive file read in container
    (file=%fd.name user=%user.name
     container=%container.name pod=%k8s.pod.name)
  priority: WARNING

# Detect privilege escalation
- rule: Privilege escalation via setuid
  desc: Process set user ID
  condition: >
    evt.type = setuid and
    container and
    evt.arg.uid = 0 and
    not proc.name in (setuid_whitelist)
  output: >
    Privilege escalation detected
    (user=%user.name command=%proc.cmdline
     container=%container.name)
  priority: CRITICAL

Перш ніж запускати набір правил у виробництві, запитайте, який вивід ви очікуєте від відомо справного робочого навантаження. Якщо ваші нормальні образи запускають шел під час налаштування точки входу (entrypoint), правило про шел може породжувати шум, якщо ви не додасте виняток. Якщо контейнер бази даних легітимно читає файли, що збігаються із загальним списком чутливих шляхів, правило про файли може потребувати налаштування під конкретне навантаження. Хороший моніторинг середовища виконання ближчий до розміщення пожежної сигналізації, ніж до стеження: замала покривність пропускає пожежі, але сигналізації, що спрацьовують щоранку, привчають людей їх ігнорувати.

Falco — не єдиний варіант середовища виконання, і вибір інструмента має слідувати за операційною вимогою. Tetragon з екосистеми Cilium використовує eBPF і може спостерігати за виконанням процесів, доступом до файлів і мережевою поведінкою з прикріпленою ідентичністю Kubernetes. KubeArmor зосереджується на політиці та примусовому застосуванні через модулі безпеки Linux. Комерційні платформи часто поєднують виявлення під час виконання з даними про вразливості, звітами про відповідність і керованими правилами. Правильний вибір залежить від того, чи потрібні вам відкриті правила, гачки примусового застосування, кероване обслуговування або інтеграція з ширшою платформою безпеки.

┌─────────────────────────────────────────────────────────────┐
│              RUNTIME SECURITY TOOLS                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  TETRAGON (Cilium)                                         │
│  ├── eBPF-based security observability                     │
│  ├── Process execution, network, file access               │
│  ├── Enforcement capabilities                              │
│  └── Low overhead                                          │
│                                                             │
│  SYSDIG                                                    │
│  ├── Commercial runtime security                           │
│  ├── Built on Falco technology                            │
│  ├── Managed rules and compliance                          │
│  └── Enterprise features                                   │
│                                                             │
│  KUBEARMOR (CNCF Sandbox)                                  │
│  ├── LSM-based enforcement                                 │
│  ├── Process, file, network policies                       │
│  ├── Less established than Falco                           │
│  └── Focus on enforcement                                  │
│                                                             │
│  AQUA/PRISMA/STACKROX (RHACS)                              │
│  ├── StackRox → Red Hat Advanced Cluster Security         │
│  ├── Commercial platforms                                  │
│  ├── Full-stack security                                   │
│  ├── Runtime + vulnerability management                    │
│  └── Compliance and reporting                              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Практична різниця між виявленням і захистом — це час реагування. Сповіщення середовища виконання, що потрапляє до каналу без нагляду, корисне пізніше як доказ, але може й не запобігти шкоді. Критичне сповіщення, яке викликає чергового на пейджер, відкриває інцидент, прикріплює метадані пода, посилається на аудит-запит і пропонує runbook для карантину, має значно кращі шанси змінити результат. Деякі інструменти можуть застосовувати політики напряму, як-от убити процес чи заблокувати поведінку, але примусове застосування породжує власний ризик для доступності й має ретельно тестуватися.

Зупиніться та спрогнозуйте: Falco виявляє шел, породжений усередині виробничого контейнера, і публікує повідомлення в Slack-канал, який черговий інженер перевіряє кожні кілька годин. Чи є такий моніторинг ефективним? Виявлення стає захистом лише тоді, коли сигнал досягає того, хто реагує, достатньо швидко, містить контекст, потрібний для рішення, і поєднаний із відпрацьованою дією, як-от ізоляція робочого навантаження, збір доказів або відкликання облікових даних.

Події безпеки, за якими варто стежити

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

┌─────────────────────────────────────────────────────────────┐
│              CRITICAL SECURITY EVENTS                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  AUTHENTICATION                                            │
│  ├── Failed authentication attempts                        │
│  ├── Anonymous API access                                  │
│  ├── Use of highly privileged accounts                     │
│  └── Authentication from unexpected sources                │
│                                                             │
│  AUTHORIZATION                                             │
│  ├── RBAC permission denied events                         │
│  ├── Attempts to access secrets                            │
│  ├── Cluster-admin role usage                             │
│  └── Privilege escalation patterns                         │
│                                                             │
│  WORKLOAD                                                  │
│  ├── Privileged pod creation                               │
│  ├── Host namespace usage (hostPID, hostNetwork)           │
│  ├── Exec into containers                                  │
│  ├── Port forwarding                                       │
│  └── Pod creation with service account tokens              │
│                                                             │
│  RUNTIME                                                   │
│  ├── Shell processes in containers                         │
│  ├── Sensitive file access                                 │
│  ├── Outbound network connections                          │
│  ├── Package manager execution                             │
│  └── Crypto mining signatures                              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Не кожна високопріоритетна подія заслуговує на однакове реагування. Одна невдала автентифікація з ноутбука розробника може бути звичайною, тоді як анонімний доступ до API з адреси, відкритої в інтернет, є сильнішим сигналом. Под, що використовує hostNetwork у просторі імен моніторингу, може бути очікуваним, тоді як те саме поле в просторі імен публічного застосунку може бути відмовою політики. Читання Secret сервісним акаунтом застосунку може бути нормальним під час запуску, тоді як операція list по багатьох Secret є поширеним патерном розвідки. Контекст перетворює сирі події на судження про безпеку.

Запити для виявлення слід писати як стартери для розслідування, а не як магічні машини істини. Запит для несанкціонованого доступу до Secret починається з успішних запитів get, list або watch до ресурсів Secret, а потім віднімає очікуваних користувачів і сервісні акаунти. Запит для створення привілейованого пода починається зі створень або патчів подів, чиє тіло запиту містить привілейовані поля, налаштування простору імен хоста чи небезпечні монтування томів. Запит для виробничого exec зосереджується на субресурсах pods/exec у виробничих просторах імен, бо інтерактивний доступ змінює ризик інциденту навіть тоді, коли ідентичність легітимна.

┌─────────────────────────────────────────────────────────────┐
│              EXAMPLE DETECTION QUERIES                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  UNAUTHORIZED SECRET ACCESS:                               │
│  Filter audit logs where:                                  │
│  • resource = secrets                                      │
│  • verb = get, list, watch                                │
│  • responseStatus.code = 200                              │
│  • user not in expected list                              │
│                                                             │
│  PRIVILEGED POD CREATION:                                  │
│  Filter audit logs where:                                  │
│  • resource = pods                                         │
│  • verb = create                                          │
│  • requestObject contains privileged: true                │
│                                                             │
│  EXEC INTO PRODUCTION:                                     │
│  Filter audit logs where:                                  │
│  • resource = pods/exec                                    │
│  • namespace in [production, prod]                        │
│  • Alert on any occurrence                                 │
│                                                             │
│  RBAC CHANGES:                                             │
│  Filter audit logs where:                                  │
│  • apiGroup = rbac.authorization.k8s.io                   │
│  • verb = create, update, patch, delete                   │
│  • Alert on changes to ClusterRoleBindings                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Кореляція — це те, де ці запити стають потужними. Уявіть аудит-сповіщення про сервісний акаунт, що перелічує Secret, за яким через шість хвилин іде сповіщення середовища виконання про шел у тому самому поді, а далі — незвичний вихідний трафік із того простору імен. Кожен сигнал окремо має невинне пояснення: контролер міг перелічувати Secret, інженер міг налагоджувати под, а трафік міг зрости під час релізу. Разом, у вузькому часовому вікні, вони утворюють правдоподібний ланцюг вторгнення, який заслуговує на термінове реагування.

Зворотне також правильне: кореляція може зменшити кількість хибних спрацьовувань. Якщо виробничий exec відбувається під час схваленого інциденту, від очікуваного інженера, після тікета зміни й без жодних подальших індикаторів середовища виконання, сповіщення може залишитися інформаційним. Це не означає, що його слід ігнорувати; це означає, що реагуванням може бути збереження доказів і перегляд, а не екстрене стримування. Сильна програма моніторингу підтримує як ескалацію, так і деескалацію, надаючи достатньо супутніх фактів.

Гіпотетичний сценарій: одна команда колись надсилала сповіщення про кожен відхилений запит RBAC і створила стільки шуму, що інженери перестали читати канал. Під час реальної атаки зловмисник генерував відхилені запити, зондуючи дозволи, але сигнал зливався з фоном. Виправленням було не видалити сповіщення. Команда змінила його, щоб виявляти незвичні частоти відхилених запитів за ідентичністю, простором імен і джерелом, а потім поєднала його з успішними чутливими операціями того самого принципала. Результатом стало менше сповіщень із чіткішою історією.

Розбір на прикладі: відстеження однієї підозрілої ідентичності

Припустімо, сповіщення каже, що system:serviceaccount:prod:reporting успішно перелічив Secret у просторі імен prod. Перша помилка — питати, чи мають сервісні акаунти взагалі коли-небудь читати Secret в абстрактному сенсі. Деякі застосунки легітимно читають невелику кількість Secret, а деяким контролерам потрібен ширший доступ для узгодження ресурсів. Краще перше питання — чи виконує ця ідентичність зазвичай це дієслово над цим ресурсом у цьому просторі імен. Спостережуваність безпеки найкорисніша, коли вона порівнює конкретну подію з конкретною очікуваною поведінкою.

Почніть з аудит-логу, бо підозріла дія є запитом до API Kubernetes. Підтвердіть дієслово, ресурс, простір імен, код відповіді, вихідний IP, user agent і позначку часу. Якщо подія є list, а не get, підніміть пріоритет, бо операції list часто розкривають більше ніж один об’єкт і поширені під час розвідки. Якщо вихідний IP належить поду, перейдіть від IP до імені пода, власника, вузла та дайджесту образу, використовуючи метадані кластера з конвеєра логів. Цей перехід значно швидший, коли збирачі послідовно збагачують записи.

Далі перевірте RBAC навколо часу запиту. Поточний результат k auth can-i корисний, але він описує лише дозволи, що існують зараз. Якщо прив’язку ролі було створено, пропатчено чи видалено незадовго до доступу до Secret, поточна відповідь може приховувати шлях, який зробив запит можливим. Тому аудит-події для roles, rolebindings, clusterroles та clusterrolebindings слід шукати у вікні навколо події. Саме тут окупається багатша деталізація аудиту для змін RBAC, бо змінений суб’єкт і роль пояснюють шлях привілеїв.

Після перегляду площини управління перейдіть до доказів середовища виконання для пода, що використовував сервісний акаунт. Шукайте виконання шела, активність менеджера пакетів, підозрілі читання файлів, неочікувані дочірні процеси та мережеві інструменти, запущені поблизу часу доступу до Secret. Мета — вирішити, чи було читання Secret поведінкою застосунку, поведінкою контролера чи поведінкою зловмисника після компрометації. Под, що перелічив Secret, а потім породив шел, є значно сильнішим сигналом інциденту, ніж под, що перелічив один відомий Secret під час нормального запуску.

Мережева телеметрія дає наступний рівень. Подія доступу до Secret може бути кроком зі збору облікових даних, але шкода часто з’являється, коли обліковий запис використовується проти іншого сервісу. Перевірте вихідний трафік із простору імен, з’єднання пода з базами даних чи хмарними API та трафік до призначень, з якими робоче навантаження зазвичай не контактує. Якщо ваші мережеві логи містять мітки Kubernetes та ідентичність сервісного акаунта, розслідування може відстежувати того самого принципала через активність API, поведінку процесів і трафік. Якщо ні, тим, хто реагує, доводиться виводити ідентичність з IP-адрес, які можуть повторно використовуватися.

Нарешті, вирішіть, чи стримувати, спостерігати чи закривати. Стримування може включати видалення пода, масштабування робочого навантаження до нуля, застосування обмежувальної NetworkPolicy, ротацію Secret, до якого було отримано доступ, або відкликання токена сервісного акаунта. Спостереження може бути доречним, коли подія збігається з відомим розгортанням і не з’являється жодних індикаторів середовища виконання чи мережі. Закриття все одно має залишати запис про те, чому подію вважали безпечною, бо майбутнім тим, хто реагує, потрібно відрізняти підтверджену нормальну поведінку від проігнорованого шуму. Рішення сильніше, коли кожен рівень вніс свої докази.

Цей розбір також показує, чому дашборди мають підтримувати переходи, а не лише підсумки. Графік, що каже “Читання Secret зросли”, може бути достатнім, щоб розпочати розслідування, але він не ідентифікує дійову особу, робоче навантаження чи наступний запит. Корисний дашборд дозволяє тому, хто реагує, перейти від доступу до ресурсу до ідентичності, від ідентичності до змін RBAC, від робочого навантаження до сповіщень середовища виконання, а від простору імен до вихідного трафіку. Інтерфейс не обов’язково має бути вишуканим; він має зберігати слідчий ланцюг під тиском часу.

Той самий метод застосовується до створення привілейованого пода. Почніть з аудит-події для мутації пода, перевірте тіло запиту на securityContext, налаштування простору імен хоста та монтування томів, потім пов’яжіть новий под із його сервісним акаунтом та образом. Моніторинг середовища виконання може показати, чи запустив той под одразу інструменти або торкнувся чутливих файлів. Мережева телеметрія може показати, чи контактував він із сервісом метаданих, ендпойнтами бази даних чи незнайомими зовнішніми адресами. Проєкт спостережуваності успішний, коли кожен перехід є очікуваним і відпрацьованим, а не винайденим під час інциденту.

Коли ви оцінюєте кластер для питань у стилі KCSA, шукайте ці переходи явно. Запитайте, чи можна прив’язати чутливу подію API до ідентичності, чи можна прив’язати ту ідентичність до робочого навантаження, чи можна прив’язати робоче навантаження до поведінки середовища виконання та чи можна прив’язати поведінку середовища виконання до мережевого впливу. Якщо одна ланка відсутня, назвіть прогалину моніторингу, а не відмахуйтеся від неї. Точне формулювання прогалини цінніше за розпливчасте твердження, що кластеру потрібна “краща спостережуваність”.

Останній урок полягає в тому, що проєкт спостережуваності слід тестувати навчаннями. Створіть нешкідливий сценарій доступу до Secret, сценарій запланованого виробничого exec та симульоване сповіщення про шел середовища виконання в невиробничому середовищі. Потім попросіть чергового інженера відновити історію з доступних сигналів. Якщо він може відповісти, хто діяв, що змінилося, що запустилося, який трафік за цим пішов і яка дія очікувалася, то проєкт працює. Якщо ні, навчання знайшло виправну прогалину раніше, ніж від неї залежатиме справжній зловмисник.

Архітектура логування

Архітектура логування Kubernetes має три завдання: збирати дані поблизу джерела, збагачувати їх контекстом Kubernetes і зберігати їх там, де ті, хто реагує, можуть швидко їх шукати. Логи контейнерів зазвичай живуть на вузлах, перш ніж агент пересилає їх далі. Аудит-логи API можуть записуватися API-сервером у файли, вебхуки чи інтеграції керованого провайдера. Інструменти середовища виконання можуть надсилати сповіщення до stdout, syslog, вебхуків чи платформ безпеки. Якщо ці шляхи спроєктовані незалежно, ті, хто реагує, витрачають інциденти на ручне зшивання позначок часу й імен.

┌─────────────────────────────────────────────────────────────┐
│              KUBERNETES LOGGING STACK                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  COLLECTION                                                │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Nodes                                              │   │
│  │  ├── Fluent Bit / Fluentd (DaemonSet)              │   │
│  │  ├── Collects container logs                        │   │
│  │  ├── Collects node logs                             │   │
│  │  └── Adds Kubernetes metadata                       │   │
│  └─────────────────────────────────────────────────────┘   │
│                         ↓                                   │
│  AGGREGATION                                               │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Central Logging                                    │   │
│  │  ├── Elasticsearch / Loki / Splunk                 │   │
│  │  ├── Long-term storage                              │   │
│  │  └── Indexed for search                             │   │
│  └─────────────────────────────────────────────────────┘   │
│                         ↓                                   │
│  ANALYSIS                                                  │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Visualization/SIEM                                 │   │
│  │  ├── Kibana / Grafana                              │   │
│  │  ├── Security dashboards                            │   │
│  │  └── Alert rules                                    │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Агенти збору мають додавати метадані, що дозволяють людині переходити між сигналами. Простір імен, ім’я пода, ім’я контейнера, ім’я вузла, власник робочого навантаження, сервісний акаунт, ім’я кластера та дайджест образу — усі корисні. Без цих полів ті, хто реагує, зрештою шукають за сирим текстом повідомлення, що крихко й повільно. З цими полями сповіщення середовища виконання може вказати на под, под може вказати на свій сервісний акаунт, а сервісний акаунт може вказати на відповідні аудит-події.

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

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

┌─────────────────────────────────────────────────────────────┐
│              SECURITY DASHBOARD METRICS                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  AUTHENTICATION PANEL                                      │
│  ├── Auth attempts over time                               │
│  ├── Failed auth by user/source IP                         │
│  ├── Anonymous access attempts                             │
│  └── Unusual authentication patterns                       │
│                                                             │
│  API ACTIVITY PANEL                                        │
│  ├── API requests by verb (create, delete, etc.)          │
│  ├── Requests to sensitive resources                       │
│  ├── Requests by user/service account                      │
│  └── Error rates and types                                 │
│                                                             │
│  WORKLOAD SECURITY PANEL                                   │
│  ├── Privileged pods running                               │
│  ├── Pods with host access                                 │
│  ├── Policy violations                                     │
│  └── Image vulnerability summary                           │
│                                                             │
│  RUNTIME ALERTS PANEL                                      │
│  ├── Falco alerts by severity                              │
│  ├── Shell spawns in containers                            │
│  ├── Sensitive file access                                 │
│  └── Network anomalies                                     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Маршрутизація сповіщень має відображати серйозність і власність. Невдале витягування образу належить команді застосунку, якщо тільки воно не наводить на думку про підробку ланцюга постачання. Шел у виробничому контейнері може належати як власнику сервісу, так і черговому з безпеки. Зміна ClusterRoleBinding може належати інженерії платформи та керуванню ідентичностями. Маршрутизація кожного сигналу до одного центрального каналу породжує втому, тоді як маршрутизація сигналів лише до команд сервісів може приховувати патерни атак між просторами імен. Проєкт має зберігати як локальну власність, так і центральну видимість.

Існує також межа довіри навколо самої системи логування. Зловмисники, що отримують дозволи кластера, можуть спробувати видаляти поди, ротувати логи, вимикати агентів чи заповнювати сховище шумом. Для чутливих середовищ надсилайте аудит-дані за межі кластера або до зміцненої інтеграції площини управління, обмежуйте, хто може змінювати конфігурації збирачів, і надсилайте сповіщення, коли агенти логування перестають звітувати. Спостережуваність є частиною системи безпеки; якщо її можуть тихо вимкнути ті самі ідентичності, за якими вона стежить, вона слабша, ніж видається.

Патерни та антипатерни

Патерн: багаторівнева деталізація аудиту

Використовуйте багаторівневу деталізацію аудиту, коли різні ресурси мають різну цінність для розслідування та різну чутливість. Мутації RBAC, субресурси exec, зміни вебхуків допуску та специфікації привілейованих подів зазвичай заслуговують на багатше логування, бо змінені поля пояснюють ризик. Рутинні читання малочутливих ресурсів зазвичай не потребують тіл запитів. Цей патерн працює, бо він приймає, що логи є водночас доказом і відповідальністю, а потім свідомо витрачає деталізацію там, де вона матиме значення під час інциденту.

Міркування щодо масштабування — це підтримка політики. Коли команди додають контролери, кастомні ресурси та розширення платформи, політику аудиту слід переглядати, щоб важливі шляхи мутації не потрапляли до малодетального стандартного правила. Кастомні ресурси, що надають доступ до інфраструктури, керують обліковими даними чи змінюють поведінку допуску, можуть бути такими самими важливими для безпеки, як і вбудовані ресурси Kubernetes. Застаріла політика може виглядати повною, водночас пропускаючи об’єкти, від яких ваша платформа насправді залежить.

Патерн: runbook-и для корельованих сповіщень

Використовуйте корельовані runbook-и, коли одне сповіщення не дає достатньо впевненості, щоб діяти самостійно. Runbook для доступу до Secret може вказати тим, хто реагує, перевірити ідентичність, вихідний IP, простір імен, дозволи сервісного акаунта, пов’язані зміни RBAC, сповіщення середовища виконання з того самого пода та вихідний трафік із простору імен. Це перетворює моніторинг на повторюваний робочий процес розслідування замість купи дашбордів. Це також допомагає новішим черговим інженерам ухвалювати послідовні рішення під стресом.

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

Патерн: тривкі докази за межами кластера

Використовуйте тривкі докази за межами кластера для аудит-логів, критичних сповіщень середовища виконання та сигналів справності збирачів. Локальне сховище вузла корисне для усунення несправностей, але слабке як єдине судове джерело, бо вузли можна замінити, скомпрометувати чи очистити. Сховище за межами кластера ускладнює локальному для кластера зловмиснику стерти запис. Воно також дозволяє тим, хто реагує на інциденти, продовжувати розслідування, якщо стримування потребує дренування вузлів чи видалення підозрілих робочих навантажень.

Міркування щодо масштабування — це контроль доступу. Центральні сховища логів часто стають потужними, бо вони містять записи з багатьох кластерів і просторів імен. Дайте тим, хто реагує, достатньо доступу, щоб швидко розслідувати, але уникайте перетворення системи логів на необмежене озеро даних із Secret, токенів, тіл запитів та ідентифікаторів клієнтів. Чутливі аудит-потоки мають мати рольовий доступ, правила збереження та моніторинг власних адміністративних змін.

Антипатерн: логування всього без власності

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

Антипатерн: сприйняття аудит-логів як безпеки середовища виконання

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

Антипатерн: сповіщення без шляхів реагування

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

Каркас прийняття рішень

Почніть із питання розслідування, потім оберіть сигнал. Якщо питання запитує, хто змінив об’єкт Kubernetes, почніть з аудит-логів. Якщо воно запитує, що процес зробив усередині контейнера, почніть із телеметрії середовища виконання. Якщо воно запитує, чи покинув трафік простір імен або кластер, почніть зі спостережуваності мережі. Якщо воно запитує, чи проходила орієнтована на користувача транзакція підозрілим шляхом, почніть із трейсів і логів застосунків. Цей порядок не дає вам втискати кожну проблему в той інструмент, що випадково встановлений.

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

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

Нарешті, перегляньте проєкт щодо режимів відмови. Що, якщо агент логування зупиниться на одному вузлі? Що, якщо аудит-бекенд буде недоступним? Що, якщо зловмисник змінить RBAC, а потім генеруватиме шум? Що, якщо сповіщення міститиме чутливі поля, що пересилаються до широкого чат-каналу? Хороший проєкт спостережуваності включає перевірки справності системи моніторингу, захищає сховище доказів і уникає витоку чутливих слідчих даних до призначень із низькою довірою.

Чи знали ви?

Політика аудиту Kubernetes досягла стабільного API audit.k8s.io/v1 задовго до Kubernetes 1.35, а це означає, що сучасні кластери можуть покладатися на стабільний формат політики замість експериментальної конфігурації аудиту.
Falco приєднався до CNCF у 2018 році та став випускником (graduated) у 2024 році, що відображає роки операційного використання для виявлення загроз середовища виконання в контейнерних і Kubernetes-середовищах.
Один завантажений кластер може генерувати багато гігабайтів аудит-даних на день, тому збереження, фільтрація та вибір полів є фінансовими засобами контролю не меншою мірою, ніж засобами безпеки.
Kubernetes Events не є тривким судовим записом за замовчуванням, тому командам, що покладаються на них для розслідувань безпеки, потрібні пересилання та збереження поза недовговічним потоком подій.

Типові помилки

Помилка	Чому вона трапляється	Як це виправити
Відсутнє аудит-логування	Команди припускають, що керовані площини управління чи логи застосунків нададуть достатньо доказів після інциденту.	Увімкніть явну політику аудиту чи аудит-інтеграцію провайдера й підтвердіть, що захоплюються чутливі ресурси, RBAC, мутації подів і субресурси exec.
Логування всього на максимальній деталізації	Інженери бояться пропустити докази й широко обирають `RequestResponse` без урахування вартості чи чутливості.	Використовуйте багаторівневі рівні аудиту, приберігайте тіла для високоцінних мутацій і захищайте сховище аудиту як чутливу систему.
Відсутній моніторинг середовища виконання	Команда сприймає аудит-логи API як повну видимість безпеки й забуває про поведінку всередині контейнера.	Додайте виявлення середовища виконання, як-от Falco, Tetragon, KubeArmor чи керовану платформу для поведінки процесів, файлів і мережі.
Сповіщення без власності реагування	Встановлення інструмента завершується ще до того, як визначено маршрутизацію до чергових, правила серйозності та runbook-и.	Призначте власників сповіщень, маршрутизуйте критичні сигнали на пейджинг і прикріплюйте кроки розслідування до кожного високопріоритетного виявлення.
Коротке збереження логів безпеки	Бюджети сховища встановлюються для зручності налагодження, а не для часових ліній інцидентів.	Визначайте збереження за вимогами розслідування, тримайте нещодавні записи доступними для пошуку та безпечно архівуйте старіші докази безпеки.
Незахищені сховища логів	Аудит-логи сприймаються як нешкідливі метадані, навіть коли вони містять тіла запитів чи посилання на чутливі об’єкти.	Обмежте доступ, моніторте адміністрування сховища логів і уникайте надсилання чутливих полів до широких чат-каналів.
Відсутні перевірки справності моніторингу	Збирачі та конвеєри сповіщень вважаються робочими, доки інцидент не доведе протилежне.	Надсилайте сповіщення, коли агенти перестають звітувати, аудит-бекенди відмовляють чи очікувані метадані кластера зникають із вхідних записів.

Тест

Ваша команда має розслідувати, хто отримав доступ до виробничого Secret, але політика аудиту логує читання Secret лише на рівні `Metadata`. Чи можете ви відповісти на основне питання і який ризик додав би `RequestResponse`?

Так, метадані зазвичай відповідають на основне питання про доступ, бо вони включають автентифікованого користувача, групи, вихідні IP, цільовий ресурс, простір імен, дієслово, позначку часу та статус відповіді. Вони не включатимуть повернутих даних Secret, що зазвичай є перевагою, бо сховище логів не має ставати ще одним місцем, де живуть значення секретів. `RequestResponse` може додати судову деталізацію для деяких ресурсів, але для читань Secret він може розкрити чутливі тіла відповідей і збільшити радіус ураження. Кращий проєкт — захоплювати достатньо метаданих для підзвітності, водночас використовуючи багатші рівні для мутацій, де тіло запиту пояснює, що змінилося.

Falco повідомляє про шел у виробничому контейнері, але сповіщення потрапило лише до малозавантаженого чат-каналу й було помічене за кілька годин. Яку прогалину це виявляє і як має змінитися проєкт спостережуваності?

Прогалина не у спроможності виявлення; детектор побачив підозрілу поведінку. Невдача полягає у проєкті реагування, бо критичний сигнал не досяг потрібної людини достатньо швидко й не був пов'язаний із runbook-ом стримування. Проєкт має маршрутизувати високосерйозні сповіщення середовища виконання на пейджинг чи автоматизацію інцидентів, включати контекст пода й простору імен і посилатися на аудит- та мережеві запити для того самого робочого навантаження. Якщо організація приймає ризик, високовпевнене правило може також запускати карантин чи завершення процесу після тестування.

Колега хоче зменшити обсяг аудиту, встановивши все на `None`, окрім Secret і RBAC. Які прогалини моніторингу це створило б?

Така політика втратила б видимість створення подів, оновлень подів, субресурсів exec та attach, змін ServiceAccount, об'єктів, пов'язаних із допуском, змін простору імен та інших шляхів мутації, які зловмисники використовують для отримання виконання чи закріплення. Secret і RBAC важливі, але вони не є всім шляхом атаки. Кращий підхід — багаторівневе логування: висока деталізація для чутливих мутацій, метадані для більшості інших мутацій і придушення лише для добре зрозумілого малоцінного шуму. Мета — зменшити обсяг, не видаляючи слід, що пояснює, як зловмисник перемістився від ідентичності до виконання робочого навантаження.

Аудит-запис показує доступ до Secret із внутрішнього IP пода, а не з робочої станції розробника. Як ви діагностуєте, чи це нормально, чи підозріло?

Почніть з ідентифікації сервісного акаунта, простору імен, власника пода та точного об'єкта Secret з аудит-події. Потім порівняйте доступ з очікуваною поведінкою застосунку: чи має той сервісний акаунт читати той Secret, чи зазвичай він викликає API-сервер і чи був запит одиничним `get`, чи широкою операцією `list`. Корелюйте позначку часу зі сповіщеннями середовища виконання та мережевою телеметрією з того самого пода, бо скомпрометоване робоче навантаження може використати свій токен після початкової експлуатації. Подія не є автоматично зловмисною, але вона заслуговує на розслідування, якщо ідентичність, простір імен, дієслово чи обсяг доступу є незвичними.

Зловмисник компрометує застосунок, читає змінні середовища, з'єднується напряму з базою даних і викрадає дані, не викликаючи API Kubernetes. Чи виявили б атаку аудит-логи API?

Ні, аудит-логи API не виявили б читання змінних середовища всередині контейнера чи прямого з'єднання з базою даних, бо ці дії не проходять через API-сервер Kubernetes. Аудит-лог може показати початкове створення пода чи раніше монтування Secret, але він не покаже поведінку процесів після того, як робоче навантаження вже працює. Моніторинг середовища виконання може виявити незвичну активність процесів, а мережева телеметрія може виявити неочікуваний вихідний трафік чи переміщення даних. Цей сценарій є причиною, чому спостережуваність безпеки має поєднувати аудит-логи із сигналами середовища виконання та мережі.

Дашборд показує сплеск відхилених запитів RBAC від одного сервісного акаунта, за яким іде успішне оновлення ClusterRoleBinding іншим користувачем. Що тим, хто реагує, слід перевірити далі?

Тим, хто реагує, слід сприйняти цю послідовність як можливий шлях підвищення привілеїв, а не як дві непов'язані події. Вони мають перевірити відхилені запити, щоб дізнатися, які дозволи зондувалися, переглянути успішну зміну ClusterRoleBinding, щоб ідентифікувати додані суб'єкти та ролі, і перевірити, чи з'являється той самий вихідний IP, простір імен чи акаунт автоматизації в обох часових лініях. Вони мають також пошукати подальші чутливі операції, як-от перелічення Secret, створення подів чи exec. Це міркування важливе, бо зловмисники часто спершу зондують, а потім використовують сильнішу ідентичність чи неправильну конфігурацію, щоб завершити дію.

Ви впроваджуєте новий робочий процес інцидентів для сигналів спостережуваності. Які докази слід зібрати першими, коли спрацьовує сповіщення про виробничий exec?

Зберіть спершу нестійкий контекст: аудит-подію для запиту `pods/exec`, ідентичність і вихідний IP, власника пода, сервісний акаунт, вузол, дайджест образу та сповіщення середовища виконання навколо тієї самої позначки часу. Потім збережіть логи контейнера й відповідну мережеву телеметрію перед видаленням чи перезапуском будь-чого, якщо тільки терміновість стримування не переважає збір доказів. Перевірте, чи змінювалися RBAC або доступ до Secret незадовго до події exec, бо інтерактивний доступ часто є одним кроком у більшому ланцюгу. Робочий процес має робити ці переходи повторюваними, щоб ті, хто реагує, не імпровізували під тиском.

Практична вправа: проєктування політики аудиту

У цій вправі ви спроєктуєте виробничу політику аудиту та контрольний список розслідування для кластера, що використовує Kubernetes 1.35 або новіший. Сценарій навмисно реалістичний: команда платформи хоче сильних доказів для чутливих операцій, не топлячи бекенд логування в малоцінному трафіку. Ви використовуватимете k у перевірках після встановлення alias k=kubectl, але головним артефактом є міркування про політику, а не жива зміна кластера.

Сценарій: спроєктуйте політику аудиту для виробничого кластера. Визначте, що логувати на кожному рівні:

Вимоги:

Увесь доступ до Secret має логуватися
Усі зміни RBAC мають логуватися з повною деталізацією
Створення/видалення подів у виробничому просторі імен потребує логування
Exec у будь-який под є високопріоритетним
Звичайні операції читання мають мати мінімальне логування

Опрацюйте завдання по порядку. Кожне завдання додає один рівень: ідентифікувати захищені ресурси, обрати рівень аудиту, пояснити компроміс, пов’язати сигнал із реагуванням і перевірити, що отримана політика підтримує результати навчання з цього модуля. Якщо у вас є тестовий кластер, ви можете адаптувати політику до конфігурації вашого API-сервера; якщо ні, вправа все одно працює як перегляд проєкту.

Ідентифікуйте ресурси й субресурси API, що мають бути високопріоритетними: Secret, ресурси RBAC, pods/exec, pods/attach, pods/portforward, ServiceAccount та мутації виробничих подів.
Оберіть рівень аудиту для кожної високопріоритетної категорії й напишіть одне речення, що пояснює, чому самих метаданих достатньо чи недостатньо для розслідування.
Додайте правила контролю шуму для малоцінних читань і системних компонентів, не придушуючи важливих для безпеки мутацій.
Визначте перші три дії того, хто реагує, для успішного читання Secret неочікуваним сервісним акаунтом.
Визначте перші три дії того, хто реагує, для сповіщення про шел середовища виконання, що відбувається протягом хвилин після аудит-події про виробничий exec.
Перевірте проєкт, переконавшись, що кожен результат навчання опрацьовано політикою, кроками реагування чи обома.

Розв'язання та міркування

Високопріоритетні ресурси — це ті, що або розкривають облікові дані, змінюють авторизацію, створюють виконання чи надають інтерактивний доступ. RequestResponse доречний для exec і змін RBAC, коли організація приймає компроміс щодо зберігання й чутливості, бо тим, хто реагує, потрібна повна деталізація про те, що змінилося чи який субресурс було використано. Request є розумним стандартом для операцій із Secret у цій навчальній політиці, але реальні організації мають бути обережними з повернутими даними й можуть віддавати перевагу метаданим для читань, водночас зберігаючи тіла запитів для створень і оновлень. Правила контролю шуму мають іти після високопріоритетних правил, щоб вони не поглинали чутливі події.

Дії того, хто реагує, мають переходити між рівнями. Для неочікуваного сервісного акаунта, що читає Secret, перевірте аудит-подію, поточний RBAC, власника пода, простір імен і нещодавні сповіщення середовища виконання чи мережі з того робочого навантаження. Для сповіщення про шел поблизу події exec збережіть докази, ідентифікуйте користувача й джерело, перевірте, чи був exec схвалений, і вирішіть, чи ізолювати под, чи відкликати облікові дані. Проєкт є повним лише тоді, коли докази можуть відповісти, хто діяв, якого об’єкта торкнулися, що запустилося після цього і як тим, хто реагує, слід діяти.

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # HIGH PRIORITY: Exec into pods - full detail
  - level: RequestResponse
    resources:
    - group: ""
      resources: ["pods/exec", "pods/attach", "pods/portforward"]

  # HIGH PRIORITY: All secret operations
  - level: Request
    resources:
    - group: ""
      resources: ["secrets"]

  # HIGH PRIORITY: RBAC changes - full detail
  - level: RequestResponse
    resources:
    - group: "rbac.authorization.k8s.io"
      resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
    verbs: ["create", "update", "patch", "delete"]

  # MEDIUM: Pod operations in production
  - level: Request
    resources:
    - group: ""
      resources: ["pods"]
    namespaces: ["production", "prod"]
    verbs: ["create", "update", "patch", "delete"]

  # MEDIUM: ServiceAccount operations
  - level: Request
    resources:
    - group: ""
      resources: ["serviceaccounts"]
    verbs: ["create", "update", "patch", "delete"]

  # LOW: Log metadata for remaining mutating operations
  - level: Metadata
    verbs: ["create", "update", "patch", "delete"]

  # MINIMAL: Skip logging for read-only operations on common resources
  - level: None
    resources:
    - group: ""
      resources: ["events", "endpoints"]

  - level: None
    users: ["system:kube-proxy"]

  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get", "list", "watch"]

  # DEFAULT: Metadata for everything else
  - level: Metadata
    omitStages:
    - "RequestReceived"

Критерії успіху:

Ваша політика логує субресурси exec, attach і port-forward перед будь-яким широким стандартним правилом.
Ваша політика логує мутації RBAC з достатньою деталізацією, щоб відновити змінену роль чи прив’язку.
Ваша політика записує доступ до Secret, явно визнаючи чутливість сховища аудит-логів.
Ваші правила контролю шуму не придушують мутацій подів, мутацій ServiceAccount чи змін привілейованих робочих навантажень.
Ваш робочий процес інцидентів корелює аудит-логи, сповіщення середовища виконання та мережеву телеметрію замість покладання на один сигнал.

Наступний модуль

Модуль 5.3: Безпека середовища виконання — примусове застосування політик безпеки під час виконання після того, як виявлення показує, що роблять робочі навантаження.

Джерела

Спостережуваність безпеки уможливлює виявлення загроз і реагування на інциденти:

Компонент	Призначення	Інструменти
Аудит-логи	Активність API	Вбудовано в Kubernetes
Моніторинг середовища виконання	Поведінка контейнерів	Falco, Tetragon
Агрегація логів	Централізований аналіз	ELK, Loki, Splunk
Сповіщення	Швидке реагування	PagerDuty, Slack