Lors de l'implémentation des fonctionnalités de sécurité, d’accès réseau et d’observabilité, travailler dans le kernel Linux est idéal, mais présente certains défis. Qu'il s'agisse de modifier un code source du kernel ou d'ajouter des modules, les développeurs se trouvent souvent confrontés à des couches d’infrastructures et d’abstraction difficiles à déboguer. Heureusement, Extended BPF (eBPF) permet de résoudre ces problèmes.
eBPF (Extended Berkeley Packet Filter) est une technologie kernel (lancée dans Linux 4.x) qui permet aux programmes d'être exécuté sans devoir modifier le code source du kernel ni ajouter de modules supplémentaires. Il s'agit en quelque sorte d'une machine virtuelle (VM) sandbox légère dans le kernel Linux sur laquelle les développeurs peuvent exécuter du bytecode BPF utilisant des ressources spécifiques du kernel.
L'utilisation d'eBPF élimine le besoin de modifier le code source du kernel et simplifie l'exploitation des couches existantes par les logiciels. Résultat : une technologie puissante dont le potentiel peut changer fondamentalement la manière dont sont assurés les services (réseau, observabilité et sécurité).
Nous vous proposons plus de détails sur ce qu’est l'eBPF, comment il fonctionne et quand envisager son implémentation.
Fonctionnement d'eBPF
Les programmes eBPF sont pilotés par les événements et associés à un chemin de code. Ce dernier contient des déclencheurs particuliers, appelés « hooks », qui exécutent tous les programmes eBPF associés dès qu'ils les trouvent. Exemples de hooks : événements réseau, appels système, entrées de fonctions et points de trace du kernel.
Lorsqu'il est déclenché, le code est compilé d'abord vers le bytecode BPF. Le bytecode est ensuite inspecté avant d'être exécuté pour vérifier qu'il ne crée aucune boucle. Cette étape empêche que le programme ne compromette, accidentellement ou volontairement, le kernel Linux.
Lorsqu'un programme est déclenché au niveau d'un hook, il passe des appels d'assistance. Ces appels sont des fonctions qui dotent eBPF de nombreuses fonctionnalités lui permettant d'accéder à la mémoire. Ils doivent être prédéfinis par le kernel, mais la liste des fonctionnalités qui existent ne cesse de s'allonger.
Au début, eBPF était utilisé pour apporter une plus grande observabilité et sécurité lors du filtrage des paquets réseau. Il a toutefois évolué dans le temps et est aujourd'hui un moyen de rendre l'implémentation du code fourni par l'utilisateur plus sûre, plus pratique et plus performante.
Avantages d'eBPF
eBPF est généralement utilisé pour tracer les processus dans l'espace utilisateur et c'est là qu'il présente les plus gros avantages. Il s'agit d'une méthode sûre et pratique qui permet d'assurer :
- Rapidité et la performance. eBPF peut déplacer le traitement des paquets de l'espace du kernel vers l'espace de l'utilisateur. De même, eBPF est un compilateur juste-à-temps (JIT). Une fois le bytecode compilé, eBPF est invoqué à la place d'une nouvelle interprétation du bytecode pour chaque méthode.
- Faible intrusion. Quand il est utilisé en tant que débogueur, eBPF n'a pas besoin d'arrêter un programme pour observer son état.
- Sécurité. Les programmes sont effectivement placés dans le sandbox, ce qui signifie que le code source du kernel reste protégé et inchangé. L'étape de vérification garantit que les ressources ne sont pas affaiblies par des programmes qui exécutent des boucles interminables.
- Facilité d'utilisation. La création du code permettant aux hooks d'accrocher les fonctions du kernel demande moins de travail que le développement et la maintenance des modules du kernel.
- Tracing unifié. eBPF vous apporte un framework unique, puissant et accessible pour les processus de tracing, ce qui augmente la visibilité et la sécurité.
- PogrammabilitéL'utilisation d'eBPF aide à améliorer la richesse des fonctionnalités d'un environnement sans ajouter de couches supplémentaires. De même, le code étant exécuté directement dans le kernel, il est possible de stocker les données entre les événements eBPF au lieu de les purger comme le font les autres traceurs.
- Expressivité. eBPF est expressif, capable d'exécuter des fonctions qui se trouvent généralement dans les langages de haut niveau.
Meilleures pratiques eBPF
eBPF étant une nouvelle technologie, il reste encore beaucoup à découvrir et les meilleures pratiques ne cessent d'évoluer. Pour l'instant, il n'existe pas de meilleures pratiques clairement définies, mais vous pouvez prendre quelques mesures pour assurer l'efficacité et la performance des programmes.
Si vous utilisez eBPF dans votre écosystème, nous vous recommandons les pratiques suivantes :
- Utilisez LLVM Clang pour compiler C en bytecode. Au tout début d'eBPF, il fallait coder et assembler le programme manuellement. Les développeurs ont ensuite utilisé l'assembleur du kernel pour générer le bytecode. Mais heureusement, tout cela n'est plus nécessaire. Clang fournit l'infrastructure pour le frontend et les outils dans les langages C.
- Utilisez la boîte à outils BCC lors du développement de programmes BPF. La collection de compilateur BPF, BCC (BPF Compiler Collection), est une boîte à outils qui peut vous aider à créer le tracing efficace du kernel et des programmes de manipulation. BCC convient particulièrement aux tâches associées à l'analyse des performances et au contrôle du trafic réseau.
Difficultés rencontrées avec eBPF
Bien que puissant, eBPF ne convient pas à tous les projets ni à tous les écosystèmes. Il présente quelques inconvénients importants qui peuvent s'avérer frustrants dans certains cas. Certains développeurs jugeront eBPF inadéquat pour les raisons suivantes :
- Il est limité à l'environnement Linux et à un kernel récent. eBPF a été développé dans le kernel Linux et lui est complètement dédié. Il est ainsi moins transférable que les autres traceurs. En outre, il vous faut un kernel relativement récent. Si vous exécutez quoi que ce soit prédatant v 4.13, vous ne pourrez pas l'utiliser.
- Les programmes dans le sandbox subissent des restrictions. eBPF obtient une plus grande sécurité en limitant les ressources auxquelles les programmes ont accès. Mais cela signifie aussi qu'en limitant à quelle partie du système d'exploitation un programme a accès, on restreint également la fonctionnalité.
Bon fonctionnement d'eBPF
eBPF gagne rapidement du terrain avec les applications cloud natives, et en conséquence, il est le plus souvent utilisé dans deux situations :
- Quand il y a un besoin d'observabilité avec tracing du kernel. Dans ce cas, eBPF est plus rapide et précis. Il n'y a pas de changement de contexte et les programmes eBPF sont pilotés par les événements ce qui fait que rien n'est exécuté sans un déclencheur particulier et aucune occurrence n'est ratée.
- Quand le monitoring de sécurité classique ne fonctionne pas. eBPF est très utilisé dans les environnements distribués et conteneurisés, notamment Kubernetes. Là, il peut combler le manque de visibilité en faisant apparaître le trafic HTTP.
eBPF peut également être déployé pour d'autres mesures de sécurité, par exemple :
- Pare-feu
- Pilotes de périphériques
- Monitoring de la performance réseau
New Relic et eBPF
Pixie (acquis par New Relic), est une plateforme d'observabilité open source kubernetes native dans le cluster qui apporte la visibilité instantanée dans les workloads Kubernetes sans aucune instrumentation manuelle. eBPF assure une grande partie de la puissance qui se cache derrière la plateforme Pixie. Comme nous l'avons expliqué plus haut, eBPF vous permet d'exécuter un code restreint lors du déclenchement d'un événement. Cet événement peut être un appel de fonction dans le kernel space(kprobes) ou userspace(uprobes). Pixie utilise uprobes et kprobes pour obtenir l'observabilité sur tous les services et applications.
Pixie collecte automatiquement les données de télémétrie en se servant d'eBPF, et son intelligence machine hors pair connecte ces données aux métadonnées Kubernetes afin d'assurer la visibilité tout en conservant la localisation des données. Cette visibilité vient compléter la puissante solution d'observabilité Kubernetes de New Relic. Et en mai, vous pourrez envoyer des données télémétriques générées par Pixie vers New Relic One, ce qui vous permettra de gagner ainsi une rétention évolutive, de puissantes visualisations, une corrélation avancée et des fonctionnalités d'alerte intelligentes.
eBPF : l'observabilité efficace
eBPF est une nouvelle technologie qui améliore l'observabilité, le réseau et la sécurité dans le kernel Linux. Il élimine le besoin de modifier le code source du kernel ou d'ajouter des modules. Vous pouvez ainsi créer une infrastructure plus riche pour soutenir votre système sans le rendre trop complexe.
Nous avons examiné eBPF, son fonctionnement et son utilité dans les environnements distribués. Le monitoring à partir de la couche du kernel solutionne de nombreux défis associés à l'observabilité dans le cloud. Ainsi, vous approfondissez la visibilité, vous améliorez nettement la contextualisation, et vous obtenez une plus grande précision.
Lors de l'implémentation des fonctionnalités de sécurité, d’accès réseau et d’observabilité, travailler dans le kernel Linux est idéal, mais présente certains défis. Qu'il s'agisse de modifier un code source du kernel ou d'ajouter des modules, les développeurs se trouvent souvent confrontés à des couches d’infrastructures et d’abstraction difficiles à déboguer. Heureusement, Extended BPF (eBPF) permet de résoudre ces problèmes.
eBPF (Extended Berkeley Packet Filter) est une technologie kernel (lancée dans Linux 4.x) qui permet aux programmes d'être exécuté sans devoir modifier le code source du kernel ni ajouter de modules supplémentaires. Il s'agit en quelque sorte d'une machine virtuelle (VM) sandbox légère dans le kernel Linux sur laquelle les développeurs peuvent exécuter du bytecode BPF utilisant des ressources spécifiques du kernel.
L'utilisation d'eBPF élimine le besoin de modifier le code source du kernel et simplifie l'exploitation des couches existantes par les logiciels. Résultat : une technologie puissante dont le potentiel peut changer fondamentalement la manière dont sont assurés les services (réseau, observabilité et sécurité).
Nous vous proposons plus de détails sur ce qu’est l'eBPF, comment il fonctionne et quand envisager son implémentation.
Fonctionnement d'eBPF
Les programmes eBPF sont pilotés par les événements et associés à un chemin de code. Ce dernier contient des déclencheurs particuliers, appelés « hooks », qui exécutent tous les programmes eBPF associés dès qu'ils les trouvent. Exemples de hooks : événements réseau, appels système, entrées de fonctions et points de trace du kernel.
Lorsqu'il est déclenché, le code est compilé d'abord vers le bytecode BPF. Le bytecode est ensuite inspecté avant d'être exécuté pour vérifier qu'il ne crée aucune boucle. Cette étape empêche que le programme ne compromette, accidentellement ou volontairement, le kernel Linux.
Lorsqu'un programme est déclenché au niveau d'un hook, il passe des appels d'assistance. Ces appels sont des fonctions qui dotent eBPF de nombreuses fonctionnalités lui permettant d'accéder à la mémoire. Ils doivent être prédéfinis par le kernel, mais la liste des fonctionnalités qui existent ne cesse de s'allonger.
Au début, eBPF était utilisé pour apporter une plus grande observabilité et sécurité lors du filtrage des paquets réseau. Il a toutefois évolué dans le temps et est aujourd'hui un moyen de rendre l'implémentation du code fourni par l'utilisateur plus sûre, plus pratique et plus performante.
Avantages d'eBPF
eBPF est généralement utilisé pour tracer les processus dans l'espace utilisateur et c'est là qu'il présente les plus gros avantages. Il s'agit d'une méthode sûre et pratique qui permet d'assurer :
- Rapidité et la performance. eBPF peut déplacer le traitement des paquets de l'espace du kernel vers l'espace de l'utilisateur. De même, eBPF est un compilateur juste-à-temps (JIT). Une fois le bytecode compilé, eBPF est invoqué à la place d'une nouvelle interprétation du bytecode pour chaque méthode.
- Faible intrusion. Quand il est utilisé en tant que débogueur, eBPF n'a pas besoin d'arrêter un programme pour observer son état.
- Sécurité. Les programmes sont effectivement placés dans le sandbox, ce qui signifie que le code source du kernel reste protégé et inchangé. L'étape de vérification garantit que les ressources ne sont pas affaiblies par des programmes qui exécutent des boucles interminables.
- Facilité d'utilisation. La création du code permettant aux hooks d'accrocher les fonctions du kernel demande moins de travail que le développement et la maintenance des modules du kernel.
- Tracing unifié. eBPF vous apporte un framework unique, puissant et accessible pour les processus de tracing, ce qui augmente la visibilité et la sécurité.
- PogrammabilitéL'utilisation d'eBPF aide à améliorer la richesse des fonctionnalités d'un environnement sans ajouter de couches supplémentaires. De même, le code étant exécuté directement dans le kernel, il est possible de stocker les données entre les événements eBPF au lieu de les purger comme le font les autres traceurs.
- Expressivité. eBPF est expressif, capable d'exécuter des fonctions qui se trouvent généralement dans les langages de haut niveau.
Meilleures pratiques eBPF
eBPF étant une nouvelle technologie, il reste encore beaucoup à découvrir et les meilleures pratiques ne cessent d'évoluer. Pour l'instant, il n'existe pas de meilleures pratiques clairement définies, mais vous pouvez prendre quelques mesures pour assurer l'efficacité et la performance des programmes.
Si vous utilisez eBPF dans votre écosystème, nous vous recommandons les pratiques suivantes :
- Utilisez LLVM Clang pour compiler C en bytecode. Au tout début d'eBPF, il fallait coder et assembler le programme manuellement. Les développeurs ont ensuite utilisé l'assembleur du kernel pour générer le bytecode. Mais heureusement, tout cela n'est plus nécessaire. Clang fournit l'infrastructure pour le frontend et les outils dans les langages C.
- Utilisez la boîte à outils BCC lors du développement de programmes BPF. La collection de compilateur BPF, BCC (BPF Compiler Collection), est une boîte à outils qui peut vous aider à créer le tracing efficace du kernel et des programmes de manipulation. BCC convient particulièrement aux tâches associées à l'analyse des performances et au contrôle du trafic réseau.
Difficultés rencontrées avec eBPF
Bien que puissant, eBPF ne convient pas à tous les projets ni à tous les écosystèmes. Il présente quelques inconvénients importants qui peuvent s'avérer frustrants dans certains cas. Certains développeurs jugeront eBPF inadéquat pour les raisons suivantes :
- Il est limité à l'environnement Linux et à un kernel récent. eBPF a été développé dans le kernel Linux et lui est complètement dédié. Il est ainsi moins transférable que les autres traceurs. En outre, il vous faut un kernel relativement récent. Si vous exécutez quoi que ce soit prédatant v 4.13, vous ne pourrez pas l'utiliser.
- Les programmes dans le sandbox subissent des restrictions. eBPF obtient une plus grande sécurité en limitant les ressources auxquelles les programmes ont accès. Mais cela signifie aussi qu'en limitant à quelle partie du système d'exploitation un programme a accès, on restreint également la fonctionnalité.
Bon fonctionnement d'eBPF
eBPF gagne rapidement du terrain avec les applications cloud natives, et en conséquence, il est le plus souvent utilisé dans deux situations :
- Quand il y a un besoin d'observabilité avec tracing du kernel. Dans ce cas, eBPF est plus rapide et précis. Il n'y a pas de changement de contexte et les programmes eBPF sont pilotés par les événements ce qui fait que rien n'est exécuté sans un déclencheur particulier et aucune occurrence n'est ratée.
- Quand le monitoring de sécurité classique ne fonctionne pas. eBPF est très utilisé dans les environnements distribués et conteneurisés, notamment Kubernetes. Là, il peut combler le manque de visibilité en faisant apparaître le trafic HTTP.
eBPF peut également être déployé pour d'autres mesures de sécurité, par exemple :
- Pare-feu
- Pilotes de périphériques
- Monitoring de la performance réseau
New Relic et eBPF
Pixie (acquis par New Relic), est une plateforme d'observabilité open source kubernetes native dans le cluster qui apporte la visibilité instantanée dans les workloads Kubernetes sans aucune instrumentation manuelle. eBPF assure une grande partie de la puissance qui se cache derrière la plateforme Pixie. Comme nous l'avons expliqué plus haut, eBPF vous permet d'exécuter un code restreint lors du déclenchement d'un événement. Cet événement peut être un appel de fonction dans le kernel space(kprobes) ou userspace(uprobes). Pixie utilise uprobes et kprobes pour obtenir l'observabilité sur tous les services et applications.
Pixie collecte automatiquement les données de télémétrie en se servant d'eBPF, et son intelligence machine hors pair connecte ces données aux métadonnées Kubernetes afin d'assurer la visibilité tout en conservant la localisation des données. Cette visibilité vient compléter la puissante solution d'observabilité Kubernetes de New Relic. Et en mai, vous pourrez envoyer des données télémétriques générées par Pixie vers New Relic One, ce qui vous permettra de gagner ainsi une rétention évolutive, de puissantes visualisations, une corrélation avancée et des fonctionnalités d'alerte intelligentes.
eBPF : l'observabilité efficace
eBPF est une nouvelle technologie qui améliore l'observabilité, le réseau et la sécurité dans le kernel Linux. Il élimine le besoin de modifier le code source du kernel ou d'ajouter des modules. Vous pouvez ainsi créer une infrastructure plus riche pour soutenir votre système sans le rendre trop complexe.
Nous avons examiné eBPF, son fonctionnement et son utilité dans les environnements distribués. Le monitoring à partir de la couche du kernel solutionne de nombreux défis associés à l'observabilité dans le cloud. Ainsi, vous approfondissez la visibilité, vous améliorez nettement la contextualisation, et vous obtenez une plus grande précision.
Étapes suivantes
Installez Pixie et appréciez toute la puissance d'eBPF pour l'observabilité.
Les opinions exprimées sur ce blog sont celles de l'auteur et ne reflètent pas nécessairement celles de New Relic. Toutes les solutions proposées par l'auteur sont spécifiques à l'environnement et ne font pas partie des solutions commerciales ou du support proposés par New Relic. Veuillez nous rejoindre exclusivement sur l'Explorers Hub (discuss.newrelic.com) pour toute question et assistance concernant cet article de blog. Ce blog peut contenir des liens vers du contenu de sites tiers. En fournissant de tels liens, New Relic n'adopte, ne garantit, n'approuve ou n'approuve pas les informations, vues ou produits disponibles sur ces sites.
