Un attaquant ouvre un shell dans un conteneur compromis, lit /etc/shadow, lance un binaire de cryptomining. Côté ops, la question n'est pas seulement de le voir dans un log une heure plus tard. C'est de tuer le process avant qu'il finisse son travail. La détection qui alerte sans bloquer laisse l'incident se dérouler ; il faut un cran de plus.
Tetragon fait ce cran. Projet CNCF issu d'Isovalent et de l'équipe Cilium, il observe l'activité d'un nœud Kubernetes via eBPF et peut intervenir directement dans le noyau : terminer un process, refuser un appel système. Pas un agent qui reçoit des événements et réagit trop tard. Le filtrage et le blocage se font in-kernel, là où l'événement se produit.
Ce que Tetragon voit
Tetragon s'accroche à des points du noyau via eBPF : kprobes, tracepoints, LSM hooks, uprobes pour l'espace utilisateur. À partir de là, il observe l'exécution de process, les accès fichiers, les connexions réseau (sockets, tentatives de connexion sortante), les changements de capabilities, l'usage des privilèges.
L'intérêt par rapport à un outil hôte classique : le contexte Kubernetes est attaché à chaque événement. Pas un PID nu et une ligne de commande, mais le pod, le namespace, les labels, l'image du conteneur, le workload. Quand un bash s'exécute dans un pod qui ne devrait faire tourner qu'un binaire applicatif, Tetragon le rapporte avec toute l'identité k8s. La corrélation se fait sans tâtonner.
En prod, ça donne ça : un événement process_exec enrichi qui dit quel binaire, quel parent, dans quel pod de quel namespace, lancé par quel utilisateur effectif. Lisible, exploitable, corrélable avec le reste de la supervision.
TracingPolicy : décrire ce qu'on surveille
La configuration passe par une custom resource Kubernetes, la TracingPolicy. On y déclare les points d'accroche (un kprobe sur une fonction noyau, un LSM hook), les arguments à extraire, les filtres (sur un namespace, un binaire, un chemin), et les actions à déclencher.
Un exemple concret : surveiller toute ouverture en lecture de /etc/shadow. La policy pose un hook sur l'appel concerné, filtre sur le chemin du fichier, et émet un événement quand un process y touche. On peut affiner sur le pod ou le namespace pour ne pas noyer le signal sous le bruit légitime.
La granularité est fine. On cible une fonction noyau précise, on extrait les arguments qui comptent, on filtre côté kernel pour réduire le volume remonté. Le travail d'écriture de policy demande de connaître les appels système et les fonctions noyau visées, comme une policy SELinux bien faite demande de connaître les types et les contextes. Pas de magie : c'est de la sécurité déclarative qui suppose qu'on sache ce qu'on surveille.
Enforcement in-kernel, pas seulement alerter
C'est la différence qui compte. Tetragon ne se contente pas d'émettre un événement, il peut agir. Deux mécanismes d'enforcement, in-kernel.
Le premier : override du retour d'une fonction. La fonction n'est jamais exécutée, une valeur (typiquement une erreur) est renvoyée à la place. L'opération est bloquée net. C'est le mode propre pour refuser un appel système ou une vérification de sécurité. Côté kernel, ça demande l'option CONFIG_BPF_KPROBE_OVERRIDE.
Le second : l'envoi d'un signal, par exemple SIGKILL, au process qui correspond aux critères. Le process est tué. Attention au piège classique : un SIGKILL pendant un write() ne garantit pas que l'écriture n'a pas eu lieu, il tue le process mais l'opération en cours peut être passée. Pour un blocage strict, l'override du retour est plus sûr que le signal. Les deux se combinent quand on veut à la fois refuser l'appel et terminer le process fautif.
La règle qu'on applique : alerte d'abord, enforcement ensuite, sur des cas précis et testés. Mettre une TracingPolicy en mode kill sur une signature trop large, c'est se garantir un incident de prod auto-infligé le jour où un process légitime tombe dans le filet. On observe, on valide la précision de la policy, puis on active le blocage.
Le surcoût eBPF
eBPF traite l'événement dans le noyau, sans renvoyer chaque syscall vers un agent en espace utilisateur qui le parse. Le filtrage et le blocage se font directement dans le kernel. Le surcoût mesuré reste sous 1 % selon les comparatifs 2026, contre 5 à 10 % pour une approche qui parse les syscalls en userspace.
Ce chiffre conditionne l'adoption. Un outil de runtime security à 10 % de CPU sur chaque nœud d'un cluster, c'est un coût d'infra que personne ne veut signer. Sous 1 %, l'enforcement devient déployable partout sans débat capacity planning. C'est l'argument eBPF de fond, le même que pour l'observabilité réseau Cilium : faire le travail dans le noyau plutôt que de copier des données vers l'espace utilisateur.
Intégration Cilium et Hubble
Tetragon vient de l'écosystème Cilium. Si le cluster tourne déjà sur Cilium pour le CNI, l'ajout de Tetragon s'inscrit dans la même logique eBPF, et les événements de sécurité remontent vers Hubble, l'observabilité du plan réseau Cilium. Une seule famille d'outils, une seule pile eBPF, des événements réseau et sécurité corrélés au même endroit.
Tetragon fonctionne aussi en standalone, sans Cilium. Mais le couplage est là, et il pèse dans le choix. Un cluster déjà sous Cilium qui veut de la runtime security n'a pas à chercher ailleurs.
Cas concrets
Détection de shell interactif dans un conteneur. Une TracingPolicy qui repère l'exec d'un shell (bash, sh) dans des pods applicatifs. Personne ne devrait ouvrir un shell dans un pod de production en marche. L'événement remonte, et en mode enforcement, le shell est tué à l'exec.
Lecture de fichiers sensibles. Hook sur l'accès à /etc/shadow, aux clés privées, aux secrets montés. On voit qui lit quoi, on bloque les accès non prévus.
Escalade de privilèges. Surveillance des changements de capabilities, des appels qui élèvent les droits. Un process applicatif qui tente soudain d'acquérir CAP_SYS_ADMIN est un signal fort.
Connexions réseau suspectes. Tentatives de connexion sortante vers des destinations non prévues, exfiltration, callback de C2. Tetragon voit les sockets et peut, là aussi, bloquer.
Tetragon ou Falco
Les deux sont CNCF, les deux tournent sur eBPF en 2026, et la comparaison est plus serrée qu'avant. Historiquement Falco se concentrait sur la détection d'anomalies comportementales en parsant les syscalls ; sa release 0.40 a fait du driver eBPF moderne le défaut et a fait baisser son empreinte CPU et mémoire. Tetragon, lui, a construit son modèle autour de l'enforcement in-kernel.
| Critère | Tetragon | Falco |
| Origine | Isovalent / Cilium | Sysdig |
| Approche | Observabilité + enforcement in-kernel | Détection d'anomalies, règles |
| Enforcement actif | Oui (override retour, SIGKILL) | Détection, réponse externe |
| Surcoût | Sous 1 % (eBPF kernel) | 5 à 10 % en parsing userspace historique, réduit en eBPF |
| Couplage | Écosystème Cilium / Hubble | Indépendant |
Le verdict ops : pour de la runtime security Kubernetes moderne, on part sur eBPF, pas sur du parsing userspace. Si le cluster tourne déjà sur Cilium, Tetragon est le choix naturel, l'enforcement in-kernel et la corrélation Hubble closent le sujet. Sur un cluster sans Cilium qui veut surtout de la détection avec un large catalogue de règles prêtes, Falco reste le meilleur point d'entrée. Et rien n'interdit les deux : Falco pour la détection large, Tetragon pour l'enforcement ciblé. La runtime security n'est qu'une couche : elle suppose des admission controllers en amont, type OPA Gatekeeper, et une centralisation des alertes côté SIEM Wazuh ou équivalent. Tetragon couvre le runtime, pas le reste de la chaîne.
Déployer Tetragon sur un cluster de prod et écrire des TracingPolicy justes, c'est un travail qui se cadre : choisir les hooks, valider la précision avant d'activer l'enforcement, brancher les événements sur la supervision existante. Une stack Kubernetes durcie de bout en bout, des admission controllers à la runtime security en passant par le réseau, c'est ce qu'on opère au quotidien sur les clusters qu'on gère. Si vous voulez de l'enforcement runtime sans vous offrir un incident auto-infligé, on peut poser et opérer la couche sécurité de votre cluster.
Sources
- Tetragon - Enforcement : les deux mécanismes d'enforcement (override du retour, signal), avec les limites du SIGKILL.
- Tetragon - TracingPolicy : référence de la custom resource, hooks kprobe/uprobe/tracepoint/LSM.
- Tetragon - Overview : modèle eBPF, filtrage et blocage in-kernel, contexte Kubernetes.
- cilium/tetragon (GitHub) : code source, prérequis noyau (CONFIG_BPF_KPROBE_OVERRIDE pour l'enforcement).
- Comparatif eBPF runtime security 2026 : positionnement Tetragon, Falco, Tracee et surcoût eBPF.
