Sécurité runtime : Falco et Tetragon, sur quel critère trancher

L’auditeur revient sur vks-fret-01 avec sa quatrième question, et c’est la plus désagréable des quatre : montrez-moi ce qu’un processus a réellement fait à l’intérieur d’un pod que vous avez autorisé, sur un réseau que vous avez ouvert, depuis une image que vous avez signée. Aucun des trois plans de contrôle précédents ne répond. Le RBAC autorise des appels d’API. Une politique réseau autorise ou interdit un flux, sans le journaliser. Une signature atteste d’une provenance, pas d’un comportement. La détection runtime est le premier plan qui regarde ce qui se passe — et le dernier filet quand les trois autres ont laissé passer quelque chose.

Cet article ne compare pas deux produits : il compare deux documentations. Chaque axe est renseigné par la page du projet concerné des deux côtés, ou il est déclaré non tranchable — et cette déclaration est un livrable, pas un aveu de recherche incomplète. Aucun lab n’a été exécuté : aucun agent n’a été déployé, aucun événement n’a été observé, aucune alerte n’a été triée. Tout ce qui suit provient de pages de documentation amont réellement chargées, et ce qui n’y figure pas est dit comme tel.

TL;DR

• La décision. Le choix ne se fait pas entre deux produits mais sur une question à deux réponses : voulez-vous voir, ou voulez-vous empêcher ? Un seul des deux projets publie un chemin d’application — et il publie aussi que ce chemin ne garantit rien à lui seul.
• L’arbitrage qui coûte. Empêcher exige une option de compilation du noyau (CONFIG_BPF_KPROBE_OVERRIDE), accepte une API en cilium.io/v1alpha1 — donc alpha — et transforme un faux positif en incident de production au lieu d’une alerte.
• L’action de lundi matin. Avant toute discussion d’outil, relever trois faits sur vos propres nœuds : version de noyau, exposition du BTF, présence de l’option d’override. Les deux premières branches de l’arbre de décision se ferment là, pas sur une page produit.

Contrat de version

Cette série tient sur un plancher Kubernetes 1.35 et une cible 1.36 : la 1.34 sort de support le 27 octobre 2026, avant la publication de cet article, et la 1.36 est la dernière version amont chargée. Aucune version ultérieure n’a été annoncée sur une page chargée : elle n’est donc pas mentionnée ici.

Ni Falco ni Tetragon ne sont des API Kubernetes. Leur version ne se lit pas dans un bandeau FEATURE STATE — il faut aller la chercher, et les deux projets ne la publient pas au même endroit. C’est un point de méthode qui vaut d’être dit.

Élément	Version	État	Où elle est publiée
Falco — documentation	v0.44	version courante de la doc	bandeau du site de documentation
Falco — dernière release	0.44.1, publiée le 11 juin 2026	release stable, pas une préversion	API GitHub du dépôt officiel
Tetragon — dernière release	v1.7.0, publiée le 29 avril 2026	release stable, pas une préversion	API GitHub du dépôt officiel
TracingPolicy, TracingPolicyNamespaced	cilium.io/v1alpha1	CRD, version d’API alpha	page de référence Tetragon
Règles Falco	—	fichier de règles, pas un objet Kubernetes	page Basic Elements of Falco Rules

Deux remarques de version qui piègent le lecteur. D’abord, cilium.io/v1alpha1 est une version d’API alpha, et c’est l’API sur laquelle repose toute la configuration de Tetragon, application comprise. Une équipe qui exige des API stables pour tout ce qui touche à la production doit le savoir avant, pas après ; ce n’est pas un défaut — une CRD hors arbre Kubernetes ne suit pas le cycle de vie amont — mais cela se nomme. Ensuite, un fichier de règles Falco ne porte aucun apiVersion, parce que ce n’est pas un objet Kubernetes : l’enveloppe qui le transporte, elle, en porte un.

Ce que cet article ne décrira pas, et pourquoi : PodSecurityPolicy (policy/v1beta1), déprécié en v1.21 et retiré en v1.25, qui n’est pas un objet de cette page ; le pilote eBPF legacy de Falco, qui n’apparaît plus sur la page Kernel Events chargée ; la liste des actionners de Falco Talon, publiée sur un site de documentation qui ne résout pas en DNS ; et tout chiffre d’overhead, de latence, de consommation ou de volume d’alertes, parce qu’aucun chiffre comparable n’a été trouvé sur une page amont — c’est un résultat, pas une lacune.

Le cadrage à retirer avant de comparer

Le premier service que rend cet article est de retirer au lecteur un cadrage qu’il a probablement déjà lu ailleurs : « Falco fait de l’audit, Tetragon fait de l’eBPF ». La page Kernel Events de falco.org liste deux pilotes pour Falco, et donne le modern eBPF probe comme pilote par défaut ; le module noyau vient en second. Le premier est bâti sur le paradigme CO-RE et embarqué dans le binaire.

Les deux outils collectent en eBPF. Un lecteur qui choisit l’un « parce que c’est l’eBPF » choisit sur un critère inexistant. La différence est ailleurs, et c’est tout le sujet.

Sept axes, et la règle qui les admet

Une règle, énoncée avant la comparaison : un axe n’entre dans la matrice que s’il est renseigné par la documentation des deux projets. Un axe documenté d’un seul côté n’est pas un avantage, c’est un angle mort — il sort de la matrice. Ce n’est pas de la prudence : c’est la seule protection contre le comparatif de vendeurs. Falco et Tetragon sont portés par deux organisations distinctes qui publient chacune du contenu de positionnement ; reprendre un axe depuis la page de l’un revient à le laisser écrire les règles du match.

Axe	Falco — ce que publie le projet	Tetragon — ce que publie le projet
1. Collecte	appels système captés par un pilote, flux confronté à un moteur de règles, alerte ; deux pilotes, modern eBPF par défaut	points d’accroche déclarés dans une politique, filtrage dans le noyau ; socle sans politique : process_exec et process_exit
2. Périmètre d’événements	deux familles — noyau et greffon ; greffons nommés pour l’audit Kubernetes (k8saudit, k8saudit-aks, k8saudit-eks, k8saudit-gke, k8saudit-ovh), CloudTrail, Okta, GitHub, Docker, Nomad	types d’événements de processus PROCESS_EXEC, PROCESS_EXIT, PROCESS_KPROBE, PROCESS_UPROBE, PROCESS_TRACEPOINT, PROCESS_LOADER ; domaines listés : capacités, exécution, intégrité de fichiers, réseau, intégrité de l’OS, privilèges
3. Modèle de règles	langage de règles — rules, macros, lists ; cinq champs obligatoires, huit priorités d’EMERGENCY à DEBUG ; jeu par défaut livré, seules les règles maturity_stable activées	ressource Kubernetes déclarative ; onze filtres de sélecteur, dont matchArgs, matchBinaries, matchNamespaces, matchWorkloads ; limites publiées, notamment « each hook can contain up to 5 selectors » ; bibliothèque de politiques présentée comme des exemples à appliquer
4. Application	aucune section d’application dans l’arborescence des concepts ; réponse déléguée à Falco Talon, dépôt séparé badgé Incubating	deux actions publiées, Override return value et Signals ; trois modes de politique monitoring, enforcement, monitor_only
5. Dépendances noyau	modern eBPF : « all versions >=5.8 are enough », BTF exposé, ring buffer BPF, capacités CAP_SYS_BPF, CAP_SYS_PERFMON, CAP_SYS_RESOURCE, CAP_SYS_PTRACE — module noyau : >= 3.10, privilèges complets	« Tetragon needs Linux kernel version 4.19 or greater » ; BTF requis pour CO-RE ; CONFIG_BPF, CONFIG_BPF_JIT, CONFIG_BPF_EVENTS, CONFIG_BPF_SYSCALL ; CONFIG_BPF_KPROBE_OVERRIDE sous la section Enforcement ; LTS testés 4.19, 5.4, 5.10, 5.15, bpf-next
6. Volume et destination	perte à l’entrée quand les tampons par CPU saturent ; leviers buf_size_preset, cpus_for_each_buffer, base_syscalls ; compteurs scap.n_drops*, falco.outputs_queue_num_drops ; cinq canaux de sortie	étranglement par cgroup via --cgroup-rate, événements THROTTLE_START / THROTTLE_STOP ; compteurs tetragon_bpf_missed_events_total, tetragon_observer_ringbuf_events_lost_total ; export JSON, journal ou point de terminaison gRPC
7. Gouvernance	projet CNCF gradué le 29 février 2024, accepté le 10 octobre 2018 — trajectoire publiée par la fondation	aucune déclaration de maturité sur le dépôt officiel ; Tetragon n’est nommé nulle part sur la page projet CNCF de Cilium

Deux dissymétries se lisent dans ce tableau et ne doivent pas être lissées. Falco publie les capacités Linux requises par son pilote, Tetragon non — sur les pages chargées. Tetragon publie la liste des noyaux LTS sur lesquels il est éprouvé, Falco non. Ce sont des absences de publication, pas des absences de propriété. La même prudence vaut pour la ligne 7 : rien de ce qui a été chargé ne permet d’établir le statut de Tetragon vis-à-vis de la CNCF, ni comme projet propre ni comme sous-projet ; le seul fait citable est l’asymétrie de publication.

Un dernier point d’honnêteté sur l’axe 2. L’argument selon lequel un filtrage dans le noyau vaut mieux qu’un filtrage en espace utilisateur, parce que ce dernier intervient après l’exécution de l’appel, est publié par le projet Tetragon. C’est un argument de projet, pas un constat neutre, et aucune page de falco.org chargée n’y répond. Cette absence de réponse n’est pas une concession : c’est un axe documenté d’un seul côté.

Qui empêche réellement quelque chose

C’est l’axe qui porte la conclusion de l’article, et de toute la série.

Côté Falco, le fait est documentaire, pas polémique : la page Concepts publie cinq entrées — Event Sources, Rules, Outputs, Plugins, Metrics. Aucune section d’application, de réponse ou de blocage. Le vocabulaire de la page d’accueil est parsing, asserting, alerting. La réponse automatisée existe, mais dans un dépôt séparé : falcosecurity/falco-talon, décrit comme « a Response Engine for managing threats in your Kubernetes », alimenté par Falco ou Falcosidekick, et badgé Incubating. Écrire « Falco peut tuer le pod » revient à attribuer à un projet gradué une capacité portée par un composant en incubation.

Côté Tetragon, deux actions sont publiées. Override return value : « the function will never be executed and, instead, a value (typically an error) will be returned to the caller ». Signals : l’envoi d’un SIGKILL à un processus correspondant à des critères. Et la page publie immédiatement la limite de la seconde, qu’il faut citer mot pour mot : « Sending a SIGKILL signal does not always stop the operation being performed by the process that triggered the operation. » L’exemple donné est un write() : le signal ne garantit pas que la donnée ne sera pas écrite. La recommandation publiée est de combiner les deux actions.

S’ajoute un mode qui change tout en exploitation : monitoring — « enforcement operations are elided » ; enforcement — « enforcement operations are respected and performed » ; monitor_only — « the policy has no enforcement actions, thus it cannot be set to enforcement mode ». Le mode se pose dans la politique via spec.options, au chargement, ou à chaud.

La formulation juste, à ne pas arrondir : Tetragon publie un chemin d’application et sa limite ; Falco publie un chemin d’alerte et délègue la réponse à un composant séparé encore en incubation.

Manifeste de départ, explicitement non bloquant. Le point d’accroche fd_install et la structure d’arguments reprennent l’exemple publié sur la page Tracing Policy, adaptés au fil rouge :

apiVersion: cilium.io/v1alpha1
kind: TracingPolicyNamespaced
metadata:
  name: webshop-sensitive-file-watch
  namespace: webshop-app
spec:
  options:
    - name: "policy-mode"
      value: "monitor"          # pas d'application — les actions sont élidées
  podSelector:
    matchLabels:
      app: REPLACE_WITH_APP_LABEL
  kprobes:
    - call: "fd_install"
      syscall: false
      args:
        - index: 0
          type: "int"
        - index: 1
          type: "file"
      selectors:
        - matchArgs:
            - index: 1
              operator: "Equal"
              values:
                - "REPLACE_WITH_WATCHED_PATH"
          matchActions:
            - action: Sigkill      # non exécutée tant que policy-mode vaut monitor

Le chemin surveillé reste un placeholder à dessein : un chemin d’exemple recopié tel quel en production surveille le mauvais fichier.

La règle Falco équivalente en intention n’est pas un objet Kubernetes et ne porte donc pas d’apiVersion. Structure et champs conformes à la page Basic Elements of Falco Rules :

# fichier de règles Falco — pas un objet Kubernetes, pas d'apiVersion
- rule: shell_in_webshop_container
  desc: notice shell activity within a webshop container
  condition: >
    (evt.type in (execve, execveat)) and
    container.id != host and
    proc.name = bash
  output: >
    shell in a container |
    user=%user.name container_id=%container.id
    container_name=%container.name shell=%proc.name
    parent=%proc.pname cmdline=%proc.cmdline
  priority: WARNING

L’enveloppe Kubernetes qui transporte ce fichier, elle, porte bien son apiVersion — et c’est elle qui tombe sous le RBAC posé au premier article de la série :

apiVersion: v1
kind: ConfigMap
metadata:
  name: falco-rules-webshop
  namespace: REPLACE_WITH_FALCO_NAMESPACE
data:
  webshop_rules.yaml: |
    - rule: shell_in_webshop_container
      # … contenu du fichier de règles ci-dessus

Les deux axes que la documentation ne tranche pas

Ce tableau est un livrable au même titre que la matrice. C’est aussi, très exactement, l’endroit où entre le comparatif de vendeurs : un chiffre d’overhead ou un taux de détection est ce que le lecteur cherche, ce qui rend un article partageable — et ce qui n’existe dans aucune source amont chargée.

Axe non tranchable	Pourquoi	Ce que cet article publie à la place
Couverture de détection comparée	aucun des deux projets ne publie de méthodologie d’évaluation, et aucune méthodologie commune n’a été trouvée sur page chargée	ce que chacun observe (axe 2), à confronter à vos propres cas d’usage — jamais « X détecte mieux que Y »
Overhead, latence, consommation, volume d’alertes	zéro chiffre comparable trouvé sur une page amont chargée, sur deux campagnes de vérification	les compteurs à relever chez vous (axe 6) — importer un chiffre d’un billet tiers reviendrait à emprunter la crédibilité d’un inconnu sous une signature réelle

Ce que l’axe 6 apporte au choix tient en une phrase : les deux projets publient une mécanique de perte d’événements et les compteurs pour la mesurer, aucun ne publie de valeur de référence comparable. Les deux vous donnent de quoi mesurer chez vous ; aucun ne vous dispense de le faire.

Relever trois faits sur ses nœuds avant de choisir

Les notes de version VKr publient les versions de noyau des images de nœuds, VKr par VKr. Pour v1.36.1 : Photon 5.0 en 6.1.170-1.ph5, Ubuntu 22.04 LTS en 5.15.0-181.191, Ubuntu 24.04 LTS en 6.17.0-35.35~24.04.1. Pour v1.35.5, la version plancher de la série : Photon 5.0 en 6.1.170-1.ph5, Ubuntu 22.04 en 5.15.0.179.163 (generic), Ubuntu 24.04 en 6.17.0-29.29~24.04.1 (hwe). L’image par défaut est publiée : « By default, VKS cluster nodes use the PhotonOS edition of the specified VKr », la bascule vers Ubuntu se faisant par l’annotation run.tanzu.vmware.com/resolve-os-image: os-name=ubuntu.

La conséquence est nette : les trois noyaux publiés dépassent le plancher >= 5.8 du pilote modern eBPF de Falco et le plancher 4.19 de Tetragon. Sur ce critère de version, et sur celui-là seul, aucun des deux outils n’est écarté par la plateforme.

Les trois relevés à faire, et qui n’ont pas été faits ici. Les sorties ne sont pas reproduites, précisément parce qu’elles n’ont pas été observées :

# 1. version de noyau réellement en service, par nœud
kubectl get nodes -o wide

# 2. exposition du BTF — le fichier doit exister sur le nœud
ls -l /sys/kernel/btf/vmlinux

# 3. option d'override de kprobe — conditionne l'action Override de Tetragon
zcat /proc/config.gz | grep -E 'CONFIG_BPF_KPROBE_OVERRIDE|CONFIG_DEBUG_INFO_BTF'

Le placeholder REPLACE_WITH_NODE_KERNEL_VERSION du fil rouge reste volontairement vide, même si la valeur du catalogue est connue : la version publiée pour une image VKr n’est pas la preuve de ce qui tourne sur un cluster donné, qui dépend de l’image choisie et du niveau de correctif appliqué.

Le reste de la procédure est une procédure de décision, pas d’installation. Écrire la question avant de comparer les réponses — voir ou empêcher, et répondre « les deux » revient à trancher dans l’urgence au premier incident. Poser la destination d’alerte avant l’agent : qui reçoit, à quelle heure, et que fait cette personne à 3 h du matin ; le groupe grp-secops est le destinataire, et les deux outils exposent des métriques Prometheus, ce qui rend la supervision de l’agent lui-même possible dès le premier jour. Démarrer sans rien empêcher dans les deux cas — Falco par construction, Tetragon par le mode monitoring. Puis, seulement, basculer politique par politique, avec la commande de retour écrite dans le ticket avant l’activation :

# passage explicite en application, politique par politique
tetra tp set-mode --namespace webshop-app webshop-sensitive-file-watch enforce

# retour en observation — même commande, mode inverse
tetra tp set-mode --namespace webshop-app webshop-sensitive-file-watch monitor

Le retour arrière n’est d’ailleurs pas symétrique, et c’est un critère de choix à part entière. Retirer Falco retire de la visibilité et rien d’autre, puisqu’il n’empêche rien : le coût est un angle mort, pas une interruption. Retirer une politique Tetragon en mode monitoring non plus. Retirer une politique en application devient une opération de production — et aucune page chargée ne décrit ce qu’il advient d’une opération en cours à ce moment-là. C’est un trou assumé : la bascule de mode est le retour arrière à privilégier, parce que c’est le seul explicitement documenté.

Pièges & points de vigilance

• matchNamespaces ne parle pas de Kubernetes. Dans les sélecteurs Tetragon, matchNamespaces filtre sur les namespaces Linux ; matchWorkloads filtre sur les charges Kubernetes, et la sélection par identité Kubernetes passe par podSelector et containerSelector. Deux notions homonymes, deux effets différents.
• Un mode monitor_only ne devient pas bloquant. Publié : la politique n’a pas d’actions d’application, « thus it cannot be set to enforcement mode », et la bascule à chaud « will result in an error ». Le mode n’ajoute pas une action absente de la politique.
• La maturité d’une règle Falco n’est pas une promesse de silence. Publié noir sur blanc : « The maturity level of the rules, however, does not directly reflect their potential for generating noise in the adopters’ environment. » Une règle stable peut être bruyante chez vous.
• Ne pas superviser l’agent lui-même. Les deux projets publient une mécanique de perte d’événements et les compteurs correspondants. Un agent qui perd silencieusement produit une couverture apparente, ce qui est plus dangereux qu’une absence assumée.
• Un cgroup étranglé est un angle mort. L’étranglement de Tetragon « stops posting its events » au-delà du seuil, et la réserve publiée précise que seuls les événements du capteur de base, PROCESS_EXEC et PROCESS_EXIT, sont surveillés à ce titre. C’est une protection, et c’est aussi une perte de visibilité sur le cgroup le plus actif — donc potentiellement le plus intéressant.
• Un point d’accroche présent d’un seul côté de la documentation. La page de concepts de Tetragon liste trois types de points d’accroche (kprobes, tracepoints, uprobes), la page de référence en liste cinq (les mêmes plus LSM hooks et USDTs). Deux pages du même projet, chargées le même jour, ne disent pas la même chose : l’écart n’est pas tranché ici, et tant qu’il ne l’est pas sur une version précise, ne bâtissez pas une politique de production sur un point d’accroche présent d’un seul côté.
• Une alerte Falco ne portera pas toujours son contexte Kubernetes. Les champs k8s.* sont extraits du socket du runtime de conteneurs, avec des conditions de course publiées et des processus de bac à sable sans image. Une alerte sans nom de pod arrive à l’astreinte comme une alerte sans adresse.
• Ce que la documentation ne publie pas. Tetragon publie un modèle de menace explicite — « Tetragon’s current design does not offer comprehensive protection against all forms of kernel-level exploitation », et « no security observability data from a root-compromised node can be considered trustworthy ». Aucune page équivalente n’a été trouvée côté Falco : c’est une absence de publication, pas une absence de limites. De même, les privilèges Linux requis par Tetragon n’ont pas été relevés sur les pages chargées, alors que Falco publie les siens.

Conclusion

Pas de vainqueur. La conclusion est une question que vous posez à votre propre plateforme, en trois branches, chacune adossée à une page publiée. Vos sources d’intérêt sont-elles toutes sur la machine ? Si le journal d’audit Kubernetes, un journal cloud ou un fournisseur d’identité entrent dans le périmètre, un seul des deux projets publie des greffons pour ces sources. Avez-vous besoin d’empêcher, et vos noyaux le permettent-ils ? Si oui, un seul des deux publie un chemin d’application — et il publie aussi que ce chemin ne garantit rien sans combinaison d’actions, et qu’il dépend d’une option de compilation. Qui écrit les règles, et avec quel outillage ? Un langage de règles avec bibliothèque livrée et niveaux de maturité, ou une ressource Kubernetes déclarative soumise au RBAC et bornée par des limites numériques publiées.

Aucune de ces trois branches ne se décide en lisant un tableau comparatif. Les trois se décident en relevant un fait sur son propre cluster.

Et la série se clôt sur un aveu plutôt que sur une case cochée. Le RBAC autorise ou refuse un appel d’API, pas un comportement de processus déjà démarré. Le mode enforce de Pod Security Admission rejette le pod, mais ne s’applique pas aux objets de charge : le Deployment, lui, passe. NetworkPolicy isole par sélection, sans règle de refus explicite ni journalisation — c’est publié dans sa propre liste de non-capacités. La signature atteste d’une provenance, pas d’un comportement, et exige un composant hors arbre. Et sur ce quatrième plan, Falco ne bloque pas, tandis que le SIGKILL de Tetragon ne garantit pas que l’opération n’a pas eu lieu. Quatre filets, chacun troué à un endroit que sa propre documentation publie. Le cinquième plan n’est pas un outil : c’est quelqu’un qui lit les alertes.

Les quatre articles de la série, dans l’ordre : 1 — RBAC Kubernetes, 2 — Network policies et Cilium, 3 — Supply chain : Sigstore, SBOM, admission control, et celui-ci.

Lectures voisines : Déployer son premier cluster VKS sur VCF 9 pour la plateforme sur laquelle tout ceci tourne, Day-2 ops sur VKS : lifecycle, upgrades, observabilité pour le cycle de vie des VKr et donc des noyaux de nœuds, Prometheus & Grafana sur VKS pour la destination des métriques d’agent, et VCF 9.1 : sécurité & résilience pour le contexte de durcissement de la plateforme.