eBPF-сенсори та 18-хвилинне вікно атаки на Kubernetes

Будь-який платформний лід, який хоч раз запускав свіжий AKS-кластер у п'ятницю ввечері, знайомий з цим відчуттям: ви ще не дописали NetworkPolicy, а боти вже стукають у двері. Вісімнадцять хвилин. Саме стільки — медіанний час до першого зондування AKS-кластера, згідно зі звітом Wiz. EKS отримує трохи більше — 28 хвилин. Обидва числа менші за час більшості передач чергування.

Цифри

Вісімнадцять хвилин — це недостатньо для будь-якої звичайної людської дії. Недостатньо, щоб як слід переглянути Terraform-план. Недостатньо, щоб обговорити в Slack, чи варто відкривати дашборд. І вже точно недостатньо, щоб запустити щотижневе сканування вразливостей, отримати PDF і передати його на тріаж команді безпеки.

Як повідомляє CyberSecurityNews, вікна у 18 хвилин для AKS і 28 хвилин для EKS взяті зі звіту Wiz Kubernetes Security Report, а десятихвилинна різниця між двома керованими сервісами майже напевно є шумом від патернів сканування ботів, а не реальною перевагою захисту EKS. Ставтеся до обох як до однієї й тієї самої проблеми: ваш кластер потрапляє до списку цілей ще до того, як CI-пайплайн завершує перший деплой.

Перекладемо це в операційні терміни. Якщо у вас команда з 10 платформних інженерів і хтось чергує на Kubernetes-провізіонінгу, вам тепер потрібне автоматизоване захисне налаштування, вбудоване в bootstrap кластера — бо людина-рецензент не встигне раніше за бота. Це реальна стаття бюджету. У виробничих інцидентах, які я спостерігав у фінтех-компаніях на керованому Kubernetes, кластер «захардимо після демо» — саме той, що в понеділок вранці майнить Monero.

Ще одна цифра, на яку варто звернути увагу: якісні runtime-інструменти виявляють загрози за секунди. Порівняйте це з 18-хвилинним вікном атаки — математика очевидна. Ви не можете обігнати автоматизованих зловмисників за допомогою ручних циклів перевірки. Потрібно скоротити виявлення до того ж порядку величини, що й автоматизація атакуючих, тобто до одиничних секунд.

Kubernetes за замовчуванням постачається з широкими дозволами, відкритими дашбордами і сервісними акаунтами з надлишковим доступом. Ця комбінація разом із публічною IP-адресою робить 18-хвилинні цифри відтворюваними, а не випадковими. Ботам не потрібен zero-day, коли вхідні двері незачинені.

Що справді нового

eBPF як такий не є новинкою. Extended Berkeley Packet Filter підключається до ядра Linux вже роками, а Falco, Tetragon і Cilium більшу частину цього часу постачають runtime-виявлення на його основі. Що змінилося — так це те, що прибічники безагентного підходу тепер інтегрують eBPF у свої платформи, замість того щоб вважати його конкуруючою категорією.

Wiz побудував свою репутацію на скануванні хмарних середовищ без розгортання агентів. Додавання Wiz Sensor як опціонального агентного доповнення до Wiz Defend — це реальне архітектурне визнання: ви не можете бачити in-memory-експлуатацію ззовні вузла. Статичне сканування перевіряє, що запаковано в образі контейнера, порівняно з відомими CVE. Воно нічого не говорить про те, що реально завантажено в пам'ять, коли контейнер запущений. Вразливий пакет, який ніколи не імпортується, — теоретична загроза. Бінарний файл, що виглядає нешкідливо, але використовується для латерального переміщення, — це вже реальна.

Wiz Sensor перевіряє вразливості щодо того, що завантажено в пам'ять, а не лише щодо того, що є на диску. Це справді корисна інженерна перевага, бо вона скорочує шумну чергу CVE, в якій тоне кожна команда безпеки. Половина того, що позначає ваш SBOM-сканер, — це код, який ніколи не виконується. Підтвердження досяжності в runtime — саме так ви перестаєте платити двом інженерам за погоню за примарними знахідками.

Ще одна відносно нова деталь: Wiz Runtime Sensor для Windows, випущений у червні, використовує легкий kernel-модуль, що підключається до Windows Security API і пересилає дані активності в user space, де виконується логіка виявлення. Обидва сенсори — Linux і Windows — звітують в одну платформу. Для тих, хто запускає гібридні кластери (а таких в enterprise iGaming і legacy-фінтеху більше, ніж вендори люблять визнавати), уніфікований телеметричний пайплайн — це реальний диференціатор, а не eBPF-брендинг.

Моя думка: головна новина тут не в тому, що «eBPF — це круто». eBPF був крутим ще з 2018 року. Головне в тому, що безагентні вендори тихо визнали необхідність агента для runtime і тепер поспішають його прикрутити, поки чисті runtime-інструменти не з'їли їхні доходи від розширення.

Що вже враховано командами безпеки

Якщо ви уважно стежили за безпекою Kubernetes останні три роки, більшість цього вже є у вашій моделі загроз. Ви вже знаєте, що конфігурації за замовчуванням небезпечні. Ви вже знаєте, що сервісні акаунти мають надлишкові дозволи, бо вузькі scope ламають усе, а в нікого немає часу налагоджувати RBAC у вівторок. Ви вже знаєте, що бінарні файли типу curl, bash і пакетні менеджери не можна усунути скануванням, бо ваш застосунок їх реально потребує. Команди, з якими я працював на платіжній інфраструктурі, роками відображають це на техніки MITRE ATT&CK для контейнерів.

Що ще не враховано — і саме тут я бачу, що команди досі потрапляють у пастку — це операційна вартість самого eBPF-агента. eBPF є Linux-специфічним. Він працює лише на Linux-вузлах. Це означає, що кожен Windows-вузол, кожен керований сервіс, що абстрагує вузол, кожен serverless-контейнерний runtime без доступу до ядра — це прогалина в покритті. Ваш дашборд буде зеленим, поки цілі фрагменти вашого флоту залишаються без моніторингу.

Незручна правда: більшість команд купують runtime-виявлення, розгортають його на Linux-пулах воркерів, якими вони керують, і мовчки ігнорують той факт, що їхні Windows-вузли, Fargate-задачі та GKE Autopilot-навантаження перебувають поза досяжністю сенсора. Випуск Windows-сенсора закриває одну з цих прогалин. Решта залишаються.

Контраргумент

Ось аргумент, з яким я б посперечався: що додавання eBPF-агента на кожен вузол — очевидно правильна відповідь. Це зовсім не очевидно. Агенти рівня ядра мають довгу історію спричинення збоїв, що перевищують інциденти, які вони мали запобігати. Хто пережив певний ранок у липні 2024 року, знає, що відбувається, коли kernel-модуль поводиться некоректно у промисловому масштабі.

eBPF безпечніший за сирий kernel-модуль, бо виконується у верифікованій пісочниці, але «безпечніший» — це не «безпечний». Кожен додатковий хук у syscalls, виконання процесів і мережеві шляхи — це CPU, що витрачається на спостереження, а не на обробку запитів. На навантаженнях із високою пропускною здатністю ці витрати реальні, і я бачив, як команди відкочували runtime-сенсори після бенчмаркінгу, що показав відчутний латентний податок на p99.

Контраргумент: для багатьох навантажень захист кластера на рівні провізіонінгу (обмежений RBAC, відсутність публічних дашбордів, admission-контролери, підписування образів) дає більше безпеки за долар, ніж додавання runtime-сенсора поверх погано налаштованого кластера. Runtime-виявлення — це те, що додають після виконання базових вимог, а не замість них.

Ключові висновки

• Вікна атаки у 18 хвилин для AKS і 28 хвилин для EKS означають, що захисне налаштування кластера має бути автоматизованим на рівні провізіонінгу, а не переглядатися людьми після цього.
• Статичне сканування образів не може бачити in-memory-експлуатацію або зловживання легітимними бінарними файлами типу curl, bash і пакетних менеджерів. Runtime-видимість — єдиний спосіб їх виявити.
• Сенсори на основі eBPF (Falco, Tetragon, Cilium, Wiz Sensor) закривають прогалину Linux runtime, але eBPF є тільки Linux-рішенням. Windows-вузли потребують окремого підходу на основі kernel-модуля.
• Перевірка вразливостей щодо того, що завантажено в пам'ять (а не що є на диску), — найкорисніша функція для скорочення шуму CVE-черги. Надавайте пріоритет інструментам, що це роблять.
• Перед тим як додавати агент рівня ядра на кожен вузол, заблокуйте налаштування за замовчуванням, обмежте сервісні акаунти та закрийте відкриті дашборди. Runtime-виявлення — це шар поверх базової гігієни, а не її заміна.