Falco у Kubernetes: runtime-безпека контейнерів на eBPF та виявлення загроз у 2026 році
Falco це CNCF-проєкт для runtime-безпеки Kubernetes на eBPF. Розбираємо архітектуру, встановлення через Helm, написання правил і покриття MITRE ATT&CK у 2026 році.
Falco це open-source сенсор runtime-безпеки для контейнерів, Kubernetes і Linux-хостів: він читає системні виклики через eBPF і зіставляє їх з правилами у YAML. У 2026 році Falco лишається єдиним CNCF-проєктом статусу Graduated у категорії runtime security. Для мене, як для людини, яка тягне продакшн-кластери в проді вже років вісім, це означає одне: операційну зрілість, якої я вимагаю від будь-якого компонента в критичному шляху. Якщо у вас на голові питання «що зламається першим при компрометації контейнера», то саме Falco дає відповідь у реальному часі, а не в постмортемі.
Falco використовує сучасний CO-RE eBPF-драйвер (з версії 0.35+), тому не потребує компіляції модулів ядра і працює на Linux 5.8+ без DKMS-костилів.
Розгортання у Kubernetes це DaemonSet із привілейованим контейнером на кожному вузлі; політика PSA має бути privileged лише для namespace falco.
Стандартний набір правил (falco-rules 4.x) покриває понад 120 технік MITRE ATT&CK for Containers, зокрема T1611 (container escape) і T1610 (deploy container).
Falcosidekick це обов'язковий компаньйон: він конвертує JSON-події у Slack, PagerDuty, Loki, Elasticsearch, Prometheus і Kafka без написання скриптів.
У продакшн-кластері з ~200 подами реальне навантаження від Falco становить 3–6% CPU на вузол; головний тюнінг це outputs.rate та відключення шумних правил через enabled: false у користувацькому оверлеї.
Falco лише детектує. Для активного blocking-у потрібен Falco Talon або Tetragon (див. порівняльну таблицю нижче).
Що таке Falco і навіщо він потрібен у 2026 році
Якщо коротко, Falco це sensor рівня ядра. Він читає потік системних викликів (open, execve, connect, ptrace, setns і компанія) з ядра Linux, збагачує їх контейнерним контекстом (image, pod, namespace, container.id) і зіставляє з правилами, описаними у YAML. Коли правило спрацьовує, Falco генерує подію з рівнем важливості (від Emergency до Debug), яку далі можна відправити у stdout, файл, gRPC, HTTP або через компаньйон Falcosidekick у будь-який SIEM чи месенджер.
Історія проєкту коротка, але показова. Він зародився у Sysdig 2016 року, у 2018-му перейшов до CNCF як incubating, а в лютому 2024-го отримав статус Graduated. Це той самий рівень, що Kubernetes, Prometheus і etcd. Практично це означає, що жоден вендор не зможе вивернути ліцензію чи закрити код: Apache 2.0 назавжди.
Моя модель загроз для будь-якого багатоорендного Kubernetes-кластера завжди починається з одного питання: «якщо зловмисник отримав RCE в поді, що він зробить наступним?». Найчастіше це curl | sh для завантаження криптомайнера, спроба mount /proc/self/root для виходу з контейнера, або kubectl-виклик через service account. Falco бачить кожен із цих кроків, тому що вони перетинають межу ядра. Мережевий IDS на кшталт Suricata бачить лише трафік, а auditd з правилами MITRE ATT&CK дає лише хостові події без контейнерного контексту. Falco закриває саме цей проміжок.
Як Falco виявляє загрози: архітектура eBPF та правила
Архітектурно Falco складається з чотирьох рівнів. Найнижчий це драйвер, який захоплює системні виклики. Історично існували три варіанти: kernel module (kmod), legacy eBPF probe і сучасний CO-RE eBPF (Compile Once, Run Everywhere). З версії 0.35 стандартом є саме CO-RE, який використовує BTF (BPF Type Format) і не потребує заголовків ядра на цільовому хості. Це головна причина, чому Falco більше не «ламається після kernel update», як це було у 2020 році. (У мене на пам'яті кілька доволі болючих ночей саме з цього приводу.)
Другий рівень це libsinsp, бібліотека, що збагачує сирі syscall-и контекстом: PID у container.id у k8s.pod.name у k8s.ns.name. Саме тому в подіях Falco ви бачите не просто «execve /bin/sh», а «execve /bin/sh in pod webapp-abc123 in namespace prod». Різниця для дебагу колосальна.
Третій рівень це rules engine. Правила описані трьома блоками: lists (перевикористовувані масиви значень), macros (іменовані булеві вирази) і власне rules. Ось як виглядає канонічне правило виявлення оболонки у контейнері:
- rule: Terminal shell in container
desc: A shell was used as the entrypoint/exec point into a container
condition: >
spawned_process
and container
and shell_procs
and proc.tty != 0
and container_entrypoint
and not user_expected_terminal_shell_in_container_conditions
output: >
A shell was spawned in a container with an attached terminal
(user=%user.name user_loginuid=%user.loginuid %container.info
shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline terminal=%proc.tty)
priority: NOTICE
tags: [container, shell, mitre_execution, T1059]
Четвертий рівень це outputs. Falco вміє писати у stdout (JSON), файл, syslog, HTTP webhook, gRPC-стрім і programmatic-канали через плагіни. У продакшні ви майже ніколи не використовуєте вбудовані outputs напряму, весь трафік йде через Falcosidekick, про який детально нижче.
Встановлення Falco у Kubernetes через Helm
Канонічний спосіб це офіційний Helm chart з репозиторію falcosecurity. Мінімальний робочий сетап на кластері з Linux 5.8+ і BTF займає одну команду, але я завжди починаю з окремого namespace і явно виставленої PodSecurity Admission-мітки. Так у вас не з'явиться сюрпризу, коли кластерна політика раптом заблокує DaemonSet.
Щоб перевірити, що правила справді працюють, я завжди роблю навмисну «атаку» одразу після інсталяції. Це найкращий спосіб зловити конфігураційні помилки, поки вони ще не в проді. Я цим підходом років п'ять керуюсь і жодного разу не пожалкував:
# Створюємо тестовий под і викликаємо shell
kubectl run alpine-test --image=alpine --rm -it -- sh
# У Falco-логах негайно з'явиться подія "Terminal shell in container" з priority NOTICE
kubectl -n falco logs -l app.kubernetes.io/name=falco | grep "Terminal shell"
Falco vs Sysdig Secure vs Tetragon: що обрати
У 2026 році ринок runtime-безпеки контейнерів фактично тримається на трьох гравцях. Falco це відкритий CNCF-проєкт. Sysdig Secure це комерційна платформа тієї ж компанії, побудована навколо ядра Falco плюс власні модулі forensics, drift detection і CSPM. Tetragon від Isovalent (тепер Cisco) молодший, але суто eBPF-нативний конкурент, який виріс із Cilium.
Критерій
Falco
Sysdig Secure
Tetragon
Ліцензія
Apache 2.0
Комерційна
Apache 2.0
Драйвер
CO-RE eBPF / kmod
CO-RE eBPF
Тільки eBPF (LSM hooks)
Enforcement (kill)
Ні (тільки detect)
Так
Так, через SIGKILL action
Формат правил
YAML, декларативний
YAML + UI
TracingPolicy CRD
Kubernetes-нативність
DaemonSet + плагін
SaaS + агенти
CRD-first, як Cilium
Cloud-plane події
Так (плагіни)
Так
Ні
Мінімальне ядро
5.8+
5.8+
5.10+ (LSM BPF)
Ідеальний сценарій
Виявлення + SIEM
Регульовані середовища з SLA
Enforcement у Cilium-кластерах
Практично: якщо ви вже живете у Cilium і потрібне in-kernel enforcement, беріть Tetragon. Якщо потрібен SOC-2/PCI compliance із SLA і готові платити, Sysdig. У всіх інших випадках (а це приблизно 90% команд, з якими я працювала) Falco з Falcosidekick покриває задачу за нуль ліцензійних грошей і без залежності від вендора.
Написання власних правил Falco
Стандартний набір falco-rules добре покриває загальні техніки, але у кожному кластері є свій контекст: власні сервісні акаунти, свої образи, свої «дозволені винятки». Правила треба писати обережно, бо кожне неоптимальне правило додає CPU-навантаження на кожен syscall. Ось приклад правила, яке виявляє запис у чутливі каталоги, з whitelist для CI-раннера:
- list: sensitive_dirs
items: [/etc, /var/lib/kubelet, /root/.ssh, /var/run/secrets]
- macro: write_syscall
condition: (evt.type in (open, openat, openat2) and evt.is_open_write=true)
- rule: Write to sensitive directory
desc: An unauthorized process wrote to a sensitive path
condition: >
write_syscall
and fd.name pmatch (sensitive_dirs)
and container
and not proc.name in (kubelet, containerd-shim, runc)
and not container.image.repository startswith "ci-runner/"
output: >
Sensitive path written (user=%user.name path=%fd.name process=%proc.cmdline
container=%container.name image=%container.image.repository)
priority: WARNING
tags: [filesystem, mitre_persistence, T1547]
Три речі, які я перевіряю у кожному новому правилі перед мерджем: (1) чи є оператор not для очевидних системних процесів, (2) чи використано pmatch замість in для шляхів, і (3) чи додано тег MITRE ATT&CK. Останнє критично для кореляції в SIEM. Я на цьому свого часу обпеклася: пропустила теги в кількох кастомних правилах, і кореляція в Elastic просто пройшла повз. Далі правило валідується локально:
# Синтаксична перевірка
falcoctl artifact rules-validate ./my-rules.yaml
# Симуляція події на реальному хості
sudo falco --rules-file=./my-rules.yaml --validate
Відправка алертів: Falcosidekick, Slack і Prometheus
Голий Falco пише JSON у stdout. Це чудово для контейнерного логера, але жахливо для інциденту о 3-й ночі. Falcosidekick вирішує це: він приймає webhook від Falco і маршрутизує події у 60+ бекендів (Slack, Teams, PagerDuty, Loki, Elasticsearch, S3, Kafka, GCP Pub/Sub, AWS SNS і так далі).
Мінімальна production-конфігурація, яку я ставлю в кожному кластері, це три бекенди: Slack для інформування, Prometheus для метрик і Loki для довгого зберігання. Ось приклад values.yaml для Helm:
Далі підключіть ServiceMonitor для Prometheus, щоб рахувати falcosecurity_falcosidekick_falco_events_total по priority. Це дає базу для двох критичних алертів у Alertmanager: сплеск подій рівня CRITICAL і повне мовчання Falco (можлива компрометація сенсора). Такий підхід перегукується з моделлю колаборативного захисту, яку я описувала в огляді CrowdSec як альтернативи Fail2ban: сенсор без надійного каналу доставки це просто лог-файл, який ніхто не читає.
Виявлення container escape та MITRE ATT&CK покриття
Container escape (MITRE T1611) це найгірший сценарій у моїй моделі загроз для Kubernetes. Атакуючий вийшов з контейнера на хост і тепер має доступ до kubelet-credentials, до інших подів, до nodeport-сервісів. Falco з коробки має 5 правил, які покривають найпоширеніші вектори:
Launch Privileged Container: под із securityContext.privileged: true або hostPID.
Mount Launched in Privileged Container: виклик mount усередині контейнера (типова спроба змонтувати host filesystem).
Change thread namespace: виклик setns із виходом у namespace init-процесу.
Read sensitive file untrusted: читання /etc/shadow, /proc/self/environ або токенів service account з несподіваного процесу.
Container Drift Detected (open+create): новий бінарник створений і виконаний у контейнері після запуску, класична ознака dropper-у.
Кожне з цих правил має тег MITRE (наприклад T1611, T1610, T1543), що дозволяє одразу мапити події на матрицю MITRE ATT&CK for Containers у SIEM. Я раджу періодично проганяти по кластеру офіційний тестовий образ falcosecurity/event-generator, який навмисно генерує події для всіх наявних правил. Це швидка перевірка того, що ланцюжок «сенсор → sidekick → Slack» дійсно працює end-to-end.
kubectl run event-generator --image=falcosecurity/event-generator \
--rm -it -- run syscall --loop --sleep 5s
Falco у продакшн: продуктивність і поширені помилки
На кластері з ~200 подами на вузлі накладні витрати від Falco становлять у середньому 3–6% CPU і 200–400 МБ RAM. Це прийнятно, але тільки якщо ви розумієте, звідки береться навантаження. Три головні джерела, які я бачу під час аудитів:
Шумні правила без exception-списків. Правило Write below etc у типовому Ubuntu-контейнері спрацьовує на кожен apt update. Рішення: додати виняток для очікуваних процесів через файл falco_rules.local.yaml, не редагуючи stock rules.
Output rate-limit не встановлено. У falco.yaml обов'язково має бути outputs: rate: 1 max_burst: 1000, інакше під час storm-у подій ви покладете Slack-webhook і втратите критичні алерти.
Драйвер kmod у 2026 році. Якщо ви бачите driver.kind: kmod, це знак, що конфіг перенесли з 2021-го. CO-RE eBPF швидший, безпечніший і не ламається після kernel-upgrade.
Ще одна пастка це багатоядерне ядро з увімкненим kernel lockdown. У режимі integrity завантаження неверифікованого модуля блокується, тому kmod-драйвер просто не стартує. Це поширена ситуація у RHEL 9/10 з SecureBoot; вирішення знову ж таки CO-RE eBPF, який не потребує завантаження модулів. Ця тема добре перегукується з хардненінгом Ubuntu 24.04 через AppArmor: обидва інструменти працюють у різних площинах (MAC vs runtime detection), але залежать від сучасних kernel security features.
З точки зору радіуса ураження (blast radius) Falco це сенсор, а не enforcement. Якщо ви хочете вбивати підозрілі процеси автоматично, ви або переходите на Tetragon, або ставите поруч Falco Talon, response engine, який слухає gRPC-стрім Falco і виконує kubectl-дії (kill pod, cordon node, apply NetworkPolicy). Але я завжди раджу починати саме з детекції. У 100% кластерів, які я аудитую, перші два тижні Falco приносять понад 50 «сюрпризів», про які команда не знала, і жодне enforcement-рішення не має сенсу до того, як ви наведете лад у своїх власних процесах.
Часті питання
Чим Falco відрізняється від Sysdig Secure?
Falco це open-source CNCF-проєкт із детекцією подій рівня ядра та вивантаженням JSON. Sysdig Secure це комерційна платформа тієї ж компанії, яка використовує Falco як сенсор, але додає централізований UI, forensics, compliance-звіти (PCI, HIPAA), CSPM і SLA-підтримку. Для більшості команд без регуляторних вимог функціоналу Falco плюс Falcosidekick цілком достатньо.
Чи потрібен привілейований контейнер для Falco?
Так. Falco DaemonSet вимагає hostPID, доступ до /proc, /sys/kernel/debug та capability CAP_SYS_ADMIN, бо він завантажує eBPF-програму у ядро та читає системні виклики. Тому namespace, у якому він працює, має мати мітку PodSecurity Admission enforce=privileged, але ЛИШЕ цей namespace, не весь кластер.
Чи впливає Falco на продуктивність контейнерів?
Так, але помірно. На вузлі зі 100–200 подами модерн-eBPF-драйвер додає 3–6% CPU і близько 300 МБ RAM на процес Falco. Основне джерело витрат це шумні правила з великою кількістю виключень. Правильне налаштування outputs.rate і додавання exception-списків у falco_rules.local.yaml знижують навантаження ще на 30–40%.
Чи може Falco блокувати атаки, а не лише виявляти їх?
Ні, класичний Falco лише виявляє. Для активної реакції потрібен окремий компонент, Falco Talon, який слухає gRPC-потік подій і виконує дії у Kubernetes (kill pod, cordon node, застосування NetworkPolicy). Альтернативно, Tetragon від Isovalent робить in-kernel enforcement напряму через LSM BPF hooks.
Яку версію ядра Linux вимагає Falco 0.39 у 2026 році?
Для модерн-eBPF-драйвера (CO-RE) потрібне ядро 5.8+ з увімкненою підтримкою BTF (CONFIG_DEBUG_INFO_BTF=y). Це стандарт для Ubuntu 22.04/24.04, RHEL 9/10, Amazon Linux 2023 і всіх свіжих managed Kubernetes-дистрибутивів (EKS, GKE, AKS). Для старіших ядер лишається legacy eBPF або kmod-драйвер, але цей шлях не рекомендується.
