eBPF permet d'exécuter vos propres petits programmes à l'intérieur du noyau Linux, en toute sécurité, sans le recompiler ni charger de module. Ce module s'adresse à l'administrateur système qui veut trois choses : comprendre ce qu'est un programme eBPF et comment le noyau le contrôle, tracer une machine en direct pour diagnostiquer un incident, et durcir un serveur pour que cette puissance ne devienne pas une porte d'entrée. Onze leçons, toutes testées en machine virtuelle : un programme noyau ne se teste pas dans un conteneur, qui partage le noyau de l'hôte. Trois d'entre elles se terminent par un lab à rejouer sur une VM.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Expliquer ce qu'est un programme eBPF, où il s'accroche et comment le noyau le vérifie
- Tracer un système en direct avec bpftrace et les outils BCC prêts à l'emploi
- Mesurer la surface d'attaque qu'eBPF ajoute à un serveur
- Durcir un serveur : sysctl, capacités, inventaire des programmes chargés
- Situer les outils eBPF de Kubernetes, qui vivent dans d'autres formations
Qu'est-ce qu'eBPF, en deux minutes ?
Section intitulée « Qu'est-ce qu'eBPF, en deux minutes ? »eBPF (extended Berkeley Packet Filter) est une machine virtuelle intégrée au noyau Linux. Elle exécute des programmes déclenchés par des événements du noyau : un appel système, un paquet réseau qui arrive, une fonction du noyau qui s'exécute. Le programme lit ce qui se passe, agit, puis renvoie un résultat, le tout sans quitter le noyau.
Trois propriétés en font une technologie à part. La vérification : avant le chargement, un composant du noyau, le vérificateur, prouve que le programme ne peut ni boucler à l'infini ni lire une mémoire interdite, sinon il est refusé. L'absence d'instrumentation : eBPF observe le système de l'extérieur du code observé, sans modifier l'application ni installer d'agent dans un conteneur. La performance : le programme s'exécute là où l'événement se produit, sans va-et-vient coûteux vers l'espace utilisateur.
Pourquoi ce module vient après les internals
Section intitulée « Pourquoi ce module vient après les internals »Ce module est un approfondissement, placé hors des trois niveaux de la formation Linux, après les leçons sur les mécanismes internes du noyau. Les trois qu'il suppose connus sont les cgroups, qui regroupent et limitent les processus, les namespaces, qui isolent ce qu'un processus voit, et les capabilities, qui découpent les pouvoirs de root.
La raison est pratique. Les programmes eBPF de systemd s'accrochent aux cgroups, les outils de sécurité décident par namespace et par conteneur, et la capacité CAP_BPF est l'un des leviers du durcissement. Sans ces trois notions, les sorties de bpftool et les recommandations de la dernière partie restent des formules à recopier. Le durcissement renvoie aussi à la leçon Durcir un serveur avec sysctl, qui pose les paramètres noyau que le module reprend.
Le fil des onze leçons
Section intitulée « Le fil des onze leçons »Le module suit une progression en trois temps, du modèle mental vers l'usage, puis vers le risque.
Comprendre pose le socle. La leçon eBPF, c'est quoi donne le modèle mental et les types de programmes. Écrire et charger son premier programme vérifie que votre noyau prend eBPF en charge, puis fait voir le cycle complet sur une machine. Les maps expliquent comment le noyau et l'espace utilisateur échangent des données, et le vérificateur comment lire un refus. La leçon CO-RE et BTF rend un programme portable ; elle est facultative pour un administrateur, car elle sert surtout à qui développe des outils.
Tracer met eBPF au travail pour diagnostiquer. bpftrace répond en une ligne à « que fait ma machine maintenant ? » et présente les outils BCC prêts à l'emploi (execsnoop, opensnoop, biolatency). BCC et libbpf montre comment construire ses propres outils ; elle est elle aussi facultative.
Durcir traite le revers de la médaille. La surface d'attaque d'eBPF, les rootkits eBPF et leur détection avec bpftool, puis durcir eBPF : qui peut charger un programme, avec quelles capacités, et comment auditer ce qui tourne.
Par où commencer ?
Section intitulée « Par où commencer ? »Le parcours dépend de votre besoin, et le module monte en difficulté : personne n'a besoin de tout lire d'un coup.
Si le sujet est nouveau, suivez l'ordre du module en commençant par eBPF, c'est quoi. Si vous voulez simplement voir eBPF fonctionner sans écrire une ligne de C, la voie la plus douce est bpftrace, qui suffit à diagnostiquer une machine lente. Si votre souci est la sécurité d'un serveur, lisez d'abord la surface d'attaque, puis le durcissement : ces leçons supposent seulement de savoir ce qu'est un programme eBPF.
Où vivent les outils eBPF de Kubernetes ?
Section intitulée « Où vivent les outils eBPF de Kubernetes ? »eBPF est la brique commune sous plusieurs outils que ce module ne traite pas, parce qu'ils appartiennent à d'autres formations. Les retrouver au bon endroit évite de dupliquer leurs guides.
Pour le réseau, Cilium est le CNI (la brique réseau d'un cluster Kubernetes) qui remplace en grande partie iptables par eBPF : voir Cilium, son observabilité avec Hubble, et la formation Kubernetes qui les porte. Pour la sécurité à l'exécution, Falco et Tracee détectent une action suspecte, Tetragon la bloque directement dans le noyau, et Falco ou Tetragon les compare sur le même cluster.
Pour l'observabilité dans Kubernetes, Inspektor Gadget rattache les événements tracés aux pods. Le profilage continu par eBPF (Parca, Pyroscope), qui garde un historique de l'usage du CPU, relève lui aussi de l'observabilité et reste hors de ce module : bpftrace sert à l'investigation ponctuelle, ces outils à la surveillance permanente.
Glossaire express
Section intitulée « Glossaire express »Les mêmes mots reviennent d'une leçon à l'autre. Voici leurs définitions courtes, à garder sous la main ; chaque terme est développé dans la leçon qui lui est dédiée.
| Terme | Définition courte |
|---|---|
| eBPF | Machine virtuelle du noyau qui exécute vos petits programmes, déclenchés par des événements. |
| bytecode | Le format intermédiaire, propre à eBPF, dans lequel votre C est compilé avant vérification. |
| hook | Le point de déclenchement où s'accroche un programme (voir kprobe, tracepoint, uprobe, XDP). |
| kprobe / tracepoint | Accroche sur une fonction du noyau (kprobe, dynamique) ou un point d'observation stable (tracepoint). |
| uprobe | Accroche sur une fonction d'un programme en espace utilisateur, pas du noyau. |
| helper | Fonction que le noyau met à disposition des programmes eBPF (lire le nom d'un processus, écrire dans une map...). |
| map | Structure de données du noyau, partagée avec l'espace utilisateur : la mémoire et la voix du programme. |
| vérificateur | Composant du noyau qui prouve qu'un programme est sûr avant de le charger, sinon il le refuse. |
| JIT | Compilateur qui traduit le bytecode vérifié en code machine natif, pour la performance. |
| BTF | Description des types du noyau (/sys/kernel/btf/vmlinux), la carte qui rend la portabilité possible. |
| CO-RE | Compile Once Run Everywhere : compiler un programme une fois et le charger sur des noyaux différents. |
À retenir
Section intitulée « À retenir »- eBPF exécute vos programmes dans le noyau Linux, déclenchés par des événements (appel système, paquet, fonction), sans module ni recompilation.
- Un vérificateur prouve qu'un programme est sûr avant de le charger : pas de boucle infinie, pas d'accès mémoire interdit.
- Le module suit trois temps : comprendre (socle), tracer (diagnostiquer), durcir (réduire le risque).
- Il suppose connus les cgroups, les namespaces et les capabilities, et reprend les paramètres de la leçon sysctl.
- CO-RE et BCC/libbpf sont des gestes de développeur d'outils : facultatifs pour un administrateur.
- Cilium, Falco, Tetragon et le profilage continu vivent dans d'autres formations ; eBPF y est la brique commune.