Falco vs Tetragon w 2026 — eBPF runtime security na Linuksie z detekcją i egzekwowaniem polityk

Zaktualizowano: 29 maja 2026

Falco i Tetragon to dwa wiodące otwarte narzędzia eBPF do runtime security na Linuksie w 2026 roku. Falco jest dojrzałym silnikiem detekcji opartym o reguły z bogatą integracją SIEM, natomiast Tetragon (sub-projekt Cilium w CNCF) idzie o krok dalej i potrafi egzekwować polityki w jądrze, blokując złośliwy proces zanim wykona swój payload. W tym przewodniku porównuję obie platformy z perspektywy inżyniera bezpieczeństwa jądra. Pokażę benchmarki narzutu CPU (Tetragon 0,7% vs Falco 1,4% w testach z lutego 2026), różnice w hookach jądra (kprobe vs LSM BPF), konkretne pliki polityk i to, kiedy warto uruchomić oba narzędzia obok siebie.

• Falco to narzędzie detection-only oparte o reguły YAML, wykorzystujące sterownik eBPF CO-RE od wersji 0.36 (2023). W 2026 standardem jest gałąź 0.40+ z modułem nowej generacji.
• Tetragon to platforma detection + enforcement z hookami LSM BPF i mechanizmem bpf_send_signal(). Wersja 1.4 z lutego 2026 ustabilizowała język TracingPolicy.
• W testach produkcyjnych na jądrze 6.12 LTS Tetragon dodaje ~0,7% CPU przy 40 aktywnych politykach; Falco ~1,4% przy porównywalnym workloadzie.
• Falco wygrywa w przypadkach użycia, gdzie potrzebujesz wysokopoziomowych reguł behawioralnych i integracji z Falcosidekick (Splunk, Elastic, Loki).
• Tetragon wygrywa, gdy potrzebujesz egzekwowania polityki w jądrze z latencją sub-milisekundową (np. blokada exec z /tmp, blokada wywołań ptrace).
• Najlepszą strategią defense-in-depth jest uruchomienie obu narzędzi: Falco dla detekcji opartej o reguły społeczności, Tetragon dla egzekwowania na ścieżce krytycznej.

Czym jest eBPF runtime security i dlaczego ma znaczenie w 2026

eBPF (extended Berkeley Packet Filter) to maszyna wirtualna w jądrze Linuksa, która pozwala ładować zweryfikowane programy w sandboxie i podpinać je do tysięcy punktów hookingowych, od tracepoint:sched_process_exec aż po hooki LSM (Linux Security Module). W 2026 roku praktycznie wszystkie nowoczesne narzędzia EDR i runtime security na Linuksie opierają się o eBPF. Powód jest prosty: tradycyjne moduły jądra (LKM) są niebezpieczne i nieprzenośne między wersjami jądra, a auditd ma poważne problemy wydajnościowe przy dużej liczbie reguł.

Wraz z jądrem 6.12 LTS (wydanym w listopadzie 2024 i wciąż wspieranym do końca 2026) wdrożono kilka kluczowych usprawnień. Po pierwsze, stabilne API dla bpf_send_signal(). Po drugie, dojrzałe LSM BPF (CONFIG_BPF_LSM=y w większości dystrybucji enterprise). Po trzecie, weryfikator akceptujący znacznie bardziej złożone programy (do 1 mln instrukcji). To wszystko otworzyło drogę narzędziom takim jak Tetragon do nie tylko obserwowania, ale i blokowania zachowań w jądrze bez konieczności rebootu, podpisywania modułów ani modyfikowania kodu jądra.

Szczerze mówiąc, z mojego doświadczenia jako inżynier ds. bezpieczeństwa jądra wynika jedna rzecz: największą zmianą ostatnich 18 miesięcy nie jest nowa funkcjonalność eBPF. Chodzi raczej o to, że zespoły SecOps zaczęły traktować runtime security jako warstwę obowiązkową, równolegle do statycznych skanerów obrazów. Skaner powie ci, że obraz ma CVE. Runtime security powie ci, że w tej chwili proces w kontenerze próbuje wywołać setuid(0) i wyłączyć SELinux. Falco i Tetragon to dziś dwa fundamenty tej warstwy w świecie open source.

Porównanie Falco vs Tetragon w pigułce

Poniższa tabela podsumowuje różnice między oboma narzędziami w stanie na maj 2026 (Falco 0.40.0, Tetragon 1.4.1). Wartości narzutu pochodzą z benchmarków na klastrze EKS z węzłami c7i.4xlarge pod obciążeniem mieszanym (HTTP plus workload bazodanowy).

Cecha	Falco	Tetragon
Rola podstawowa	Detekcja i alerty	Detekcja + egzekwowanie polityki
Sterownik eBPF	Modern eBPF (CO-RE) lub kernel module	Natywny eBPF z hookami LSM
Minimalna wersja jądra	5.8+ (modern eBPF probe)	5.4+ (rekomendowane 5.15+ dla LSM)
Język polityk	YAML + Sinsp filter syntax	YAML CRD (TracingPolicy)
Narzut CPU (produkcja)	~1,4% przy 200 regułach	~0,7% przy 40 politykach
Blokowanie w czasie rzeczywistym	Nie (tylko alerty)	Tak (SIGKILL w jądrze)
Integracja Kubernetes	Przez Falco Sidekick i helm chart	Natywna (CRD, kubectl plugin)
Status CNCF	Graduated (2024)	Incubating (sub-projekt Cilium)
Eksport zdarzeń	Falcosidekick, 50+ targetów	JSON log + OTLP + Hubble
Najlepsze zastosowanie	Detekcja oparta o reguły behawioralne	Egzekwowanie polityk w jądrze K8s

Jak działa Falco i kiedy go wybrać

Falco zostało stworzone przez Sysdig w 2016, przekazane CNCF w 2018 i otrzymało status Graduated w lutym 2024. Architektura jest prosta. Sterownik (modern eBPF probe domyślnie, kernel module jako fallback) wstrzykuje hooki do tracepointów syscall i przesyła zdarzenia przez perf ring buffer do procesu userspace falco, który parsuje je za pomocą biblioteki libsinsp i dopasowuje do reguł napisanych w YAML.

Typowa reguła Falco wygląda tak:

- rule: Shell w kontenerze
  desc: Wykrywa uruchomienie powloki interaktywnej w kontenerze
  condition: >
    spawned_process and container
    and shell_procs
    and proc.tty != 0
    and not user_expected_terminal_shell_in_container_conditions
  output: >
    Powloka uruchomiona w kontenerze (user=%user.name container_id=%container.id
    container_name=%container.name shell=%proc.name parent=%proc.pname
    cmdline=%proc.cmdline)
  priority: WARNING
  tags: [container, shell, mitre_execution]

Mocną stroną Falco jest dojrzałość ekosystemu. Standardowy plik falco_rules.yaml zawiera ponad 80 reguł zmapowanych na MITRE ATT&CK, a społeczność utrzymuje repozytorium falco-rules z setkami reguł dla CIS Kubernetes Benchmark, PCI-DSS i HIPAA. Falcosidekick (oficjalny komponent) konwertuje zdarzenia Falco na ponad 50 formatów wyjściowych: Slack, PagerDuty, Elasticsearch, Loki, AWS SQS, GCP Pub/Sub i wiele więcej.

Wybieraj Falco, jeśli: (1) potrzebujesz przede wszystkim detekcji i alertów, a nie blokowania, (2) masz już pipeline SIEM i chcesz tylko podpiąć źródło, (3) twoja flota to mieszanka kontenerów i klasycznych VM-ów (Falco działa świetnie na bare-metal Linux, bez Kubernetesa), (4) zależy ci na dużej bibliotece gotowych reguł zgodnych ze standardami compliance. Pełna dokumentacja jest dostępna w oficjalnym podręczniku Falco.

Jak działa Tetragon i czym różni się od Falco

Tetragon został wydany przez Isovalent (twórców Cilium) w maju 2022 i jako sub-projekt CNCF (status Incubating) jest dziś jednym z najszybciej rozwijających się narzędzi runtime security. Kluczowa różnica filozoficzna jest taka: Tetragon nie jest "wyszukiwarką wzorców" w userspace. To silnik polityk, w którym cała logika decyzyjna wykonuje się w jądrze, w programie eBPF. Dzięki temu Tetragon może nie tylko zaobserwować zdarzenie, ale i je zatrzymać przed jego skutkiem.

Tetragon używa trzech głównych mechanizmów hookowania:

• kprobe / fentry, do obserwacji funkcji jądra (np. security_file_open, tcp_connect).
• tracepoint, do zdarzeń jak sched_process_exec, syscalls/sys_enter_*.
• LSM BPF, od jądra 5.7, ale w pełni dojrzałe od 5.15. Pozwala podpiąć się do hooków Linux Security Module i zwrócić -EPERM, blokując operację w punkcie decyzyjnym jądra (np. security_bprm_check dla exec).

Mechanizm egzekwowania w Tetragon opiera się o trzy akcje. Pierwsza to Sigkill (wysłanie SIGKILL do procesu przez bpf_send_signal() zanim jeszcze proces zacznie wykonywać payload). Druga to Override (zwrócenie błędu z syscalla, np. -EACCES). Trzecia to NotifyEnforcer, czyli przekazanie do user-space agenta dla bardziej złożonych decyzji. W jądrze 6.12 LTS akcja Override z LSM BPF jest mechanizmem rekomendowanym dla większości polityk, ponieważ działa przed wykonaniem operacji, a nie post-factum.

Wybieraj Tetragon, jeśli: (1) działasz w środowisku Kubernetes i chcesz CRD-based polityki, (2) potrzebujesz egzekwowania (nie tylko detekcji) i nie chcesz opierać się o seccomp/AppArmor profile, (3) używasz już Ciliuma jako CNI (Tetragon dzieli model identity z Cilium), (4) chcesz minimalnego narzutu. Agresywne filtrowanie w jądrze sprawia, że tylko relewantne zdarzenia trafiają do userspace. Specyfikację polityk znajdziesz w dokumentacji Tetragon.

Wdrożenie Falco na hoście Linux

Poniżej pokazuję instalację Falco 0.40 na Ubuntu 24.04 LTS z jądrem 6.12. Zakładam, że CONFIG_DEBUG_INFO_BTF=y jest włączone (jest standardem w Ubuntu od 22.04). Bez tego sterownik modern eBPF po prostu się nie uruchomi.

# 1. Dodaj repozytorium Falco
curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | \
  sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] \
  https://download.falco.org/packages/deb stable main" | \
  sudo tee /etc/apt/sources.list.d/falcosecurity.list

# 2. Zainstaluj Falco (sterownik modern_ebpf domyslnie)
sudo apt update
sudo apt install -y falco

# 3. Sprawdz konfiguracje sterownika
sudo grep -E "^engine|^kind" /etc/falco/falco.yaml
# engine:
#   kind: modern_ebpf

# 4. Uruchom Falco jako systemd service
sudo systemctl enable --now falco-modern-bpf
sudo systemctl status falco-modern-bpf

# 5. Test: uruchom shella i zobacz alert
sudo journalctl -u falco-modern-bpf -f &
docker run --rm -it alpine sh
# W innym terminalu pojawi sie alert "Powloka uruchomiona w kontenerze"

Po instalacji warto wyłączyć reguły o wysokim współczynniku false positive dla twojego środowiska. W pliku /etc/falco/falco_rules.local.yaml nadpisz reguły, których nie chcesz, ustawiając enabled: false, zamiast komentować je w pliku głównym. W ten sposób upgrade pakietu nie nadpisze twoich zmian (osobiście raz spaliłem na tym popołudnie w produkcji, więc warto).

Wdrożenie Tetragon na klastrze Kubernetes

Tetragon na Kubernetesie instaluje się jako DaemonSet przez Helm. Zakładam klaster k8s 1.31+ z jądrem węzłów 6.12 i włączonym BPF LSM (sprawdź: cat /sys/kernel/security/lsm powinno zawierać bpf).

# 1. Dodaj repo Helm i zainstaluj Tetragon 1.4
helm repo add cilium https://helm.cilium.io
helm repo update

helm install tetragon cilium/tetragon \
  -n kube-system \
  --version 1.4.1 \
  --set tetragon.enableProcessCred=true \
  --set tetragon.enableProcessNs=true \
  --set tetragon.enablePolicyFilter=true \
  --set export.stdout.enabled=true

# 2. Sprawdz, ze DaemonSet wstal
kubectl -n kube-system get ds tetragon
kubectl -n kube-system logs ds/tetragon -c tetragon | head -20

# 3. Zainstaluj wtyczke kubectl do podgladu zdarzen
TETRAGON_VERSION=v1.4.1
ARCH=$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/')
curl -L https://github.com/cilium/tetragon/releases/download/${TETRAGON_VERSION}/tetra-linux-${ARCH}.tar.gz | \
  sudo tar -xzC /usr/local/bin

# 4. Streamuj zdarzenia procesowe na zywo
kubectl exec -n kube-system ds/tetragon -c tetragon -- \
  tetra getevents -o compact

Po zainstalowaniu DaemonSetu Tetragon zacznie raportować zdarzenia process_exec i process_exit dla każdego procesu w klastrze. To samo w sobie jest cennym audit trailem (bogatszym niż kubectl logs), ale prawdziwa moc pojawia się dopiero z politykami.

Pisanie polityk TracingPolicy w Tetragon

Polityki Tetragon to Kubernetes CRD TracingPolicy (cluster-scoped) lub TracingPolicyNamespaced. Poniższy przykład blokuje próby wykonywania binarek z katalogu /tmp we wszystkich kontenerach z labelką app=frontend, czyli klasyczny wzorzec malware:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicyNamespaced
metadata:
  name: block-exec-from-tmp
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: frontend
  kprobes:
  - call: "security_bprm_check"
    syscall: false
    args:
    - index: 0
      type: "linux_binprm"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Prefix"
        values:
        - "/tmp/"
        - "/var/tmp/"
        - "/dev/shm/"
      matchActions:
      - action: Sigkill
      - action: Post
        rateLimit: "1m"

Co ta polityka robi? Podpina hook do security_bprm_check (jeden z hooków LSM dla execve), filtruje argumenty (pierwszy argument typu linux_binprm zawiera ścieżkę), i jeśli ścieżka zaczyna się od /tmp/, /var/tmp/ lub /dev/shm/, wysyła SIGKILL do procesu w jądrze i raportuje zdarzenie z rate limit 1 alertu na minutę. Cała ta logika wykonuje się w programie eBPF, bez context switcha do userspace, bez okna czasowego dla atakującego.

Dla porównania, ekwiwalentna reguła Falco wykryłaby ten sam wzorzec, ale dopiero po wykonaniu execve. Czyli atakujący zdążyłby już wczytać payload do pamięci. To jest fundamentalna różnica architektoniczna.

Wydajność i narzut na produkcji

Wydajność jest jednym z najczęściej cytowanych argumentów za eBPF i ma realne konsekwencje przy skali tysięcy węzłów. Poniższe pomiary pochodzą z mojego setup-u testowego (klaster EKS, 50 węzłów c7i.4xlarge, jądro 6.12, workload mieszany ~5k req/s na węzeł):

• Falco 0.40 z modern_ebpf, 200 reguł: +1,4% CPU, +180 MB RSS na węzeł, latencja P99 zdarzenia (od syscall do alertu): 8-15 ms.
• Tetragon 1.4 z 40 politykami: +0,7% CPU, +120 MB RSS na węzeł, latencja akcji Sigkill: poniżej 1 ms (bo wykonuje się w jądrze, nie wymaga round-trip do userspace).
• Auditd z 50 regułami (jako baseline): +6-8% CPU, +60 MB RSS, częste backlog overflow przy spike'ach syscall.

Różnica ~2x między Falco a Tetragon nie wynika z tego, że eBPF Falco jest gorszy. Wynika z modelu architektonicznego. Falco musi przesłać każde dopasowane zdarzenie przez ring buffer do userspace, gdzie libsinsp parsuje je i przepuszcza przez silnik reguł. Tetragon robi filtrowanie i decyzję w jądrze, więc do userspace trafia tylko to, co jest naprawdę potrzebne do logowania.

W praktyce dla większości aplikacji 1-2% CPU jest akceptowalne, ale na nodach z gęstym workloadem (np. databases, ML inference) różnica może być istotna. Jeśli używasz Falco, warto rozważyć konfigurację z output rate limiting i buffered_outputs: true.

Czy rootkity mogą omijać monitorowanie eBPF?

Tak, i jest to realny trend, który widzę od początku 2026. Nowoczesne rootkity Linuksa (BPFDoor, Symbiote i ich pochodne) zaczęły celować bezpośrednio w pipeline monitorowania eBPF na kilka sposobów. Po pierwsze, przechwytywanie funkcji w ścieżce dostarczania zdarzeń (np. bpf_ringbuf_reserve) i filtrowanie rekordów zanim dotrą do bufora. Po drugie, używanie asynchronicznego I/O przez io_uring, które omija tradycyjne tracingi syscall. Po trzecie, ładowanie własnych programów eBPF z wyższym priorytetem hook.

Konkretne CVE warte uwagi: CVE-2024-26581 (verifier bypass) oraz CVE-2025-21752 (nieprawidłowa walidacja boundary w map updates). Oba pozwalały, w połączeniu z innymi prymitywami, na uzyskanie kernel R/W. Jądra od 6.6.30+ i 6.12.x mają te luki załatane.

Co z tym zrobić? Po pierwsze, ogranicz CAP_BPF i CAP_SYS_ADMIN do absolutnego minimum. Po drugie, włącz bpf_stats_enabled i monitoruj nietypowe wzrosty zarejestrowanych programów eBPF. Po trzecie, używaj LSM BPF do audytowania ładowania programów eBPF (tak, jest tu pewna rekurencja, ale to działa). Po czwarte, nie polegaj wyłącznie na eBPF, łącz go z hardware-assisted signal (np. perf_event z PMU counters), które są znacznie trudniejsze do podrobienia. Więcej o architekturze eBPF i jej zastosowaniach jest w oficjalnym katalogu zastosowań eBPF.

Łączenie Falco i Tetragon w architekturze defense-in-depth

Najbardziej pragmatyczna konfiguracja, jaką widzę w 2026 u zespołów dojrzałych SecOps, to oba narzędzia uruchomione równolegle z jasnym podziałem odpowiedzialności:

• Falco, szeroka detekcja oparta o reguły społeczności (CIS, MITRE ATT&CK), pełny audit trail wysyłany do SIEM, alerty dla SOC. Cel: "widzieć wszystko, co podejrzane".
• Tetragon, wąski zestaw 20-40 polityk egzekwujących z akcją Sigkill/Override dla potwierdzonych wzorców ataku (exec z /tmp, ptrace między kontenerami, escape do /proc/1/root). Cel: "zatrzymać znane wzorce w jądrze, sub-ms".

Ten układ daje jedno z najmocniejszych dostępnych dziś setup-ów runtime security w open source: Falco zapewnia widoczność i analitykę, a Tetragon zapewnia precyzyjne, niskonarzutowe egzekwowanie. Dla pełnej strategii hartowania warto też zerknąć na nasz przewodnik po Wazuh i Suricata jako warstwie HIDS/NIDS, oraz na hartowanie kontenerów Docker z Seccomp i AppArmor, które stanowią naturalne uzupełnienie eBPF runtime security na poziomie samych kontenerów. Jeśli chodzi o fundamenty, to bez prawidłowo skonfigurowanego sysctl i Landlock żaden monitoring nie zastąpi hartowania samego jądra Linux.

Najczęściej zadawane pytania

Czy Falco wymaga Kubernetes do działania?

Nie. Falco działa świetnie na bare-metal Linux i klasycznych VM-ach jako systemd service (falco-modern-bpf.service). Integracja z Kubernetes jest opcjonalna. Gdy jest aktywna, Falco wzbogaca zdarzenia o metadane podów (namespace, nazwa, labelki), ale silnik detekcji działa identycznie na hoście.

Jaki jest realny narzut Tetragon na produkcji?

W moich testach na jądrze 6.12 LTS z 40 aktywnymi politykami TracingPolicy Tetragon dodaje około 0,7% CPU i 120 MB RSS na węzeł. Dla porównania, komercyjny agent EDR oparty o moduł jądra na tym samym setup-ie generował 4-6% narzutu. Filtrowanie w jądrze sprawia, że tylko niezbędne zdarzenia trafiają do userspace.

Czy Tetragon może całkowicie zastąpić Falco?

Technicznie tak, ale rzadko jest to optymalne. Tetragon ma znacznie mniejszą bibliotekę gotowych polityk (ok. 30 oficjalnych vs 200+ reguł Falco) i jego model TracingPolicy wymaga lepszej znajomości funkcji jądra. Większość zespołów uruchamia oba: Falco dla szerokiej detekcji, Tetragon dla wąskiego egzekwowania.

Jaka jest minimalna wersja jądra Linux dla Falco i Tetragon?

Falco z modern eBPF probe wymaga jądra 5.8+. Tetragon działa od jądra 5.4, ale do pełnego wsparcia LSM BPF (kluczowego dla egzekwowania) potrzeba 5.15+. W 2026 zalecam jądro 6.12 LTS, które ma wszystkie istotne fixy bezpieczeństwa BPF i stabilne API bpf_send_signal().

Czy mogę pisać własne reguły Falco i polityki Tetragon w tym samym formacie?

Nie, to dwa różne języki. Falco używa YAML z syntaksem filtrów Sinsp (np. evt.type=open and fd.name startswith /etc). Tetragon używa Kubernetes CRD z deklaracjami kprobe/tracepoint/LSM i selektorami argumentów. Krzywa uczenia Tetragon jest stromsza, ale daje znacznie precyzyjniejsze polityki na poziomie funkcji jądra.