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, ajoute Tracee comme troisième voie, et vous aide à choisir. Cluster de test : k3d (k3s v1.31), Tetragon v1.7.0 et Falco 0.44 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
Choisir rapidement selon votre besoin dominant
Savoir si les combiner a du sens

Recommandation rapide

Votre besoin dominant	L'outil
Bloquer une action interdite, pas seulement la voir	Tetragon
Détection mature, large écosystème de règles, standard CNCF	Falco
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.

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 des cas précis et à fort risque avec Tetragon. Une couche de visibilité étendue, une couche d'application ciblé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é).
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.