Falco vs Tetragon : comparés sur le même cluster

La différence décisive entre Falco et Tetragon tient en un mot : sur le même événement, Falco alerte, Tetragon bloque. Pour le prouver, les deux ont été déployés sur un même cluster k3d et soumis au même scénario : un processus qui lit /etc/shadow dans un pod. Cette page montre les sorties réelles de chacun, traite l'objection légitime de Falco Talon (qui ajoute la réponse à Falco), ajoute Tracee comme troisième voie, et vous aide à choisir. Cluster de test : k3d (k3s v1.31), Tetragon v1.7.0, Falco 0.44 et Falco Talon v0.3.0 installés par Helm.

Ce que vous allez apprendre

Voir Falco et Tetragon réagir au même scénario
Distinguer alerter et bloquer, preuve à l'appui
Comprendre pourquoi Falco + Talon n'égale pas Tetragon (prévention contre réaction)
Choisir rapidement selon votre besoin dominant
Savoir si les combiner a du sens

Recommandation rapide

Votre besoin dominant	L'outil
Empêcher une action interdite dans le noyau, avant qu'elle n'aboutisse	Tetragon
Détection mature, large écosystème de règles, standard CNCF	Falco
Remédier après détection (supprimer, isoler, notifier un pod)	Falco + Talon
Détection par signatures comportementales et forensic	Tracee
Corréler des événements à Kubernetes sans volet sécurité	Inspektor Gadget

La suite montre pourquoi, sur le même cluster.

Le scénario commun : lire un fichier sensible

Sur le cluster, un pod nommé victime (une image nginx) exécute la commande interdite :

kubectl exec victime -- cat /etc/shadow

Voyons comment chaque outil réagit exactement à cette même action.

Falco : il alerte

Falco compare l'événement à ses règles et émet une alerte. Sortie réelle de ses journaux :

Warning Sensitive file opened for reading by non-trusted program
  file=/etc/shadow  process=cat  command=cat /etc/shadow
  container_name=victime  container_image=docker.io/library/nginx
  k8s_pod_name=victime  k8s_ns_name=default

L'alerte est riche et immédiatement exploitable : le fichier, le processus, l'image du conteneur, le pod, l'espace de noms. Mais c'est une alerte : l'action a eu lieu, cat a bien lu /etc/shadow. Falco l'a vu et signalé, il ne l'a pas empêché.

Tetragon : il observe le même événement

Déployé sur le même cluster, Tetragon voit lui aussi l'exécution, avec le contexte du pod. Sortie réelle de tetra getevents :

process  default/victime  /usr/bin/cat /etc/shadow
exit     default/victime  /usr/bin/cat /etc/shadow 0

Jusque-là, c'est la même observation que Falco, sous une autre forme. La différence apparaît quand on demande à Tetragon d'agir.

Tetragon : il bloque

On applique une TracingPolicy qui associe l'accès à /etc/shadow à l'action Sigkill :

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: bloque-shadow
spec:
  kprobes:
  - call: "security_file_open"
    syscall: false
    args:
    - index: 0
      type: "file"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Equal"
        values:
        - "/etc/shadow"
      matchActions:
      - action: Sigkill

On relance alors exactement la même commande. Résultat réel :

kubectl exec victime -- cat /etc/shadow   # code retour = 137  (137 = tué par SIGKILL)
kubectl exec victime -- cat /etc/hostname # code retour = 0    (autorisé)

Le processus est tué avant d'avoir lu le fichier (code 137 = SIGKILL), tandis qu'un accès légitime (/etc/hostname) passe sans encombre : la politique est ciblée. Tetragon confirme l'action dans son flux :

process  default/victime  /usr/bin/cat /etc/shadow
exit     default/victime  /usr/bin/cat /etc/shadow SIGKILL

Voilà la démonstration : sur le même événement, Falco a écrit une ligne d'alerte, Tetragon a empêché l'accès. C'est toute la différence entre détecter et appliquer.

Et Falco Talon, alors ? Prévention contre réaction

Une objection légitime : Falco Talon permet à Falco d'agir, pas seulement d'alerter. Au premier abord, Falco + Talon ressemble alors à Tetragon. C'est ici que se joue la vraie distinction, et elle ne tient pas à « agir ou pas » mais à quand et où l'action a lieu.

Falco Talon (projet falcosecurity, v0.3.0) est un moteur de réponse. Il reçoit les alertes de Falco, via Falcosidekick en HTTP sur le port 2803, et exécute des actionners au niveau de l'API Kubernetes : kubernetes:terminate (supprimer le pod), kubernetes:label (le marquer comme suspect), et d'autres. On lui fournit une règle qui relie une règle Falco à une action :

- action: Terminate Pod
  actionner: kubernetes:terminate

- rule: Reagir sur lecture de fichier sensible
  match:
    rules:
      - Read sensitive file untrusted
  actions:
    - action: Terminate Pod

Reprenons le même scénario sur le même cluster. On relit /etc/shadow dans le pod victime. Résultat réel, capturé :

# 1. la lecture REUSSIT : le secret a bien ete lu
kubectl exec victime -- cat /etc/shadow    ->  lecture reussie

# 2. quelques secondes plus tard, le pod a disparu
kubectl get pod victime    ->  Error from server (NotFound): pods "victime" not found

Le journal de Talon confirme la chaîne complète, de l'événement à l'action :

event   "Read sensitive file untrusted"   file=/etc/shadow   k8s_pod_name=victime
match   rule="Reagir sur lecture de fichier sensible"
action  "Terminate Pod"   actionner=kubernetes:terminate   status=success
        output="the pod 'victime' in the namespace 'default' has been terminated"

Comparez maintenant avec Tetragon sur exactement le même scénario :

Sur `cat /etc/shadow`	Tetragon	Falco + Falco Talon
La lecture du fichier	échoue (SIGKILL, code 137)	réussit, le secret est lu
Le devenir du processus/pod	processus fautif tué à la source	pod supprimé ensuite
Couche d'action	noyau (eBPF), synchrone	API Kubernetes, asynchrone
Nature	prévention (avant l'action)	réaction (après l'action)

La nuance est décisive, et elle porte sur le moment de l'intervention. Tetragon empêche : l'appel système est bloqué dans le noyau, la lecture n'a jamais lieu. Falco + Talon remédie : la lecture a eu lieu, le secret doit être considéré comme compromis, mais le pod est supprimé ou isolé en quelques secondes pour couper la suite de l'attaque. La conséquence pratique est nette : après un déclenchement de Falco, la rotation du secret concerné n'est pas optionnelle.

Aucune approche n'est meilleure dans l'absolu. Contre une exfiltration instantanée, seule la prévention protège vraiment. Pour de la remédiation orchestrée (isoler un pod du réseau, le labelliser, notifier, agir sur plusieurs ressources d'un coup), Talon fait ce que Tetragon ne fait pas nativement. Gardez en tête la maturité : l'application in-kernel de Tetragon est éprouvée, tandis que Talon reste un projet jeune (v0.3.0).

Trois approches d'un même problème

Cette expérience éclaire les positionnements. Chaque outil répond à « que se passe-t-il d'anormal ? », mais pas au même endroit du cycle.

Falco : la détection par règles. Falco confronte le flux à un ensemble de règles. C'est la référence historique, un projet CNCF mûr avec une immense bibliothèque de règles communautaires. Il alerte ; la réponse (couper, isoler) se branche en aval.

Tracee : la détection par signatures. Tracee applique des signatures qui reconnaissent des techniques d'attaque (un programme qui détecte qu'on l'analyse, un exécutable déposé puis lancé). Fort ancrage forensic, mais lui aussi détecte et alerte.

Tetragon : l'application dans le noyau. Tetragon observe et applique : la TracingPolicy ci-dessus tue le processus dans le noyau. C'est le seul des trois à empêcher plutôt qu'à seulement signaler.

Comparatif détaillé

Critère	Falco	Tetragon	Tracee
Approche	Règles	Observation + blocage	Signatures
Peut bloquer une action	Non (réponse externe)	Oui (in-kernel)	Non
Moteur	Règles en espace utilisateur	Filtrage dans le noyau	Signatures
Maturité / adoption	Très élevée (CNCF)	Élevée (Cilium)	Élevée (Aqua)
Écosystème de règles	Le plus large	Politiques ciblées	Signatures fournies
Point fort	Détection éprouvée	Prévention	Forensic
Kubernetes	DaemonSet	DaemonSet	DaemonSet

Deux points ressortent du lab. Le blocage d'abord : Tetragon agit dans le noyau, avant que l'action n'aboutisse ; Falco et Tracee alertent, et la réponse dépend d'un maillon supplémentaire. L'écosystème ensuite : la force de Falco n'est pas que technique, c'est son corpus de règles prêtes à l'emploi, précieux quand on ne veut pas tout écrire.

Quel outil pour quel cas

Empêcher une action (interdire l'accès à un secret, tuer un processus qui dérive) : Tetragon, seul à appliquer dans le noyau. Le blocage se valide d'abord en observation pour ne pas casser un service.
Détection robuste et adoptée, un maximum de règles déjà écrites, un standard reconnu : Falco.
Investigation et détections orientées techniques d'attaque avec contexte forensic : Tracee.

Le choix dépend de votre posture. Une équipe qui débute gagne à commencer par Falco (détecter, comprendre) avant d'introduire du blocage avec Tetragon.

Peut-on les combiner ?

Oui, et c'est fréquent : détecter largement avec Falco ou Tracee, bloquer dans le noyau les cas précis et à fort risque avec Tetragon, et remédier au niveau orchestration (isoler, notifier) avec Falco + Talon. Trois postures complémentaires : visibilité étendue, prévention ciblée, remédiation automatisée.

À retenir

Falco alerte, Tetragon bloque : démontré sur le même cluster, le même cat /etc/shadow.
Falco : détection par règles, mature, standard CNCF, plus grand corpus communautaire.
Tetragon : seul à empêcher une action, dans le noyau, via une TracingPolicy (code 137, SIGKILL observé).
Falco + Talon remédie, Tetragon prévient : avec Talon, Falco agit, mais après coup (le secret est lu, puis le pod supprimé) ; Tetragon empêche l'action avant qu'elle n'aboutisse.
Tracee : détection par signatures et forensic.
Combiner détection large et blocage ciblé est cohérent, mais chaque couche a un coût.
Choisir selon le besoin dominant, pas empiler par défaut.

Prochaines étapes

Tetragon : observer et bloquer L'outil qui applique dans le noyau, en détail.

Tracee : détection par signatures L'approche forensic, avec une vraie détection capturée.

Falco : détection par règles La référence CNCF de la sécurité runtime.

Le hub eBPF La technologie commune aux trois outils.