Tetragon : détection et blocage in-kernel avec eBPF

Tetragon ne se contente pas d'observer et d'alerter : il peut bloquer une action interdite directement dans le noyau, avant qu'elle n'aboutisse. C'est ce qui le distingue des outils de détection comme Tracee ou Falco, qui signalent après coup. Construit sur eBPF par l'équipe Cilium, Tetragon observe les processus et le réseau, et applique des politiques d'enforcement. Cette page le montre au travail sur un hôte, avec des sorties réelles capturées sur une VM Ubuntu 24.04 (noyau 6.8, Tetragon v1.7.0). Pour le socle eBPF, voir le hub eBPF.

Ce que vous allez apprendre

Distinguer observer, détecter et bloquer
Lancer Tetragon sur un hôte et lire son flux d'événements
Comprendre les TracingPolicy, qui ciblent finement ce qu'on surveille
Écrire une politique qui bloque une action (enforcement)
Situer Tetragon en Kubernetes et face aux autres outils

Le problème : détecter, c'est déjà trop tard

Les outils de sécurité runtime alertent : ils repèrent une action suspecte et l'enregistrent. Utile, mais l'alerte arrive après que l'action a eu lieu. Pour une lecture de fichier sensible ou une élévation de privilèges, il est parfois déjà trop tard.

Tetragon ajoute la couche d'application (enforcement). En s'accrochant aux bons points du noyau, il peut non seulement voir une action interdite, mais l'empêcher en terminant le processus fautif au moment même où il tente de la réaliser. Observer, détecter, bloquer : c'est le continuum que couvre Tetragon.

Prérequis

Un hôte Linux avec un noyau récent et BTF (/sys/kernel/btf/vmlinux), voir CO-RE et BTF.
Un runtime de conteneurs pour lancer l'image officielle.
Les privilèges pour charger des programmes eBPF sur l'hôte.

Lancer Tetragon et observer

Comme les autres outils de sécurité runtime, Tetragon se distribue en image conteneur. On le lance avec accès à l'hôte, puis on lit son flux avec le client tetra :

sudo docker run -d --name tetragon --pid=host --cgroupns=host --privileged \
  -v /sys/kernel:/sys/kernel -v /proc:/procHost \
  quay.io/cilium/tetragon:v1.7.0

# le flux d'événements, en vue compacte
sudo docker exec tetragon tetra getevents -o compact

Sortie réelle (chaque début et fin de processus, avec l'identifiant du conteneur d'origine) :

process  603c747a0f99  /usr/bin/uname -r
exit     603c747a0f99  /usr/bin/uname -r 0
process  603c747a0f99  /usr/bin/cat /etc/hostname
exit     603c747a0f99  /usr/bin/cat /etc/hostname 0

La vue compacte marque chaque démarrage (process) et chaque sortie (exit, suivie du code de retour), avec la commande complète. Par défaut, Tetragon observe déjà les exécutions de processus, sans configuration. Pour cibler autre chose, ou pour bloquer, on écrit une TracingPolicy.

Les TracingPolicy : cibler finement

Une TracingPolicy est une ressource qui décrit ce que Tetragon surveille et ce qu'il en fait. Elle s'accroche à un point du noyau (un kprobe sur une fonction, un tracepoint), filtre les événements avec des sélecteurs (par chemin de fichier, par argument, par valeur), et associe une action.

Sans action de blocage, une politique sert à observer précisément : par exemple, ne remonter que les ouvertures d'un fichier sensible, au lieu de tout le flux. C'est déjà précieux pour réduire le bruit et se concentrer sur ce qui compte.

Bloquer une action : l'enforcement

C'est le cœur de Tetragon. On ajoute à un sélecteur une action d'application, la plus directe étant Sigkill : Tetragon termine le processus dans le noyau au moment où il déclenche l'événement ciblé. Exemple d'une politique qui empêche tout processus d'ouvrir un fichier protégé :

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

Le mécanisme, documenté par le projet : lorsqu'un processus tente d'ouvrir /etc/mon-secret, le sélecteur correspond, et l'action Sigkill tue le processus avant que l'ouverture n'aboutisse. La différence avec un outil de détection est fondamentale : Tracee ou Falco auraient signalé l'accès ; Tetragon l'empêche. Au-delà de Sigkill, d'autres actions existent (surcharger la valeur de retour d'un appel, par exemple), mais Sigkill illustre le principe le plus clairement.

Tetragon en Kubernetes

Le cas d'usage principal de Tetragon est le cluster. Il s'y déploie en DaemonSet (une instance par nœud), et les événements comme les politiques portent le contexte Kubernetes : pod, espace de noms, étiquettes.

helm repo add cilium https://helm.cilium.io
helm install tetragon cilium/tetragon -n kube-system

Les TracingPolicy deviennent alors des ressources Kubernetes, appliquées à l'échelle du cluster et ciblables par espace de noms ou par étiquette de pod. C'est ce qui permet, par exemple, d'interdire une action dans un namespace précis sans toucher au reste.

Tetragon, Tracee ou Falco

Trois outils eBPF se partagent le terrain de la sécurité runtime, avec des priorités différentes. Le comparatif détaillé mérite sa page : voir Falco vs Tetragon. En bref :

Tetragon couvre l'observation et le blocage in-kernel ; c'est le seul des trois à empêcher une action, pas seulement la signaler.
Falco est la référence de la détection par règles, projet CNCF mûr et très intégré.
Tracee met l'accent sur la détection par signatures et le forensic.

Sécurité et points de vigilance

Privilèges élevés. Tetragon tourne avec un accès complet au noyau : c'est un composant sensible, à traiter comme tel (surface réduite, mises à jour suivies).
Le blocage est une arme à double tranchant. Une politique trop large peut provoquer une panne. Toujours valider en observation avant d'activer Sigkill.
Volume et bruit. Sur un hôte chargé, tout observer coûte cher et noie l'information. Utiliser des TracingPolicy ciblées plutôt que le flux brut.
Données sensibles. Les événements contiennent chemins, arguments, identités. À traiter comme des journaux de sécurité.

Dépannage

Symptôme	Cause probable	Solution
Aucun événement	BTF manquant, ou montages hôte absents	Vérifier `/sys/kernel/btf/vmlinux` et les volumes `--privileged`
La politique ne bloque pas	Sélecteur qui ne correspond pas	Vérifier le chemin/argument exact, tester d'abord en observation
Processus légitimes tués	Politique trop large	Restreindre les sélecteurs, revalider en observation
`permission denied`	Conteneur non privilégié	Ajouter `--privileged` et les montages requis

À retenir

Tetragon observe les processus et le réseau et peut bloquer une action dans le noyau : c'est son différenciateur.
Par défaut, il remonte les exécutions de processus (process / exit) sans configuration.
Une TracingPolicy cible finement un point du noyau, filtre par sélecteurs, et associe une action.
L'action Sigkill termine le processus avant que l'action interdite n'aboutisse, là où Tracee ou Falco se contentent d'alerter.
L'enforcement se valide d'abord en observation : une politique trop large peut casser un service.
En Kubernetes, Tetragon se déploie en DaemonSet avec des politiques ciblables par pod et namespace.

Prochaines étapes

Falco vs Tetragon Choisir entre détection et application selon le besoin.

Tracee : détection par signatures L'approche forensic, complémentaire de l'application.

Durcir eBPF sur un serveur Réduire la surface du sous-système qui rend tout cela possible.

Le hub eBPF Comprendre la technologie derrière l'observation et le blocage.