27 février 2026 | Temps de lecture : 13 minutes 37 secondes
Introduction : Le noyau comme infrastructure
Pendant des décennies, l'observabilité signifiait ajouter du code à vos applications. Vous avez instrumenté vos services avec des bibliothèques de métriques, semé des SDK de traçage dans vos chemins d'appels et configuré des expéditeurs de journaux sur chaque hôte. Chaque couche de visibilité venait avec un coût : gestion des dépendances, surcharge de performance, modifications de code qui devaient être déployées et maintenues. Rater un point de terminaison et vous aviez un point aveugle. Mettre à jour une bibliothèque et vous risquiez de casser votre pipeline de télémétrie.
eBPF change cette équation fondamentalement. Au lieu d'instrumenter les applications, vous instrumentez le noyau. Chaque appel système, chaque paquet réseau, chaque accès fichier, chaque exécution de processus passe par le noyau Linux — et eBPF vous permet d'observer et d'agir sur ces événements sans modifier les applications qui les génèrent. Zéro changement de code. Zéro dépendances de SDK. Zéro coordination de déploiement.
Ce n'est pas une amélioration mineure. C'est une catégorie différente de capacité. Quand votre couche de surveillance fonctionne au niveau du noyau, vous voyez tout — y compris les choses que les applications choisissent de ne pas enregistrer, les connexions réseau qui contournent votre service mesh et les processus que votre conteneur runtime ne connaît pas.
L'écosystème eBPF s'est mûr rapidement à travers 2025 et dans 2026. Ce qui était autrefois une collection de projets de recherche et d'outils spécialisés est devenu une infrastructure de production à grande échelle. Cilium gère la mise en réseau pour les principaux fournisseurs cloud. Falco fournit la sécurité de l'exécution pour les clusters Kubernetes du monde entier. Tetragon applique les politiques de sécurité directement dans le noyau. Et des outils comme Coroot offrent une observabilité complète — métriques, journaux, traces et profilage continu — à partir d'un seul agent basé sur eBPF qui ne nécessite zéro changements d'application.
Cet article explique ce que eBPF est, pourquoi cela importe pour la sécurité et l'observabilité, et comment l'adopter en pratique.
Ce qu'eBPF est vraiment
eBPF signifie extended Berkeley Packet Filter, bien que le nom soit surtout historique à ce stade. L'eBPF moderne a bien dépassé le filtrage de paquets.
En son cœur, eBPF est une machine virtuelle à l'intérieur du noyau Linux qui exécute des programmes en bac à sable en réponse aux événements du noyau. Ces programmes peuvent observer les appels système, le trafic réseau, les opérations fichier, la planification des processus, et essentiellement toute activité au niveau du noyau — tout sans modifier le noyau lui-même ou nécessiter des modules de noyau.
Le modèle de sécurité
Ce qui rend eBPF pratique est son modèle de sécurité. Avant que tout programme eBPF ne s'exécute, le vérificateur du noyau le vérifie exhaustivement :
- Pas de boucles non délimitées : Les programmes doivent se terminer. Le vérificateur rejette les programmes qui pourraient s'exécuter indéfiniment.
- Pas d'accès mémoire invalide : Chaque déréférence de pointeur est validée. Les débordements de tampon sont impossibles.
- Limites de taille de pile : Les programmes ont une taille de pile fixe (512 octets), prévenant l'épuisement de la pile.
- Accès à la fonction d'aide : Les programmes ne peuvent appeler que des fonctions d'aide de noyau pré-approuvées, pas du code de noyau arbitraire.
- Exigences de privilège : Charger les programmes eBPF nécessite des capacités appropriées (généralement
CAP_BPFou root).
Cette vérification se produit au moment du chargement, pas à l'exécution. Une fois qu'un programme passe le vérificateur, il s'exécute à une vitesse quasi-native sans vérifications de sécurité à l'exécution. Le résultat est l'observabilité au niveau du noyau avec une surcharge de performance négligeable — généralement moins de 1-2 % d'impact CPU pour la surveillance complète.
Points d'attachement
Les programmes eBPF s'attachent à des événements de noyau spécifiques appelés crochets ou points d'attachement :
| Type de crochet | Cas d'usage | Exemple |
|---|---|---|
| kprobes | Tracer toute fonction de noyau | Surveiller sys_open pour suivre l'accès aux fichiers |
| tracepoints | Événements stables de trace de noyau | Suivre la création de processus via sched_process_exec |
| XDP | Traitement de paquets réseau | Abandonner les paquets malveillants avant qu'ils n'atteignent la pile réseau |
| TC | Contrôle du trafic | Appliquer les politiques réseau au niveau du conteneur |
| LSM | Crochets du module de sécurité Linux | Appliquer les politiques de sécurité sur les opérations fichier |
| uprobe | Traçage de fonction en espace utilisateur | Profiler les fonctions spécifiques de l'application |
| perf events | Compteurs de performance CPU | Profilage continu du CPU et de la mémoire |
L'étendue des points d'attachement est ce qui rend eBPF si puissant. Un seul agent basé sur eBPF peut surveiller simultanément le trafic réseau, l'accès fichier, l'exécution des processus, la résolution DNS et les modèles d'appels système — fournissant une vue unifiée qui aurait traditionnellement exigé cinq ou six outils séparés.
eBPF pour l'observabilité : Voir tout
L'observabilité traditionnelle a trois piliers : métriques, journaux et traces. eBPF active tous trois sans instrumentation, et ajoute un quatrième — profilage continu — qui est impraticable avec les approches au niveau de l'application.
Cartes de service sans instrumentation
Quand eBPF surveille les connexions réseau au niveau du noyau, il voit chaque connexion TCP et UDP entre les services — y compris les connexions qui contournent votre service mesh, les proxies sidecar ou l'instrumentation au niveau de l'application. Cela permet la découverte automatique de services et la cartographie des dépendances.
Des outils comme Coroot utilisent cette capacité pour générer des cartes de topologie en direct montrant toutes les dépendances de service. Aucun changement de code nécessaire. Aucun conteneur sidecar. Aucune configuration par service. Déployez l'agent, et en quelques minutes vous voyez quels services communiquent avec lesquels, la latence de chaque connexion et les taux d'erreur sur chaque chemin.
Ceci est particulièrement précieux pour :
- Applications héritées qui ne peuvent pas être instrumentées sans effort significatif
- Services tiers où vous ne contrôlez pas le code
- Environnements polyglot où différents services utilisent différentes langues et cadres
- Déboguer les problèmes de production où les dépendances inconnues causent des défaillances en cascade
Métriques conscientes du protocole
eBPF ne voit pas seulement les connexions réseau — il comprend les protocoles. En analysant les en-têtes de paquets au niveau du noyau, les agents eBPF peuvent extraire les métriques au niveau de l'application sans aucune conscience d'application :
HTTP/HTTPS : Méthode de requête, chemin, code d'état, latence — équivalent à ce que vous obtiendriez d'un journal d'accès, mais capturé au niveau du noyau pour chaque service automatiquement.
Protocoles de base de données : PostgreSQL, MySQL, Redis et les protocoles filaires MongoDB sont analysés pour extraire la latence de requête, les taux d'erreur et les comptes de connexion. Cela signifie que vous obtenez les métriques de performance de base de données sans installer un agent de surveillance de base de données ou modifier les chaînes de connexion.
gRPC : Suivi de latence et d'erreur au niveau de la méthode pour les services gRPC, capturé sans modifier la configuration du cadre gRPC.
DNS : Latence de résolution et taux d'échec pour chaque recherche DNS, aidant à identifier les problèmes liés au DNS qui sont notoirement difficiles à déboguer avec les outils au niveau de l'application.
Kafka : Mesures de décalage du producteur et du consommateur capturées au niveau du protocole, fournissant une visibilité indépendante du courtier dans les performances du pipeline de messages.
Profilage continu
Peut-être la capacité la plus sous-estimée de l'observabilité basée sur eBPF est le profilage continu. Le profilage traditionnel exige de joindre un profileur à un processus spécifique, de l'exécuter pendant une période et d'analyser la sortie. C'est trop disruptif et intensif en ressources pour une utilisation en production.
Le profilage basé sur eBPF fonctionne différemment. Il s'attache aux événements perf et échantillonne les traces de pile CPU à intervalles fixes sur tous les processus sur un hôte. La surcharge est minimale — généralement moins de 1 % CPU — le rendant possible d'exécuter continuellement en production.
La valeur pratique est significative. Quand un service connaît un pic de latence, vous n'avez pas besoin de reproduire le problème avec un profileur attaché. Les données de profilage sont déjà là, capturées en tant que graphiques de flamme qui montrent exactement où le temps CPU a été dépensé pendant l'incident. Cela transforme le débogage de performance d'une enquête réactive en une analyse rétrospective.
eBPF pour la sécurité : Le noyau comme première ligne de réponse
L'observabilité est seulement la moitié de l'histoire. eBPF est tout aussi transformateur pour la sécurité d'exécution, et la convergence de l'observabilité et de la sécurité en un seul agent au niveau du noyau est l'un des changements architecturaux les plus importants dans l'infrastructure moderne.
Détection de menace d'exécution
La surveillance de sécurité traditionnelle repose sur l'analyse des journaux — examen des journaux d'application, des journaux d'audit et des journaux système pour les indicateurs de compromission. Cette approche a des limitations fondamentales : les attaquants peuvent modifier ou supprimer les journaux, les applications peuvent ne pas enregistrer les événements pertinents pour la sécurité et l'expédition de journaux introduit une latence entre un événement et sa détection.
La surveillance de sécurité basée sur eBPF fonctionne à un niveau différent. En se branchant dans les appels système et les événements du noyau, il observe les activités qu'aucun journal ne peut supprimer :
- Exécution de processus : Chaque processus engendré sur un système, y compris ceux lancés par les exploits d'évasion de conteneur
- Accès fichier : Chaque fichier ouvert, lu, écrit ou supprimé, y compris l'accès aux chemins sensibles comme
/etc/shadowou les clés cryptographiques - Connexions réseau : Chaque connexion sortante, y compris celles qui contournent les politiques de réseau au niveau de l'application
- Escalade de privilège : Appels système qui modifient les capacités de processus, les IDs utilisateur ou les contextes de sécurité
- Chargement de module de noyau : Tentatives de charger des modules de noyau, qui peuvent indiquer une installation de rootkit
Application de politique
La détection est précieuse, mais la prévention est meilleure. Les crochets LSM (Linux Security Module) eBPF permettent aux politiques de sécurité d'être appliquées directement dans le noyau, bloquant les actions non autorisées avant qu'elles ne prennent effet.
Tetragon, développé par l'équipe Cilium, est l'outil principal dans cet espace. Il fournit :
Politiques d'exécution de processus : Définir quels binaires sont autorisés à s'exécuter dans un conteneur. Si un shell se lance dans un conteneur qui ne devrait exécuter qu'un binaire Go, Tetragon peut bloquer l'exécution et générer une alerte.
Politiques réseau : Appliquer quelles destinations un pod peut se connecter au niveau du noyau, contournant les vulnérabilités potentielles du runtime de conteneur.
Politiques d'accès fichier : Restreindre quels fichiers et répertoires un processus peut accéder, fournissant la défense en profondeur au-delà des permissions du système de fichiers.
Restrictions de capacité : Limiter quelles capacités Linux un processus peut exercer, même si le runtime du conteneur les accorde.
L'application se produit dans le noyau, ce qui signifie qu'elle ne peut pas être contournée par les exploits au niveau de l'application. Un attaquant qui gagne l'exécution du code à l'intérieur d'un conteneur ne peut toujours pas effectuer les actions que la politique eBPF bloque, parce que la politique est appliquée avant que l'appel système se termine.
Sécurité réseau
Cilium, l'outil de mise en réseau basé sur eBPF le plus largement déployé, a redéfini le fonctionnement de la sécurité réseau dans les environnements Kubernetes. Les politiques réseau traditionnelles fonctionnent au niveau de l'adresse IP et du port. Les politiques basées sur eBPF de Cilium fonctionnent au niveau de l'identité et de l'API :
- Politiques basées sur l'identité : Les politiques font référence aux étiquettes Kubernetes et aux identités de service plutôt qu'aux adresses IP, éliminant le besoin de suivre les allocations d'IP de pod
- Filtrage L7 : Politiques conscientes de HTTP, gRPC et Kafka qui peuvent restreindre l'accès à des points de terminaison API spécifiques, pas seulement des ports
- Chiffrement transparent : Chiffrement basé sur WireGuard entre les nœuds, implémenté dans le noyau via eBPF sans nécessiter de changements d'application
- Gestion de la bande passante : Limites de bande passante par pod appliquées au niveau du noyau
L'écosystème d'outils eBPF
L'écosystème eBPF s'est consolidé autour de plusieurs projets clés, chacun adressant un domaine spécifique.
Mise en réseau et sécurité
| Outil | Objectif | Responsable |
|---|---|---|
| Cilium | Mise en réseau Kubernetes, politique réseau, service mesh | Isovalent (Cisco) |
| Tetragon | Application de sécurité d'exécution | Isovalent (Cisco) |
| Falco | Détection de menace d'exécution | Sysdig / CNCF |
| Calico eBPF | Mise en réseau Kubernetes avec chemin de données eBPF | Tigera |
Observabilité
| Outil | Objectif | Responsable |
|---|---|---|
| Coroot | Observabilité complète (métriques, journaux, traces, profilage) | Coroot |
| Hubble | Observabilité réseau pour Cilium | Isovalent (Cisco) |
| Pixie | Observabilité Kubernetes | New Relic / CNCF |
| Parca | Profilage continu | Polar Signals |
| Grafana Beyla | Auto-instrumentation pour HTTP et gRPC | Grafana Labs |
Traçage et débogage
| Outil | Objectif | Responsable |
|---|---|---|
| bpftrace | Langage de traçage de haut niveau pour eBPF | IO Visor |
| BCC | Ensemble d'outils de collecte BPF | IO Visor |
| bpftool | Utilitaire de gestion de programme eBPF | Noyau Linux |
Adoption pratique : Bien démarrer
L'adoption d'eBPF ne nécessite pas une connaissance profonde du noyau. Les outils modernes d'eBPF abstrahient la complexité et présentent des interfaces familières — tableaux de bord, alertes et définitions de politique.
Commencer par l'observabilité
Le point d'entrée à risque le plus faible est l'observabilité. Déployer un agent basé sur eBPF comme Coroot ou Grafana Beyla aux côtés de votre pile de surveillance existante. L'agent ne nécessite aucun changement d'application — il s'exécute en tant que conteneur privilégié ou DaemonSet et commence immédiatement à collecter les métriques.
Pour les environnements Kubernetes :
# Déployer Coroot avec Helm
helm repo add coroot https://coroot.github.io/helm-charts
helm repo update coroot
helm install -n coroot --create-namespace coroot-operator coroot/coroot-operator
helm install -n coroot coroot coroot/coroot-ce
# Accéder au tableau de bord
kubectl port-forward -n coroot service/coroot-coroot 8080:8080
En quelques minutes, vous verrez une carte de service, des métriques de latence pour les connexions HTTP et base de données et des données d'utilisation de ressources — tout cela capturé sans aucun changement d'instrumentation de vos applications.
Ajouter l'application de sécurité
Une fois l'observabilité en place, l'étape naturelle suivante est l'application de sécurité. Tetragon fournit une voie graduée :
Phase 1 : Mode audit. Déployer Tetragon avec des politiques en mode audit. Il enregistre les violations de politique sans les bloquer, vous donnant du temps pour comprendre le comportement de votre application et affiner les politiques avant l'application.
Phase 2 : Mode alerte. Connecter les événements Tetragon à votre système d'alertes. Recevoir les notifications quand une activité suspecte se produit — processus inattendus, connexions réseau non autorisées, accès aux fichiers sensibles.
Phase 3 : Mode application. Activer l'application sur les politiques qui ont été validées en mode audit. Commencer par les restrictions les plus critiques — prévention de l'évasion de conteneur, par exemple — et étendre graduellement la couverture.
Exigences du noyau
Les capacités eBPF dépendent de la version du noyau Linux. Pour les outils modernes d'observabilité et de sécurité eBPF, vous avez besoin de :
| Fonctionnalité | Noyau minimum | Recommandé |
|---|---|---|
| eBPF basique | 4.4 | 5.10+ |
| Support BTF | 5.2 | 5.10+ |
| Crochets LSM | 5.7 | 5.15+ |
| Jetons BPF | 6.9 | 6.9+ |
| Tampon d'anneau | 5.8 | 5.10+ |
La plupart des services Kubernetes gérés du fournisseur cloud (EKS, GKE, AKS) exécutent des noyaux qui supportent tous les fonctionnalités modernes d'eBPF. Les déploiements sur site devraient cibler le noyau 5.10 ou plus tard pour la meilleure compatibilité.
Considérations de performance
La surveillance eBPF ajoute une surcharge minimale, mais « minimale » n'est pas « zéro » :
- Surcharge CPU : Généralement 1-2 % pour la surveillance complète (réseau, processus, fichier, profilage)
- Utilisation mémoire : 50-200 MB par nœud pour l'agent, selon la cardinalité
- Surcharge réseau : Les métriques et événements sont expédiés à un serveur central ; l'utilisation de bande passante dépend de la taille du cluster et de l'activité
- Stockage : ClickHouse (utilisé par Coroot) ou Prometheus (utilisé par beaucoup d'outils) nécessite du stockage proportionnel au nombre de services et à la période de rétention
Pour la plupart des environnements, ces surcharges sont négligeables par rapport à la visibilité gagnée. Cependant, les systèmes de trading haute fréquence, le traitement audio/vidéo en temps réel et les autres charges de travail critiques pour la latence doivent évaluer les outils eBPF avec soin avant le déploiement en production.
La convergence de la sécurité et de l'observabilité
La tendance la plus significative dans l'écosystème eBPF est la convergence de la sécurité et de l'observabilité en plateformes unifiées. Historiquement, c'étaient des disciplines séparées avec des outils séparés, des équipes séparées et des budgets séparés. eBPF efface la frontière technique.
Quand un seul agent au niveau du noyau capture les connexions réseau, l'exécution des processus, l'accès fichier et les modèles d'appels système, les mêmes données servent les deux objectifs :
- Observabilité : « La latence du service A à la base de données a augmenté de 200 ms après le dernier déploiement »
- Sécurité : « Un processus inattendu s'est lancé dans le conteneur du service A et a établi une connexion sortante vers une IP inconnue »
Les deux observations proviennent de la même source de données eBPF. La différence est dans la façon dont les données sont analysées et les actions déclenchées. Cette convergence réduit la prolifération d'agents (un agent au lieu de trois ou quatre), élimine la duplication de données et active la corrélation qui était auparavant impossible — comme lier un événement de sécurité à son impact de performance en temps réel.
Les outils comme Coroot incarnent déjà cette convergence, fournissant des tableaux de bord d'observabilité aux côtés du suivi SLO et de la détection d'anomalie. Cilium et Tetragon ensemble fournissent la mise en réseau, l'observabilité et l'application de sécurité à partir d'une plateforme unique. Attendez-vous à ce que cette convergence s'accélère à mesure que l'écosystème mûrit.
Conclusion : La nouvelle couche d'infrastructure
eBPF a évolué d'une fonctionnalité du noyau Linux à une couche d'infrastructure fondationnelle. C'est la technologie derrière la mise en réseau chez la plupart des principaux fournisseurs de cloud pour les offres Kubernetes. Elle alimente les plateformes d'observabilité qui ont remplacé les agents APM traditionnels. Elle applique les politiques de sécurité qui protègent les conteneurs à l'exécution.
Pour les équipes d'ingénierie, le message pratique est simple : si vous exécutez des charges de travail Linux — en particulier dans Kubernetes — les outils basés sur eBPF devraient faire partie de votre pile d'infrastructure. L'observabilité que vous gagnez sans aucun changement de code est remarquable. L'application de sécurité que vous pouvez ajouter sans modifications d'application est transformatrice. Et la convergence des deux capacités en plateformes unifiées simplifie les opérations de façons que les piles d'outils séparés n'ont jamais pu.
Commencez par l'observabilité. Ajouter l'application de sécurité graduellement. Laisser le noyau faire le travail que vous avez demandé à vos applications de faire. Les résultats en vaudront la peine.