Si vous suivez les dernières tendances du cloud computing, vous avez sans doute croisé le terme eBPF à maintes reprises. Difficile de passer à côté. Voyons pourquoi.
À la recherche d'une solution moderne de sécurité, d'observabilité et de monitoring, sans sacrifier les performances ? eBPF est peut-être la réponse ! Cet article explore les raisons qui ont fait de cette fonctionnalité du noyau Linux l'un des principaux buzzwords de la stack cloud-native. Nous examinerons également une solution cloud populaire et prête à l'emploi reposant sur eBPF, et verrons comment elle peut renforcer la sécurité, l'observabilité et le monitoring de votre système cloud. Alors, faisons un peu de bruit autour de ce buzz !
Si vous connaissez déjà eBPF et souhaitez en savoir plus sur Cilium/Dataplane V2, passez directement à la Partie 2 !
eBPF relève de l'espace noyau Linux, un domaine que la plupart d'entre nous ne fréquente guère. Pourquoi quelqu'un qui évolue dans le cloud devrait-il alors s'intéresser à une fonctionnalité aussi bas niveau du noyau Linux ? Tout simplement parce qu'eBPF constitue une véritable révolution. Son impact est considérable, aussi bien sur les couches basses que sur les couches hautes.
Imaginons par exemple que vous souhaitiez écrire une logique personnalisée capable d'inspecter en détail tous les paquets réseau circulant entre vos conteneurs et de ne laisser passer que les paquets HTTP répondant à des critères précis.
Il est bien connu que pour fusionner, injecter ou limiter du trafic réseau, il faut opérer dans l'espace noyau. C'est dans le noyau Linux que l'on manipule le fonctionnement interne du système d'exploitation et son immense couche réseau, conçue pour la performance, la sécurité et la fiabilité.
Avant l'arrivée d'eBPF, il fallait écrire du code pour le noyau Linux (en langage C), soit en modifiant le code source du noyau, soit en développant un module noyau chargeable. Au-delà de la complexité inhérente, cette approche introduisait de nombreux risques, car un module noyau s'apparente à une bibliothèque dynamique (comme un fichier .DLL ou .so) rattachée au noyau.
Un bug critique dans votre code pouvait provoquer un kernel panic et faire tomber l'ensemble du système d'exploitation. En tant qu'utilisateur du cloud, et plus particulièrement si vous déployez des microservices via Kubernetes, les raisons d'éviter d'écrire du code noyau personnalisé sont nombreuses : sécurité, vélocité de développement, complexité, voire impossibilité liée à l'environnement. Bref, c'est disproportionné.
Et eBPF est arrivé 🐝
eBPF a fait son apparition et permet désormais d'injecter de la logique dans le noyau sans en modifier le code, autrement dit depuis l'espace utilisateur. Non seulement eBPF simplifie ce processus, mais il le rend aussi nettement plus sûr. Le processus de vérification d'eBPF garantit que le code eBPF chargé dans votre noyau peut s'exécuter en toute sécurité grâce à des contrôles stricts. Il vérifie et impose par exemple que :
- Votre code s'exécute de manière finie (pas de boucles infinies)
- Votre code ne plante pas et ne provoque pas de bugs fatals susceptibles d'endommager le système
- Le processus qui charge votre code eBPF dispose des privilèges requis
- La taille de votre code reste dans les limites autorisées
- Le code inaccessible est interdit
Au-delà du processus de vérification, certaines contraintes s'appliquent à votre code : eBPF vous oblige notamment à accéder à certaines ressources du noyau uniquement via des fonctions d'aide eBPF spécifiques. En résumé, eBPF apporte un filet de sécurité, une facilité de développement, un déploiement fluide et des performances accrues. De nombreux outils et moteurs tirent aujourd'hui parti de la technologie eBPF pour apporter de nouvelles fonctionnalités aux workloads cloud-native, de manière transparente et performante.
Pour voir eBPF en action, jetez un œil à cette vidéo .
Projets populaires propulsés par eBPF 🔋
- Cilium — Networking, sécurité et observabilité basés sur eBPF pour Kubernetes
- Falco — Sécurité runtime cloud-native
- Tracee — Sécurité runtime et forensics via eBPF
- Pixie — Plateforme de troubleshooting applicatif pour Kubernetes (à découvrir !)
J'espère que ces informations vous seront utiles. Cette liste recense d'autres projets propulsés par eBPF. Dans la Partie 2, nous explorerons Cilium comme solution eBPF de référence pour K8s et nous verrons ce que Dataplane V2 vient faire dans tout cela.
Merci de votre lecture ! Pour rester connecté, suivez-nous sur le DoiT Engineering Blog , le DoiT Linkedin Channel et le DoiT Twitter Channel . Pour découvrir nos opportunités de carrière, rendez-vous sur https://careers.doit-intl.com .