Capturer sélectivement des paquets réseau sans tout transmettre vers l’espace utilisateur : telle fut la première raison d’être de BPF (Berkeley Packet Filter). C’était dans les années 90, sur les systèmes UNIX-BSD. La technologie permettait, à l’appui d’un jeu d’instructions virtuel RISC-like et d’un interpréteur, d’injecter des programmes dans le noyau pour en étendre les capacités à l’exécution.

Les premiers usages au-delà du réseau avaient émergé au début des années 2010. À commencer par l’outil seccomp-bpf, servant à filtrer les syscalls. Les travaux de modernisation lancés dans ce contexte aboutirent à eBPF (extended BPF). Cette nouvelle incarnation fut intégrée à Linux en 2014. À la clé, entre autres, des instructions et des structures de données supplémentaires, davantage de registres, un compilateur JIT et des points d’attache additionnels pour les programmes. La promesse demeurait : apporter de l’extensibilité au kernel sans passer par des modules ou changer le code source.

Sur ce socle, des projets sont d’abord nés dans le domaine du traçage. Des couches d’abstraction ont pris corps en parallèle, comme la boîte à outils BCC (BPF Compiler Collection), associant front-end Python/Lua et back-end C pour faciliter l’écriture de programmes. Tandis que le compilateur fut intégré dans LLVM.

Cilium, une couche d’abstraction devenue référente

Facebook fut l’un des premiers à industrialiser eBPF, avec un équilibreur de charge L4 pour ses datacenters : Katran, aujourd’hui open source. La possibilité d’attacher eBPF très en amont sur le chemin de réception – en l’occurrence, au niveau du piote NIC – permet d’effectuer le load balancing à la source, sans NAT (paquets traités avant interception par le noyau).

Google a quant à lui contribué à faire avancer les choses dans le champ de la sécurité. Dans le cadre de l’extension de son offre Kubernetes vers les infrastructures sur site (sous les marques Anthos et GDC), il a donné naissance au framework BPF LSM. Celui-ci adapte le principe des modules de sécurité à l’écosystème eBPF, en permettant d’utiliser les mêmes hooks (points d’attache) que SELinux.

Pour rendre la technologie plus accessible, le projet Cilium fut lancé en 2016. Avec, pour le porter, une société aujourd’hui référente dans l’écosystème eBPF : Isovalent, qui appartient à Cisco depuis 2024. Il assurait initialement la mise en réseau de conteneurs. Dans ces environnements où les adresses IP tournent beaucoup, ses tables de hachage en ont fait une alternative plus « élastique » à Iptables/netfilter.

Et vint l’observabilité

Après la mise en réseau vint l’observabilité, favorisée par la multiplicité des points d’attache exploitables. En plus de ceux prédéfinis (appels système, entrées/sorties de fonctions, tracepoints…), on peut utiliser des sondes noyau (kprobes) et utilisateur (uprobes). Mais aussi des fonctions arbitraires, en les étiquetant. L’exécution est orientée événements : les programmes eBPF se déclenchent lorsque le noyau ou une application passe par ces hooks.

Ce modèle ouvre la porte à la collecte de données sans instrumentation (pas de modification du code des applications ou des agents d’observabilité) et consommant potentiellement moins de ressources système. Cilium l’implémente via une plate-forme intégrée : Hubble, qui cartographie les services et donne une visibilité des flux grâce aux identités de workloads. Il y a ajouté une brique pour sécuriser l’exécution : Tetragon, qui met en œuvre des politiques de contrôle d’accès sur les fonctions noyau, les syscalls, etc.

S’économiser l’instrumentation… dans certains cas

Datadog aussi a un usage assez transversal d’eBPF : analyse de performance des applications (Universal Service Monitoring), visibilité sur le trafic réseau (Cloud Network Monitoring), détection des menaces (Workload Protection), supervision d’intégrité des fichiers (application de règles pour limiter les envois)…

« Sans eBPF, on aurait probablement besoin de consentir un effort de modification de la configuration des agents », fait remarquer Pejman Tabassomi, Field CTO EMEA, concernant le monitoring réseau. Sur la partie APM (surveillance des performances des applications), l’approche traditionnelle d’instrumentation « permet d’aller loin dans les détails, mais c’est contraignant parce qu’on est dépendant d’un framework ou d’un runtime », explique l’intéressé. eBPF « permet d’arriver à un objectif par tout à fait identique mais comparable, sans avoir à recourir à une librairie », déclare-t-il.

Pas tout à fait identique, donc. « Il y a une sorte de compromis entre le niveau d’introspection et la facilité de mise en œuvre », résume Pejman Tabassomi. Il l’illustre par un cas d’observation des temps de réponse entre deux services. Pour mesurer le nombre et la durée des appels, eBPF peut suffire. En revanche, s’il y a besoin de comprendre les lignes de code qui peuvent poser problème, les appels de fonctions et de méthodes qui sont en cause, « à ce moment-là, on va plutôt faire de l’APM. » Non sans surveiller des initiatives communautaires tel le profiler de code en cours de développement dans l’univers OpenTelemetry.

Chez Splunk, « l’histoire avec eBPF a démarré lors du rachat de Flowmill » en 2020, fait savoir Stéphane Estevez, EMEA Market Advisor pour l’observabilité. Cet outil de monitoring réseau a alimenté la stratégie « full OpenTelemetry » de l’éditeur. « Être chez Cisco nous a donné l’accès à Isovalent pour l’observabilité et la sécurité », précise Stéphane Estevez. Tetragon, par exemple, alimente des dashboards TCP et DNS dans la composante Network Explorer.

Chez IBM, Instana est le principal terrain d’implémentation d’eBPF. La technologie présente une utilité particulière pour la détection des crashs système, selon Éric Cattoir, membre d’une équipe au niveau EMEA qui couvre les sujets regroupés sous la bannière IT Automation. En écho à Pejman Tabassomi, il déclare, sur le volet instrumentation : « Ça rend la vie plus facile pour notre produit : on a moins à suivre l’évolution des technologies (nouvelles versions de langages, de compilateurs…) ». Instana a toujours eu une approche d’auto-instrumentation, rappelle-t-il, « mais c’est difficile à mettre en place pour certains langages : eBPF facilite cela en permettant d’obtenir de manière standard des informations de profilage ».

On trouve aussi de l’eBPF dans le produit SevOne (observabilité réseau), pour la couche overlay de Kubernetes.

Des programmes composables et portables

Avec les années, les programmes eBPF sont devenus composables : ils peuvent appeler des fonctions (forme de gosub)… et d’autres programmes en remplaçant le contexte d’exécution (goto). Un mécanisme CO-RE (« Compile Once, Run Everywhere ») a été instauré à partir d’un format spécifique de métadonnées (BTF, BPF Type Format) pour procurer une portabilité entre les versions du kernel. Et des passerelles se sont créées avec l’espace utilisateur, à travers une des structures de données que gère eBPF : les magasins clé-valeur dits maps. Des outils sont par ailleurs apparus pour exécuter des programmes en userspace (rBPF, uBPF, bpftime). Ils ont accompagné l’émergence de langages de jaut niveau tel bpftrace – inspiré de DTrace, avec LLVM en back-end et BCC pour interagir avec le sous-système eBPF.

Sauf à activer le mode sans privilèges avec accès limité au noyau, les processus qui chargent des programmes eBPF doivent s’exécuter en mode admin ou avoir la capacité CAP_BPF. La mémoire est protégée en lecture seule et les accès sont masqués pour limiter les effets secondaires observables de l’exécution spéculative. Si une entité tente de modifier le programme, le noyau plante.

Le code passe dans tous les cas par un vérificateur statique. Lequel contrôle, en particulier, que le programme est d’une complexité finie, qu’il se terminera bien et qu’il n’entraînera pas de deadlock ni d’accès mémoire hors limites. Dans la pratique, l’outil reste sujet aux faux positifs. Jusqu’à Linux 5.3, les boucles étaient d’ailleurs proscrites dans les programmes eBPF, le vérificateur étant jugé capable de les évaluer efficacement.

Une fondation où convergent les Big Tech

Depuis 2021, il existe une Fondation eBPF. Google, Meta et Isovalent en sont membres platine. CrowdStrike – qui exploite la techno pour détecter les mouvements de données non autorisés – l’est aussi. Ainsi que Huawei, Intel, Microsoft – qui développe eBPF pour Windows tout en l’exploitant en remplacement du fournisseur d’événements AuditD dans Defender pour Linux – et Red Hat. Datadog est membre argent. Netflix, qui avait pris très tôt le train eBPF, l’est aussi.

Conjointement aux initiatives du marché, cette fondation soutient des projets académiques, à l’instar d’eBPF Governor, alternative aux sous-systèmes de gestion de l’alimentation sur Linux. Des recherches sont également en cours sur la vérification formelle des programmes, en complément à la réécriture du vérificateur en Rust.

Plusieurs projets devenus référents dans l’écosystème eBPF sont maintenant sous l’aile de la CNCF (Cloud Native Computing Foundation). Outre Cilium, on peut citer Falco (détection de menaces), confié en 2018 par Sysdig. Dans le champ de l’observabilité, il y a Pixie, que New Relic a reversé à la CNCF en 2021, quelques mois après en avoir fait l’acquisition (il en propose aujourd’hui une version SaaS).

Pièce maîtresse du réseau mondial de Cloudflare, eBPF a aussi investi les clouds hyperscale. À l’instar de Google sur GKE, AWS s’en sert sur son Kubernetes managé (Caretta pour la cartographie réseau, Hubble pour l’analyse du trafic). Il l’a aussi intégré dans CloudWatch (composante Network Flow Monitor) et de GuardDuty (EC2 Runtime Monitoring). Microsoft l’exploite pour contourner Iptables sur les data planes de offre AKS (Azure Kubernetes Services).

Pour le monitoring, Dynatrace a choisi de s’appuyer sur Inspektor Gadget, framework CNCF qui encapsule les programmes eBPF sous forme d’images OCI. Il le met à contribution dans un module de découverte de services.

Chez Elastic, eBPF alimente le profilage continu, ainsi que la protection de Linux et de Kubernetes dans le cadre de l’offre SIEM/XDR.

Illustration principale © kwanchaift – Adobe Stock

The post Observabilité : eBPF, un atout dans la main des DevOps appeared first on Silicon.fr.

"Merde, le port 8080 est squatté par quoi encore ???"

Si vous touchez un peu à l'auto-hébergement ou que vous gérez plus de trois services sur un serveur, vous avez forcément déjà hurlé cette phrase devant votre terminal. C'est le grand classique... on lance un nouveau conteneur, ça plante, et on finit par passer 20 minutes à faire des netstat ou des lsof pour comprendre qui fait la loi sur le réseau. Bref, c'est le bordel, et c'est exactement là que Portracker entre en scène pour nous sauver la mise.

Développé par Mostafa Wahied, Portracker n'est pas un énième scanner de ports réseau agressif façon Nmap, mais plutôt une vigie interne pour vos machines. C'est un outil auto-hébergé qui va scanner son propre hôte pour cartographier en temps réel (enfin, avec un rafraîchissement périodique réglable, généralement toutes les minutes) tous les services qui tournent et les ports qu'ils occupent. L'idée, c'est d'avoir une vue propre et centralisée pour dégager ce vieux tableur Excel que vous oubliez de mettre à jour une fois sur deux.

Le truc est super bien foutu, surtout pour les fans de Docker. Pour ceux qui se demandent comment ça se passe sous le capot, l'outil fait intelligemment la distinction entre les ports internes d'un conteneur et ceux qui sont réellement exposés sur l'hôte.

Alors oui, ça marche comment pour mapper tout ça ? En gros, ça utilise les API natives pour voir que votre instance Ghost est sur le 2368 en interne mais ressort sur le 8080 à l'extérieur. C'est le genre de truc qui évite bien des migraines quand on commence à empiler 50 conteneurs. Il y a même un support aux petits oignons pour TrueNAS pour les amateurs de NAS costauds.

Côté dashboard, c'est du propre puisqu'on est sur une interface moderne avec React, Tailwind et Shadcn UI, avec un mode sombre (évidemment) et des filtres en live qui répondent au quart de tour.

Mais la vraie force de Portracker, c'est sa capacité à bosser en meute. Vous pouvez connecter plusieurs instances entre elles via un système de "Peers" (en peer-to-peer donc) pour tout centraliser sur un seul tableau de bord. Pratique si vous avez un serveur chez vous, un VPS chez OVH et une vieille machine qui traîne dans un placard. Vous pouvez même organiser ça avec une hiérarchie parent-enfant pour mapper vos machines virtuelles sous leurs hôtes physiques respectifs.

Techniquement, c'est du solide mais ça reste léger : du Node.js avec Express et des WebSockets pour le backend, et une base SQLite (via better-sqlite3) embarquée pour ne pas avoir à se fader la conf d'une base externe. Pour le déploiement, ça se passe via Docker et pour les paranos de la sécurité (je vous vois ^^), sachez que l'outil supporte désormais l'utilisation d'un Docker Socket Proxy (genre celui de Tecnativa). Ça permet d'éviter de filer les droits root sur votre socket Docker à n'importe qui. Et depuis la version 1.2.0, vous pouvez même verrouiller l'accès avec une vraie authentification.

Notez que pour fonctionner correctement et aller fouiller dans les entrailles du système, l'outil a besoin de certaines permissions (les fameuses capabilities Linux). Il lui faudra généralement SYS_PTRACE, et éventuellement SYS_ADMIN si vous le faites tourner sur Docker Desktop ou macOS. C'est le prix à payer pour avoir une visibilité totale sur ce qui se passe dans les tuyaux.

Le projet cartonne pas mal sur GitHub et la communauté est super active donc si vous en avez marre de jouer à cache-cache avec vos ports, c'est clairement l'outil qu'il vous faut pour reprendre le contrôle de vos déploiements sans finir en PLS à chaque conflit de port 80. Et si jamais vous stressez sur la sécurité de vos ports Docker, n'oubliez pas qu'on peut aussi jouer avec les règles iptables pour blinder tout ça, mais ça, c'est une autre histoire !

Merci à AeroStream972 pour la découverte !

Bon, faut qu’on cause ! Il existe aujourd’hui beaucoup de distributions d’inspiration ou conçues depuis le début sur ce qu’on appelle l’immuabilité (on est en France, on parle français, Rognotudju !). Découvrons Talos, cette nouvelle distribution dédiée au déploiement et à la gestion de clusters Kubernetes … L’immuabilité est le terme à la mode depuis […]

Devinette du soir : Qu’est-ce qui est pire qu'un secret que vous avez oublié de cacher ?

Réponse : Des dizaines, des millions de secrets qui traînent sur GitHub parce que quelqu'un a eu la flemme de configurer un vrai gestionnaire de variables d'environnement !

Hé oui, les amis ! On a tous fait cette boulette au moins une fois (ou alors vous mentez, ou vous êtes un robot). On crée un petit fichier .env, on oublie de le rajouter au .gitignore, et paf, vos clés AWS se retrouvent à poil. Selon GitHub, c'est plus de 39 millions de secrets qui ont été détectés en fuite sur leurs dépôts en 2024. C'est du délire !

Envmap - Le gestionnaire de variables d'environnement qui tue les fichiers .env ( Source )

Du coup, au lieu de continuer à se farcir du bricolage avec des fichiers qui traînent en clair sur le disque, je vous propose de jeter un œil à Envmap .

C'est un outil écrit en Go dont l'objectif est de réduire au maximum l'écriture de vos secrets sur le disque dur. En mode normal, il va les pomper directement chez les grands manitous du stockage sécurisé comme AWS Secrets Manager, HashiCorp Vault, 1Password ou encore Doppler (même si pour l'instant, certains de ces providers sont encore en cours d'intégration).

Comme ça, au lieu de faire un vieux source .env qui laisse traîner un fichier sensible, vous lancez votre application avec envmap run -- node app.js. L'outil récupère les variables en RAM et les injecte dans le process. C'est propre, c'est net, et ça évite surtout de pousser par erreur votre config sur un repo public.

Pour ceux qui se demandent s'il faut quand même envoyer ses fichiers .env sur GitHub (spoiler : non, jamais !), Envmap propose une commande import pour ingérer vos vieux secrets. Et pour ceux qui ont besoin d'un stockage local, sachez qu'Envmap peut aussi chiffrer vos variables en AES-256-GCM, ce qui est quand même plus sérieux qu'un fichier texte lisible par n'importe qui. Notez aussi qu'il existe une commande sync si vous avez vraiment besoin de générer un fichier .env temporaire.

Perso, ce que je trouve vraiment cool, c'est l'intégration avec direnv. On rajoute une ligne dans son .envrc, et hop, les secrets sont chargés automatiquement quand on entre dans le dossier du projet. C'est magique et ça évite les crises cardiaques au moment du push.

D'ailleurs, si vous voulez aller plus loin dans la sécurisation de vos outils, je vous recommande de lire mon article sur SOPS ou encore ma réflexion sur l'usage de GitLab pour vos projets sensibles.

Bref, c'est open source (sous licence Apache 2.0), et avec ça, vous dormirez sur vos deux oreilles !

-- Article en partenariat avec Cloud Native Days --

Salut les copains !

Aujourd'hui j'ai envie de vous filer un petit rencard qui va plaire à tous ceux qui aiment l'infra, le dev et surtout l'esprit communautaire autour de tout ça. En effet, Aurélien, un fidèle lecteur, m'a envoyé un petit message pour me parler d'un événement qui se prépare et comme ça a l'air d'envoyer du bois, je relaie.

Ça s'appelle les Cloud Native Days France 2026 et c'est que c'est organisé par une équipe de 15 bénévoles (des vrais passionnés, pas des robots du marketing) et porté par une structure à but non lucratif. Selon les organisateurs, ils attendent plus de 2000 personnes le mardi 3 février 2026 au CENTQUATRE-PARIS (le fameux 104 pour les intimes ^^).

Alors autant vous dire qu'une bonne partie de la scène tech française va débarquer !

Au programme, on oublie le bullshit commercial et les présentations PowerPoint de 50 slides pour vous vendre un abonnement cloud hors de prix et on part sur de l'expertise pointue, du DevOps, du Cloud Native et bien sûr du gros morceau d'Open Source. Je vous parle de vrais RETEX (retours d'expérience) et de mecs qui savent de quoi ils parlent quand ils évoquent Kubernetes, le Platform Engineering ou la sécurité des infras.

Bref, enfin du concret pour vos méninges !

Il y aura aussi un village communautaire qui va mettre en avant des projets open source, des communautés vertueuses et des passionnés qui partagent leur savoir via des blogs ou des chaînes YouTube. C'est une ambiance que j'adore, car on peut discuter bidouille sans se faire harceler par un commercial en costume.

Voilà, donc si ça vous branche de venir apprendre des trucs ou juste de croiser du beau monde dans un lieu super sympa, je vous conseille de jeter un œil au programme complet. C'est une super occasion de sortir de son terminal et de voir du monde en vrai.

Bref, un grand bravo à Aurélien et toute son équipe de bénévoles pour le boulot.

Ça va être top !

Le programme et la billetterie sont là !

Il y a pratiquement 3 ans, jour pour jour (cela a vraiment démarré en novembre 2022), j’ai découvert un nouveau monde… Kubernetes et son orchestre (au moins philharmonique).

— Permalink