Monitoring eBPF dans Kubernetes : Détection de menaces runtime invisibles

9 Min. Temps de lecture

En 2025, les attaquants sont restés plus longtemps dans les clusters Kubernetes allemands que la majorité des CISOs de la région DACH ne veulent l’admettre. Sysdig a documenté dans son rapport sur les menaces 2026 que le temps d séjour moyen d’un intrus dans un conteneur est de 196 heures, tandis que le rapport M-Trends de Mandiant estime ce délai à 21 jours. L’écart entre la réalité des clusters et le champ de vision de l’EDR est large et structurel. La détection classique des points de terminaison fonctionne au niveau de l’hôte et ne voit pas la plupart des activités pertinentes dans un conteneur. Avec eBPF et les outils open source Falco et Tetragon qui s’appuient sur celui-ci, cette lacune se comble en 2026. Black Hat USA 2026 a élevé eBPF au rang de piste officielle, ce qui façonne le marché de l’ingénierie de détection pour les douze prochains mois.

Les points clés en bref

• L’EDR présente des lacunes constructives dans Kubernetes : Les activités de runtime de conteneur, l’exécution de code en mémoire, les workloads éphémères et les modèles de sidecar échappent à l’EDR classique de l’hôte. eBPF examine au niveau des appels système du noyau et comble cette lacune de visibilité.
• Falco et Tetragon sont prêts à la production en 2026 : Falco fournit une large bibliothèque de règles et une bonne intégration d’opérateur, tandis que Tetragon est plus fort en généalogie de processus et en observabilité de réseau. Les deux outils sont complémentaires et non concurrents.
• Les attaquants utilisent eBPF eux-mêmes : Les chargeurs furtifs, les rootkits en mémoire et les manipulations d’appels système via des programmes eBPF augmentent de manière visible en 2026. La détection doit lire la télémétrie du noyau, sinon les hôtes de conteneur sont aveugles.

LiéIngénierie de détection sans verrouillage de fournisseur  /  Auto-réplication : agents KI

Pourquoi l’EDR classique ne suffit pas dans le cluster

La détection et la réponse aux points de terminaison (EDR) ont été conçues pour les configurations classiques de serveurs et de stations de travail. Un agent EDR s’exécute sur l’hôte, observe la généalogie des processus, les opérations de fichiers, les connexions réseau et répond à des anomalies prédéfinies. Dans un environnement Kubernetes, ce modèle s’effondre pour trois raisons.

Premièrement : les conteneurs sont éphémères. Un pod qui ne vit que 90 secondes ne laisse derrière lui qu’une trace au mieux dans l’EDR de l’hôte, qui est échantillonnée par la télémétrie. La logique de détection part de processus de plusieurs minutes, alors que la réalité est de quelques secondes. Qui observe les charges de travail de conteneur avec une granularité d’hôte voit 70 à 80 % des événements pertinents.

Deuxièmement : exécution en mémoire. Les chaînes d’outils d’attaque modernes pour les conteneurs utilisent des chargeurs en mémoire uniquement, qui ne déposent jamais de fichier sur disque. La détection EDR classique, qui repose sur les événements du système de fichiers, est conceptuellement aveugle ici. eBPF voit les appels système sous-jacents, car ils doivent passer par le noyau.

Troisièmement : architectures de sidecar et de service-mesh. Lorsqu’un seul pod maintient cinq conteneurs et sept connexions réseau qui fonctionnent en interne via mTLS, un EDR d’hôte voit principalement des paquets réseau peu clairs. Le niveau sémantique manque. eBPF peut enrichir cette télémétrie au niveau de la charge de travail, car elle provient du noyau, avant que mTLS ne s’applique.

Comment Falco et Tetragon travaillent concrètement

Les deux outils reposent sur eBPF, mais diffèrent par leur focalisation et leur niveau de maturité. Falco est le projet le plus ancien, diplômé CNCF, fournit une bibliothèque de règles établie et s’intègre proprement avec Prometheus, Loki et les pipelines SIEM. La force réside dans la largeur et la maturité : un ensemble de règles standard Falco permet de détecter entre 60 et 80 % des techniques MITRE-ATT&CK-for-Container dès le premier jet.

Tetragon est issu de l’écosystème Cilium, est étroitement lié à Cilium-CNI et apporte deux propriétés que Falco ne fournit pas à cette profondeur : premièrement, une généalogie de processus complète, c’est-à-dire l’arbre généalogique père-fils de chaque activité de conteneur, deuxièmement, une couche d’application en temps réel. Tetragon peut non seulement détecter qu’un processus appelle un syscall interdit, mais également bloquer l’appel directement dans le noyau.

Pour 2026, la pile pragmatique pour les opérateurs de clusters DACH plus importants ressemble souvent à ceci : Falco comme détecteur large avec une bibliothèque de règles et une intégration SIEM, Tetragon en complément pour la généalogie des processus dans les espaces de noms particulièrement sensibles et pour l’application sélective au moment de l’exécution. Si vous ne voulez utiliser que l’un des deux en 2026, commencez par Falco, car la courbe d’apprentissage est plus plate et l’intégration des opérateurs est plus avancée.

Exemples concrets de détection pour les menaces en mémoire

Trois modèles d’exemple qui ont augmenté de manière mesurable dans les clusters DACH en 2026 et qui sont accessibles avec la télémétrie eBPF.

Memfd-Loader et exécution sans fichier. Les attaquants créent un descripteur de fichier mémoire anonyme via memfd_create, écrivent du code dedans et l’exécutent sans laisser de traces sur le disque. Règle Falco : alerte en cas de memfd_create suivi de execveat dans le même groupe de processus dans un espace de noms productif. L’EDR hôte ne voit pas de fichier ici, eBPF voit les deux syscalls.

Évasion de conteneur via élévation de privilèges cap_sys_admin. Modèle d’évasion classique qui réapparaît plus fréquemment dans les journaux de Honeypot en 2025/2026. Politique de traçage Tetragon : alerte en cas de changement de capacité dans un conteneur qui ne démarre pas dans l’espace de noms privilégié. L’EDR hôte ne voit le conteneur que comme un processus générique du runtime de conteneur, le déplacement de privilège reste invisible.

Rootkits basés sur eBPF. Les attaquants chargent leurs propres programmes eBPF qui patchent les syscalls et cachent l’activité des outils classiques. Plugin Falco ebpf-program-loaded : alerte en cas de bpf_prog_load dans un espace de noms non publié. Seule la télémétrie du noyau lui-même aide ici, car la vue de l’espace utilisateur est manipulée par le rootkit.

Avantages et inconvénients des deux outils

Comment un déploiement réaliste en 2026 peut se dérouler

Il est important de ne pas considérer le déploiement comme une introduction d’outil, mais comme un programme d’ingénierie de détection. Une pipeline basée sur eBPF sans règles documentées, sans tests CI pour la logique de détection et sans routine de tri des alertes dans les couches SOC produit des données sans effet. Pour utiliser sérieusement Falco et Tetragon, planifiez en 2026 avec deux à trois équivalents temps plein (ETP) d’ingénierie de détection qui ne seront pas absorbés par les activités quotidiennes normales du SOC.

Où la discipline vacille encore en 2026

Trois points ouverts accompagnent la tendance eBPF 2026 et devraient être pris en compte dans chaque concept. Premièrement : dérive de la version du noyau. Les programmes eBPF sont étroitement liés à l’interface du noyau, qui peut varier entre les versions du noyau. Quiconque mise sur des nœuds de travail à longue durée de vie doit prendre au sérieux CO-RE (compiler une fois, exécuter partout), sinon chaque mise à jour du noyau détruit la chaîne de détection.

Deuxièmement : surcharge de performances dans les clusters denses. Falco avec des règles modérées coûte entre 1 et 3 % de CPU de nœud de travail sous charge normale, mais peut être nettement plus élevé dans les clusters denses multi-locataires. Des profils de performances de règles soigneusement établis et des filtres ciblés sont obligatoires en 2026, sinon les discussions FinOps commencent, ce qui met en danger le programme.

Troisièmement : Kubernetes géré par le cloud avec des cycles de vie de lockdown. AWS EKS, GKE et AKS autorisent désormais les programmes eBPF, mais avec des restrictions différentes. Quiconque exploite Multi-Cloud-K8s doit établir une stratégie de détection cohérente sur les plates-formes, pas pour chaque cluster.

Foire aux questions

La détection eBPF remplace-t-elle la détection EDR classique dans le cluster ?

Non. La détection EDR classique reste pertinente pour le niveau de l’hôte et la compromission du nœud de travail. Les outils basés sur eBPF comblent l’écart de visibilité des conteneurs et étendent la pile. Une détection de cluster moderne 2026 combine EDR au niveau du nœud de travail avec Falco ou Tetragon au niveau du pod et avec la détection de réseau au niveau du maillage.

Quel est le surcoût de performances de Falco en production ?

Avec des règles modérées, le surcoût de CPU par nœud de travail se situe généralement entre 1 et 3 %. Dans les clusters denses multi-locataires avec des règles agressives, il peut atteindre 5 à 8 %. Quiconque entretient activement les profils de performances des règles maintient le surcoût dans un intervalle de pourcentage.

Quelle courbe d’apprentissage les équipes SOC doivent-elles prévoir pour eBPF ?

Réalistement, deux à quatre semaines pour Falco jusqu’à la maintenance productive des règles, quatre à huit semaines pour Tetragon. Plus important que l’approfondissement de l’outil est la pratique de l’ingénierie de détection : cartographie MITRE-ATT&CK, CI pour les règles, boucles de tri des alertes. Sans cette pratique, eBPF reste une source de télémétrie coûteuse.

Faut-il utiliser Falco et Tetragon simultanément ?

Dans les grands clusters de plus de vingt nœuds de travail et de plusieurs espaces de noms sensibles, une utilisation parallèle est justifiée. Falco apporte une couverture large et une connexion SIEM, Tetragon approfondit la généalogie des processus et fournit une application. Dans les configurations plus petites, Falco seul suffit généralement.

Comment eBPF change-t-il la discussion sur la conformité NIS2 ?

Positivement. Les entités soumises à NIS2 doivent démontrer leurs capacités de détection et de réponse. La télémétrie basée sur eBPF améliore significativement la qualité des traces d’audit, car les appels système du noyau sont la source la plus fiable pour la forensic. Quiconque doit mettre à jour son ensemble NIS2 en 2026 devrait prendre en compte la couverture eBPF comme argument.

Conseils de lecture de la rédaction

• Ingénierie de détection sans verrouillage fournisseur : pile Wazuh 2026
• Auto-réplication : agents IA de 6 à 81 %
• Phishing IA : les filtres de messagerie deviennent aveugles

Plus du réseau MBF Media

cloudmagazinMulti-cluster sans nouveau silo Ops : ce que les équipes résolvent de travers

MyBusinessFutureLes coûts du cloud sont une affaire de chef : quand le DAF et le DSI ne calculent plus de travers

Digital ChiefsLa capacité de calcul devient une chaîne d’approvisionnement : Compute comme facteur de production rare en 2026

Source de l’image du titre : générée par IA via nano

À propos de l'auteur: Alec Chizhik

Plus d'articles de Alec Chizhik