Zwindler's Reflection

Talos : un certificat en lecture seule qui reboot votre serveur

Tue, 03 Nov 2026 18:00:00 +0100

TL;DR

Sur Talos Linux <= 1.14.2, l’API TimeService/TimeCheck vérifiait les chemins de devices PTP avec un simple strings.HasPrefix(server, "/dev/"). Un .. suffisait donc à faire ouvrir n’importe quel fichier par machined, en root. On ne peut pas exfiltrer le fichier, juste le faire ouvrir.
Cette API était accessible au rôle os:reader, le rôle lecture seule qu’on distribue aux outils de monitoring.
Ouvrir /dev/watchdog arme le timer matériel. Refermer le fichier sans l’octet magique V le laisse armé. Si personne ne le nourrit : hard reset du serveur. Un compte read-only peut donc rebooter un serveur physique.
Publié le 19 octobre 2026 sous GHSA-vpfm-35qx-jhvw (Moderate, 5.9), corrigé dans 1.13.11 et 1.14.3. Et c’est mon premier advisory où je suis le seul finder crédité.

Contexte

Dans mon article précédent, je racontais comment je traque des vulnérabilités dans l’open source avec des LLM depuis cet été. Depuis, certaines de ces trouvailles sont devenues publiques : deux CVE Argo CD co-créditées avec 7 autres reporters chacune, une CVE KEDA en co-crédit. Il y en a d’autres en attente, mais la saveur n’est pas la même quand on n’est pas le “premier”.

Celle-ci est ma première GHSA en solo : un seul nom dans les credits, le mien (même si c’est Devin/SWE qui a en réalité fait la découverte initiale, cf. l’article précédent). Au-delà de la fierté personnelle, elle est aussi super marrante à raconter. Martial me fera les gros yeux car c’est “encore” un DoS (il m’a surnommé DoSnis), mais moi j’aime bien les DoS.

Elle est sortie d’un audit complet de Talos (la distribution Linux immuable dédiée à Kubernetes), pendant une passe où je cherchais une chose précise : quelles méthodes de l’API sont accessibles aux rôles les plus faibles, et qu’est-ce qu’elles font vraiment ?

Talos et ses rôles en deux minutes

Talos n’a pas de SSH, pas de shell, pas de package manager. Toute l’administration passe par une API gRPC (apid, port 50000), authentifiée par certificats clients. Le rôle est embarqué dans le certificat (champ O:). Du plus puissant au plus faible :

os:admin : tout, y compris reboot, wipe, machine config
os:operator : gestion courante (upgrade, reboot…)
os:reader : lecture seule. État du noeud, logs, métriques, configuration. C’est le rôle qu’on file aux dashboards, aux sondes, aux outils d’observabilité, en se disant “au pire, ils regardent”.

Sauf que TimeService/TimeCheck, l’API qui demande au noeud de vérifier sa synchro temporelle contre une source donnée, était ouverte aux trois rôles, reader compris (internal/app/machined/pkg/system/services/machined.go:160).

Sur le papier, ça se tient : interroger une source de temps, c’est de la lecture. Le hic, c’est que cette “source de temps” peut être soit un serveur NTP, soit un chemin de device PTP (Precision Time Protocol, les horloges matérielles /dev/ptp*).

Le bug : un `HasPrefix` qui ne protège rien

Voici l’intégralité du contrôle :

// internal/pkg/ntp/ntp.go
func IsPTPDevice(server string) bool {
 return strings.HasPrefix(server, "/dev/")
}

Oui, c’est tout. Pas de filepath.Clean, pas de rejet de .., pas de restriction à /dev/ptp*. Le handler (v1alpha1_time.go) passe ensuite la chaîne telle quelle à QueryPTPDevice, qui fait :

fd, err := os.Open(device) // machined tourne en root

Donc /dev/../dev/watchdog, /dev/../etc/shadow ou /dev/../dev/sda passent tous le filtre et sont ouverts en root par machined.

Première question qui vient : “OK, et il lit quoi ?”. Bah… rien. Le descripteur part dans des ioctls PTP, qui échouent sur tout ce qui n’est pas une horloge PTP, et le contenu n’est jamais renvoyé au client. On n’a pas de lecture de fichiers arbitraires.

Le problème est ailleurs : open() n’est pas une opération anodine.

`open()` n’est pas une lecture : le cas du watchdog

Un watchdog, c’est un minuteur matériel présent sur la plupart des serveurs : il redémarre la machine si l’OS ne donne plus signe de vie, typiquement en cas de freeze du kernel.

Sous Linux, ouvrir /dev/watchdog arme le watchdog matériel. C’est le contrat du driver : l’open lance le compte à rebours, et si personne ne vient écrire dedans régulièrement (“nourrir” le chien de garde), le matériel reset la machine. Pas de log applicatif, pas de shutdown propre, et l’OS n’a pas son mot à dire : c’est le hardware qui coupe.

Il existe une porte de sortie : écrire le caractère magique V dans le fichier avant de le fermer (le “magic close”), ce qui désarme le timer. Ici, Talos fait open(), les ioctls PTP échouent, puis close()… sans V. Le timer continue de tourner, personne ne le nourrit. Reboot.

Note : ça ne marche que si Talos n’a pas déjà ouvert le watchdog lui-même (pas de WatchdogTimerConfig dans la machine config, donc la grande majorité des cas). Autrement dit, ce sont précisément les noeuds qui n’utilisent pas le watchdog qui sont vulnérables : l’attaque l’arme, et personne n’est là pour le nourrir (pauvre chien-chien 🐶).

Repro sur mon lab

J’ai tout vérifié de bout en bout le 29 septembre 2026, sur mes noeuds Talos de lab, avec un talosconfig dont le certificat client est strictement O: os:reader.

D’abord, on vérifie que ce rôle ne peut pas rebooter par la voie normale :

talosctl -n <node-vm> reboot
# rpc error: code = PermissionDenied desc = not authorized

Ensuite, un test inoffensif pour prouver que la traversée passe :

talosctl -n <node-vm> time --check "/dev/../proc/version"
# rpc error ... error querying PTP device "/dev/../proc/version": invalid argument
# open() a reussi (le fichier existe), c'est l'ioctl PTP qui echoue

talosctl -n <node-vm> time --check "/dev/../nonexistent"
# rpc error ... "/dev/../nonexistent": no such file or directory
# open() a echoue : le fichier n'existe pas

Deux messages d’erreur différents, ça fait un oracle : on peut savoir si n’importe quel chemin existe sur le noeud, y compris hors de /dev. Et le .. qui apparaît tel quel dans l’erreur confirme au passage qu’il n’y a pas de filepath.Clean.

Maintenant, sur un serveur bare-metal avec un vrai watchdog matériel :

talosctl -n <node-bm> time --check "/dev/../dev/watchdog"
# rpc error ... invalid argument (open() en root OK, ioctl PTP en echec)

Et dans la console kernel, au même moment :

kern: crit: watchdog: watchdog0: watchdog did not stop!

C’est exactement le message qu’on obtient quand le fd est refermé sans le V : le watchdog reste armé, et le noeud fait un hard reset au timeout. Un certificat censé ne faire que de la lecture vient de rebooter physiquement un serveur.

Les autres impacts

Pour être honnête, ça reste limité : ni lecture de contenu, ni écriture. Ce qu’on obtient vraiment :

Reboot forcé via le watchdog, qu’on peut relancer à chaque redémarrage du noeud.
Oracle d’existence de fichiers sur le noeud (les deux messages d’erreur). Mais en vrai, il n’y a quasiment rien sur un noeud Talos Linux (c’est toute la beauté de la chose).
Goroutines bloquées : certains devices et FIFO bloquent dans open(2), chaque appel peut donc figer un handler de machined.
Des effets de bord plus exotiques d’open() sur certains drivers (rembobinage de bande, état de terminaux…), mais là on est complètement dans la théorie.

Le maintainer m’a mieux noté que moi

Petite anecdote sur la subjectivité du CVSS.

J’avais estimé la faille à 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L) : A:L pour le reboot, et AC:L parce qu’une fois le certificat os:reader en poche, l’attaque est déterministe.

Le maintainer (smira, de Sidero Labs) a publié 5.9 (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:H) : A:H parce qu’un hard reset de serveur physique, c’est plus qu’une simple dégradation, et AC:H parce qu’il faut un watchdog matériel présent et non géré par Talos.

Et franchement, les deux choix se défendent. Le CVSS 3.1 laisse beaucoup de place à l’interprétation, surtout sur AC (les conditions que l’attaquant ne contrôle pas) et sur la manière de compter l’impact quand l’attaquant a déjà une partie des droits. Un score CVSS, c’est une opinion argumentée, pas une mesure. Et un maintainer qui prend le temps de justifier son vecteur dans l’advisory, je ne vais pas m’en plaindre.

Le fix : trois couches, defense in depth

Le correctif (mergé dans main, backporté en 1.13.11 et 1.14.3) reprend les trois pistes que j’avais suggérées dans le rapport, en mieux :

Vérification du device : avant tout open(), le chemin doit pointer vers une vraie horloge PTP et le kernel doit confirmer que le device appartient bien au sous-système PTP. Ouvrir autre chose n’a donc plus aucun effet de bord. Les messages d’erreur sont aussi devenus génériques, ce qui supprime l’oracle.
Validation de la machine config : les chemins PTP doivent être des chemins propres, directement sous /dev, avec un nom qui commence par ptp (/dev/ptp0, /dev/ptp_kvm, /dev/ptp_hyperv). Si vous avez des configs exotiques, attention : elles risquent d’être refusées après l’upgrade.
RBAC : TimeService/TimeCheck est désormais réservé à os:admin et os:operator. TimeService/Time (la lecture de l’heure configurée, sans --check) reste accessible à os:reader.

Versions affectées : à partir de 1.10.0 (première release où TimeCheck accepte des chemins PTP), jusqu’à 1.13.11 / 1.14.3 exclus.

Si vous ne pouvez pas upgrader tout de suite :

ne distribuez pas de certificats os:reader à des clients en qui vous n’avez pas totalement confiance ;
filtrez l’accès réseau au port apid (50000) ;
sur les noeuds avec un watchdog matériel, déclarez un WatchdogTimerConfig pour que Talos garde lui-même le device ouvert.

“Takeaways”

open() n’est pas une lecture. Un appel qui “ne retourne rien” peut quand même armer du hardware, bloquer une goroutine ou servir d’oracle. Quand on audite une API “read-only”, la question n’est pas “qu’est-ce qu’elle renvoie ?” mais “qu’est-ce qu’elle fait ?”.
Un HasPrefix n’est pas une validation de chemin. Sans filepath.Clean, sans rejet de .. et sans allowlist, c’est purement décoratif. Si vous voulez chercher le même pattern ailleurs, grep HasPrefix(x, "/dev/"), HasPrefix(x, "/proc/") ou HasPrefix(x, "/sys/"). J’ai retrouvé ça dans de nombreux autres projets OSS.
“Est-ce que ça donne à l’attaquant quelque chose qu’il n’a pas déjà ?” C’est la question que je pose systématiquement pendant la contre-expertise (cf. l’article précédent), et ici la réponse ne fait pas débat : le rôle reader ne peut pas rebooter (PermissionDenied), mais il peut armer le watchdog qui, lui, reboot. Difficile pour un maintainer de répondre “working as intended”.
Les rôles “lecture seule” valent le détour. Tout le monde audite les chemins admin. Les API d’observabilité sont moins scrutées, distribuées beaucoup plus largement, et personne ne regarde leurs effets de bord. Dans le même audit, ce pattern “reader + effet de bord” m’a d’ailleurs donné d’autres pistes.
Sidero Labs a été exemplaire. Rapport accepté en moins d’une heure, fix en trois couches mergé moins de 3h après mon rapport (avec des durcissements que je n’avais pas suggérés), CVE demandée, et un advisory transparent publié moins de trois semaines plus tard. Si tous les projets traitaient les rapports comme ça, la vie de hunter serait beaucoup plus simple.

Tout est parti d’un subagent qui faisait exactement ce qu’on lui avait demandé : lire le code fichier par fichier et noter tout ce qui paraissait “même vaguement bizarre”. La suite (repro, rédaction, soumission) suit le pipeline décrit dans l’article précédent. Ça fait plaisir de pouvoir enfin raconter un cas concret de bout en bout !

Cloud Nord 2026 - Récap de ma journée à Lille

Sat, 31 Oct 2026 12:00:00 +0200

De retour de Cloud Nord 2026

Comme je vous l’avais annoncé en septembre, j’étais cette année à Cloud Nord, à Lille, pour y donner un talk “inédit” : “J’ai mis Kubernetes dans 512 Mo de RAM. Et il restait de la place pour DOOM.”

Enchaînement un peu sportif pour moi, puisque la veille au matin j’étais encore à BDX I/O pour dédicacer mon livre (cf mon post précédent).

Direction ensuite Lille dans le train, puisque Cloud Nord, c’était le vendredi 30 octobre.

Pour ceux qui ne connaissent pas : Cloud Nord, c’est une conférence communautaire nordiste organisée par des bénévoles, historiquement très orientée cloud et devops (forcément), avec un programme dense, et 2-3 tracks en parallèle.

Et comme d’habitude, voici mon récap des talks que j’ai vus.

Keynote d’ouverture : IA, souveraineté et cloud

La journée a commencé par une keynote de Patrick Perrot, général à l’Inspection Générale de la Gendarmerie nationale. Un profil un peu inattendu pour ouvrir une conf cloud.

Avoir l’opinion d’un fonctionnaire sur la vision de ce qu’est la “souveraineté” (sous des prismes particuliers, ou plus généralement) était assez intéressant. Partir du mythe de la caverne de Platon pour se poser la question des dépendances qu’on a aux géants du web et aux états, en particulier dans l’IA, même open weight, était aussi un exercice intéressant.

“Vous croyez que c’est vous qui décidez par où vous passez quand vous planifiez un trajet avec votre GPS ? Pourtant, c’est déjà vieux, un GPS”

Les machines prennent déjà des décisions pour nous depuis longtemps. Et sur le fameux “humain dans la boucle”, sa réponse, assez cinglante : “je fais confiance à certains humains pour faire trop confiance, par facilité, à l’IA.”

Son opinion :

Ne pas devenir un vassal technologique, il faut accélérer sur l’IA.
Quand on choisit un fournisseur : que se passe-t-il s’il nous lâche ? (extraterritorialité des données, réversibilité…)
Il faut désiloter : les réponses ne sont ni purement juridiques, ni purement techniques, ni purement sécurité. Il faut un panel de compétences.

Je ne suis pas certain de partager à 100% son opinion, mais la réflexion était très intéressante et bien menée. Bonne ouverture.

IA for Ops on Scaleway

À 9h50, Arnaud Gaches (Onepoint) est venu raconter comment il avait utilisé l’IA pour faire de l’ops sur Scaleway.

Note perso : je ne le dirai jamais assez, JAMAIS de dark theme sur une prez en conf 😆.

Arnaud revenait sur un projet entamé en début d’année, avec une V1 déjà présentée dans une autre conférence.

Son postulat de départ “certains devs se vantent de ne plus faire de code, pourquoi on ne fait pas pareil, nous les ops ?”. Le cœur du talk : une infra montée en plusieurs versions, entièrement via des agents “mains en l’air”, humain dans la boucle juste pour valider des actions sensibles.

Cette V2 était une version plus aboutie, avec un focus plus orienté “sécurité d’abord”.

un agent “orga” qui tourne sur le poste et qui détient les accès (orga, secrets, bucket d’état, IAM)
un agent dédié à la landing zone pour le réseau + le VPC peering
n8n, qui commence par demander à orga des droits supplémentaires, validé par l’humain (exemple)
du finops ajouté au passage
…

Je n’ai pas été surpris outre mesure par les retours d’Arnaud. Oui, Claude Code est capable de monter une infra relativement complexe et même de l’opérer dans une certaine mesure, en particulier si on fait appel à des produits managés. Claude est aussi assez bon pour croiser de multiples sources d’information pour trouver la root cause d’un incident.

En revanche, Arnaud le dit lui-même :

l’agent a trop confiance dans la doc… qui peut elle-même avoir été hallucinée par une version précédente
pas de prise de recul : il essaie de contourner les problèmes trop vite, avec un peu trop de zèle
installation d’outils tiers sans qu’on lui demande

Ma take perso : je ne suis pas convaincu, on est loin des gains visibles pour la partie “dev”.

Construire une usine agentique pour faire de l’infra, même en managé, c’est encore assez casse-gueule (finops qui dérape très facilement, risques de sécurité assez violents), ça consomme un max de tokens (il a dû passer de Claude Pro à Claude Max car les agents parlent trop entre eux). Mais indubitablement, c’est possible.

“L’IA, c’est un collègue brillant qui revient de vacances… tous les jours.”

Coupable ! Le procès d’un container malveillant dans Kubernetes

À 11h55, quickie de Paul-Alexandre Chrétien (HoppR), sur le format d’un procès.

Le prévenu : une app volontairement vulnérable, qui cumulait les chefs d’inculpation : libs obsolètes, exécution en root, RCE, vol de credentials, dump de la prod. Bref, la VULNAPP dans toute sa splendeur.

Pour la “défense des victimes” (et l’accusation), une stack d’outils que j’ai trouvée bien ficelée :

trivy-operator et ses CRD vulnReports pour le scan d’images
Kyverno et ses validatingPolicies pour bloquer à l’admission
Falco pour la détection à runtime
Policy Reporter pour centraliser les outputs de trivy + Kyverno + Falco dans un même rapport

Un bon quickie dans lequel il a réussi à mêler slides et démo. Beau boulot pour un premier talk :).

Houston, on a un problème avec ETCD

Je ne vais pas dire que je suis venu à Cloud Nord juste pour voir ce talk, mais on va dire que j’étais VRAIMENT motivé. Alexandre Burgoni et Pierre Zemb, tous deux chez Clever Cloud, sont venus parler d’etcd, du consensus distribué, et de pourquoi les gros acteurs finissent par réécrire leur propre implémentation.

Vous le savez, j’ai pas mal testé le Kubernetes managé de Clever Cloud (voir partie 1 et partie 2), qui a justement la particularité d’utiliser une réécriture de la partie etcd (sur Foundation DB). C’était donc un sujet que j’avais particulièrement envie de creuser.

Vraiment un talk excellent, sur les différents protocoles de consensus dans les infra distribuées, les problématiques que l’implémentation d’etcd a sur les performances de certaines opérations, quelques bugs “rigolos”, récents ou non.

Tout ça pour arriver au constat que non, à l’échelle, on ne peut pas faire proprement du kube (managé) avec etcd. Et c’est la raison pour laquelle les grands cloud providers ont tous fini par réécrire leur propre implémentation d’etcd pour passer à l’échelle.

Pour développer ça sereinement, ils ont fait énormément de simulation déterministe, assisté à grands coups d’IA en cas de divergences entre leur implem et etcd vanilla, une approche très inspirée de la façon dont FoundationDB lui-même a été testé.

Petite question que je n’ai pas pu m’empêcher de poser à la fin :

“Est-ce que vous avez trouvé des bugs d’etcd avec la simulation, ou est-ce que vos LLMs ont reproduit les bugs actuels pour être 100% compliant ?” 😄

Malheureusement non (pour l’instant).

Merci Pierre pour les discussions pendant le dîner des speakers (j’avais été un peu spoil en amont).

Platform Engineering à l’échelle de Decathlon, ce qu’on a appris en 5 ans

À 14h, Christophe Furmaniak (Decathlon) pour un REX sur 5 ans de platform engineering. La promesse de départ : des environnements en 20 minutes ; le défi réel : l’expérience développeur.

Je ne sais pas trop quoi penser de ce talk.

Objectivement le travail de l’équipe platform engineering chez Decathlon est titanesque, pas de doute là-dessus.

Cependant, ce que Christophe vend comme de la complexité nécessaire (une grosse stack terraform, avec plusieurs versions du moteur en // selon les équipes, des bots qui proposent des mises à jour automatiques parce que sinon il y a des retardataires, 1000 projets sur GCP au point qu’on ne sait plus qui est responsable de quoi, ou s’il faut nettoyer un projet) me paraît être de la complexité accidentelle.

Cependant, je reconnais bien volontiers que je ne travaille pas dans des contextes similaires.

Talk que j’aurais voulu voir en même temps : “Construire un Data Center dans son garage” (Aeddis Desauw, OVHcloud)

Pause avant ma conf

J’avoue avoir fait l’impasse sur le créneau de 15h45.

J’étais dans la salle pour “A la croisée de la DevEx et de GitLab” mais j’ai rien écouté : j’avais prévu 2 pi, donc un de secours pour mes démos. Et justement le pi de secours était cramé (base bbolt de containerd HS).

Donc j’étais content d’avoir un peu de temps pour fix ça (à l’arrache 😅).

J’ai mis Kubernetes dans 512 Mo de RAM. Et il restait de la place pour DOOM.

16h40, salle Amphi St Louis : mon talk, celui que je ne donnerai a priori qu’une seule fois.

Le pitch, pour ceux qui n’étaient pas là : faire rentrer Kubernetes sur un Raspberry Pi Zero 2 W (512 Mo de RAM, 20 $).

Une grosse partie du talk repose sur toute l’optimisation de Raspberry Pi OS Lite (la distrib officielle pour le pi zero, affreusement pas optimisée), mais aussi en jouant avec des recoins moins connus de Linux (notamment KubeSolo, que j’avais présenté dans Sysops Pratique).

Et en conclusion, le stress test le plus sérieux qui soit : Does it run DOOM ?

La réponse est oui, on a pu lancer DOOM, jouer en VNC, et même scaler DOOM à 9 replicas, en live, devant une 50aine de personnes.

J’ai eu des supers questions à l’issue du talk, et après. Merci à tous les présents.

Fin de journée

Pour clôturer la journée, le dernier créneau proposait deux quickies, dont “Maintenir une app bénévole : Tech, galères et résilience” de Seb Ferrer (OVHcloud). Je regrette de ne pas y être allé, car j’avais envie de voir si j’avais gagné au quizz du matin.

(Spoiler : le leaderboard a bougé après cette photo… je n’ai donc rien gagné 😆.)

L’avantage, c’est que ça m’a permis d’avoir des chouettes discussions dans les couloirs avec des gens qui ont vu mon talk et qui ont apprécié :).

Remerciements

Comme toujours, un immense merci à l’équipe d’organisation de Cloud Nord et à tous les bénévoles et une mention particulière pour m’avoir contacté au dernier moment pour remplacer un speaker défaillant. J’espère que le remplaçant était à la hauteur 😄.

Ces journées de conf, c’est aussi et surtout les rencontres dans les couloirs. Merci à tous les gens croisés, que ce soit au speaker dinner, dans les couloirs, ou à l’after. Cette fois, j’ai parlé à tellement de monde que c’est sûr que je vais en oublier donc je vais discrètement éluder la liste pour une fois ;-)

Merci :)

BDX I/O 2026 : dédicace de mon livre, jeudi matin !

Tue, 27 Oct 2026 10:00:00 +0200

C’est officiel !

Dans mon post de septembre, je vous teasais qu’une troisième chose mijotait peut-être pour BDX I/O… Je serai bien présent à l’édition 2026, mais uniquement le jeudi matin, pour une séance de dédicaces !

Les infos pratiques

Quand : jeudi 29 octobre 2026, le matin uniquement
Où : sur le stand de la librairie Mollat, à l’ENSEIRB-MATMECA (Talence)
Quoi : dédicaces de “Kubernetes : 50 solutions pour les postes de développement et les clusters de production” (Éditions Eyrolles)

Les exemplaires seront en vente directement sur le stand Mollat. Et si vous avez déjà le vôtre, amenez-le, je le signerai avec plaisir. 🙂

Un retour aux sources

Ça peut paraître anodin dit comme ça, mais cette dédicace a une saveur particulière pour moi : BDX I/O 2026 a lieu à l’ENSEIRB-MATMECA, l’école qui m’a formé (promo 2010, ça ne me rajeunit pas 🫣).

Pouvoir y revenir pour échanger avec des lecteurs et lectrices sur ce livre (l’aboutissement de 10 ans d’expérience sur Kubernetes et d’années de bidouilles sur ce blog) c’est vraiment un honneur. Le thème de cette édition, “back to school”, n’aurait d’ailleurs pas pu mieux tomber, pour moi.

Un immense merci à l’équipe de BDX I/O et à Mollat de rendre ça possible.

J’insiste un peu

Je ne serai sur place que jeudi matin (la conf elle, dure 2 jours, les 29 et 30 octobre). Si vous voulez repartir avec un exemplaire signé ou simplement discuter Kubernetes, c’est le moment ! Je pars ensuite pour Cloud Nord pour un talk sur kubesolo et… DOOM.

Après les dédicaces du Cloud Native Days France en février, ce sera ma deuxième “vraie” séance de dédicaces, et j’ai très hâte de renouveler l’expérience.

Pour plus de détails sur le livre, le site de promotion est toujours par là.

Billetterie BDX I/O : https://www.billetweb.fr/bdx-i-o-2026
Programme complet : https://bdxio.fr/schedule

On se retrouve jeudi matin à Talence !

Trouver des vulnérabilités dans l'open source quand on n'est pas spécialiste en sécurité

Wed, 23 Sep 2026 20:00:00 +0200

TL;DR

Trouver des failles dans l’open source en 2026, “grâce” aux LLM : facile, OUI
Être le premier à les remonter : possible, MAIS

Trouver des failles est devenu banal. Le vrai défi, c’est d’être le premier, et de survivre au triage. C’est de ça que parle le reste de l’article.

Pourquoi faire ça, au départ ?

La cybersécurité, ça me passionne depuis… bah, depuis toujours. Mon deuxième programme d’enfant était un VB 3.0 à la con, un faux virus qui avait pour seul boulot de remplir le dossier Démarrage de Windows 95/98 de milliers de commandes netsend auto-exécutables (si vous ne savez pas ce que c’était, allez jeter un œil !).

Mais je n’en ai jamais fait mon métier, même si l’idée m’est venue à plusieurs reprises. Ces derniers mois, j’ai collaboré plus étroitement que d’habitude avec mes collègues de l’équipe cybersécurité, et j’ai fini par me lancer : je voulais voir ce que je pouvais faire avec les LLM dans ce domaine.

Disclaimer : je ne suis PAS spécialiste en cybersécurité, pas le moins du monde. Si vous ne me connaissez pas, je ne suis qu’un platform engineer qui s’y connaît en Kubernetes, virtualisation et observabilité. Je code de manière correte en golang et en python.

Quel est le but, au juste ?

Ces deux derniers mois, je me suis mis à traquer (sur mon temps libre) des vulnérabilités dans des logiciels open source populaires que j’utilise au quotidien dans mon travail. Certains ont un programme de bug bounty, d’autres acceptent les GitHub Security Advisories. D’autres ne répondent tout simplement pas.

Pourquoi l’open source ? Bah déjà, le fait que le code soit ouvert me permet de vérifier les choses quand le LLM pense que quelque chose cloche, et de me forger ma propre opinion. L’inconvénient, honnêtement, c’est que les LLM sont aussi la raison pour laquelle l’open source se noie sous les rapports de sécurité depuis environ un an.

Mais surtout : je travaille avec ces outils tous les jours, je sais donc COMMENT ils devraient fonctionner, et ce qui N’EST PAS normal. On reviendra là-dessus aussi.

Une chose avant de commencer : tout ce qui est décrit ci-dessous a été fait sur ma propre infrastructure : clusters jetables, installations locales, VM de test. Chaque programme de bug bounty a ses règles du jeu : pas de scan d’instances tierces, pas de toucher aux données des autres, pas de déni de service sur une infra partagée. Lisez-les. Si une de vos découvertes nécessite de les enfreindre pour être prouvé, c’est que vous vous y prenez mal.

Ok ok, assez d’introduction : les LLM peuvent-ils trouver des failles sans expérience en cybersécurité ?

Réponse courte : oui. La vraie question, c’est de savoir si ça vaut le coup, et ça dépend surtout de si vous voulez être le premier ou non, et de QUAND vous commencez.

Voici mon propre retour d’expérience sur la chasse aux vulnérabilités dans l’open source. “YMMV”, comme on dit.

Vous avez déjà raté le coche

La première chose à savoir, c’est que (si vous commencez aujourd’hui) vous êtes très en retard.

C’est encore plus vrai pour les logiciels couverts par un bug bounty, parce que les chasseurs fouillaient déjà avant l’arrivée des LLM. Mais la pression sur ces projets a été multipliée par mille depuis.

Des chiffres concrets, tirés des pages publiques de deux très gros projets (stats sur 90 jours, septembre 2026), volontairement non cités (c’est bien l’écart qui compte) :

Un programme, encore à peu près en vie : 4 193 rapports reçus, ~454 000 $ versés
L’autre, essentiellement mort : 551 rapports reçus, 1 000 $ versés, dernier rapport traité il y a un mois

Relisez bien. Ce volume, c’est en grande partie du bruit généré par de l’IA. curl a complètement arrêté son bug bounty payant en début 2026, après l’effondrement du ratio de rapports valides. D’autres projets ont suspendu les paiements ou sont passés en accès sur invitation (Nextcloud, Grafana). Les mainteneurs se noient.

Alors si vous pensez être plus malin que tout le monde et que vous comptez vous faire de l’argent rapide avec votre compte Claude, réfléchissez-y à deux fois. Des centaines de personnes y avaient déjà pensé il y a un an, et il y en a un peu plus chaque jour. Vous êtes en concurrence avec elles, avec des professionnels aguerris, et avec des gens qui ont bien plus de ressources IA que vous.

Parlons modèles (choisissez vos armes)

J’ai d’abord essayé les options évidentes (“ça se passe mal!”) :

Claude : tout ce qui touche de près ou de loin à la cybersécurité est flaggé et bascule en mode fortement restreint. Au bout de quelques heures, la session est carrément gelée. La seule parade, c’est de relancer des sessions et de perdre son contexte à chaque fois - et les blocages se font plus fréquents avec le temps, même pour du travail parfaitement légitime. La voie officielle, c’est le Cyber Verification Program d’Anthropic (OpenAI a un équivalent, le Cybersecurity Grant Program), mais la validation semble arbitraire : plusieurs chercheurs en sécurité que je connais personnellement se sont fait refuser sans explication, et ils ne sont pas seuls.
Google Antigravity : ça a très bien marché pendant 2 jours, puis les blocages ont commencé. Google n’a aucun programme pour certifier les chasseurs légitimes, vous pouvez donc l’oublier. Un mois d’abonnement pour rien.

Ce qui marche : laissez tomber les grands fournisseurs américains et passez à des alternatives moins regardantes. Soit un accès par abonnement à des modèles open weights / chinois, soit des plateformes agentic avec des quotas généreux.

Et les API au token ? Très mauvaise idée pour ce genre de travail. La chasse aux failles demande un nombre absurde de tokens en lecture. Mes chiffres à moi : environ 11 milliards de tokens en 2 mois, dont la grande majorité (plus de 90%) servie depuis le cache côté fournisseur. Même avec l’une des options les moins chères au moment où j’écris (GLM 5.3 sur un broker bien connu), ça revient à environ 1 800 $. Un modèle frontier coûterait plusieurs fois ce montant. Choisir un fournisseur dont le cache est facturé moins cher aide énormément, mais vous ne voulez quand même pas de cette facture en fin de mois.

Les abonnements qui donnent accès à GLM, DeepSeek, Kimi… sont probablement de bonnes options (pas encore essayé). Ce que j’ai réellement utilisé pendant 2 mois, c’est devin.ai (l’outil agentic de Cognition, anciennement Windsurf) : leur modèle maison est compétent et, au moment où j’écris, illimité dans l’abonnement de base. Ce genre de promo va et vient, vérifiez avant de vous abonner.

Pas sponsorisé, je paie de ma poche 🥲.

Et les modèles locaux ?

L’idée est vraiment séduisante. Être autonome avec du matériel local (ou en louer) plutôt que de payer au token des tâches coûteuses, tout en échappant à la censure des fournisseurs, ça ressemble à une idée de génie (qui pense GIFI dans sa tête ?). C’est la première chose que j’ai essayée après mon “fiasco” Claude/Antigravity.

Alors… peut-on utiliser des modèles open weights locaux pour éviter de griller son quota en 20 minutes ? Avec un modèle ~30B (type Qwen, ou la meilleure variante du moment), on peut trouver quelques failles sur des gros projets anciens… mais c’est comme courir un marathon avec un sac à dos rempli de cailloux après les avoir peint (dédicace à Vincent). C’est faisable, mais ne vous attendez pas à ce que ce soit simple ni efficace.

Si vous partez sur cette voie, le pipeline ci-dessous compte encore plus qu’avec des modèles plus “gros”.

Mon pipeline

Quel que soit le modèle, la première chose dont vous avez besoin, c’est un cadre solide. Voilà ce que j’ai fait (plutôt basique, il existe peut-être des méthodes plus efficaces, mais c’est un bon point de départ) :

Analysez un composant de votre cible à la fois. Demandez au modèle de cartographier son fonctionnement en amont. Terminez-le complètement avant de passer au suivant.
Une fois la cartographie faite, répartissez le travail (surtout des fichiers de code) entre des subagents, chacun focalisé sur une partie bien délimitée. Demandez-leur de chercher des anti-patterns connus dans les fonctions, des variables mal vérifiées et compagnie, et de consigner dans un fichier markdown tout ce qui leur paraît même vaguement bizarre ou dangereux, pour analyse ultérieure.
Faites relire le travail des subagents par l’agent principal. Chaque constat part soit dans un dossier “non-security findings” (bugs trop faibles ou trop restreints pour être exploités : je m’en sers pour faire des PR d’amélioration en upstream), soit dans un dossier “security findings” pour contre-expertise.
Une fois le scan initial terminé, demandez à l’agent principal une contre-expertise de tous les nouveaux constats sécurité validés.

Contre-expertise

C’est là que vient l’essentiel de la valeur de mes scans LLM. J’ai mis deux mois à affiner cette étape, et j’y travaille toujours.

Ma checklist actuelle :

Chercher sur GitHub/GitLab les issues, PR et documents d’amélioration éventuels. Soumettre un problème de sécurité déjà connu, c’est évidemment une mauvaise idée.
Regarder aussi dans la doc officielle les limitations connues, les faiblesses & compromis documentés (c’est à dire “acceptés” par les mainteneurs, donc inéligibles), les bonnes pratiques de sécurité.
Quand vous êtes sûr à 100% qu’il n’y a ni correctif public ni rapport antérieur, demandez au modèle de reproduire sur le vrai logiciel. Selon la cible, vous voudrez peut-être des runbooks pour différentes configurations sur différentes plateformes. Cette étape est particulièrement importante avec les modèles locaux, qui sortent des rapports de vulnérabilité absolument convaincants mais qui ne marchent jamais.
Une fois reproduite, notez-la. La plupart des bug bounties demandent un score CVSS, mais il faut aller plus loin que ça.

Concrètement, un constat dans mon pipeline, ça ressemble à ça : un subagent signale un pattern suspect dans un fichier que personne ne lit -> l’orchestrateur le déduplique face aux issues publiques et aux flux de CVE -> si ça passe, reproduction sur un cluster kind jetable ou une installation locale du vrai logiciel -> puis noté, rédigé, soumis… et ensuite, vous attendez. Le triage prend en général quelques semaines/mois. Parfois quelques jours, et dans de rares cas plusieurs années (on y reviendra, c’est généralement le signe d’un programme surchargé ou mort).

Noter à la juste valeur

Une fois que vous avez de vraies vulnérabilités, les noter avec un CVSS est une étape nécessaire. Mais le travail ne s’arrête pas là. Tout le monde qui a fait un peu de cybersécurité sait bien que le CVSS ne raconte pas toute l’histoire. Et les LLM auront tendance à surévaluer leurs propres constats.

Faites poser ces questions à l’agent pendant la contre-expertise :

Le constat est-il réaliste ?
Les prérequis sont-ils réalistes ?
Existeraient-ils / arriveraient-ils dans un déploiement réel, pas seulement en théorie ?
La configuration est-elle saine (et non un piège où l’admin de notre scénario mériterait presque d’être compromis) ?
Un attaquant chercherait-il vraiment à exploiter ça ?
Le constat donne-t-il plus de droits que l’attaquant n’en a déjà ?

Toutes ces réponses (ou au moins la plupart) devraient être “oui”. Sinon, ce n’est probablement pas un problème de sécurité (ou en tout cas, c’est ce que les équipes sécurité de ces projets vous diront !), quoi qu’en dise le CVSS.

Il y a évidemment des exceptions, mais pour rester simple restons dans le cas général.

Appropriez-vous le rapport

Une fois tout ça fait, prenez le temps de le relire (vous, l’humain). Selon la qualité du modèle, vous trouverez peut être le rapport ridicule :

Lisez le rapport du LLM attentivement, comprenez-le, appropriez-vous-en !
Si quelque chose vous paraît bizarre, challengez le LLM
Si une affirmation est exagérée, challengez le LLM

C’est là qu’un bagage en cybersécurité ou une connaissance fine de l’outil que vous auditez devient vraiment utile. Ça vous évitera de vous ridiculiser (l’humain, le LLM, lui, s’en fout).

Ne faites pas partie du problème

Prenons le taureau par les cornes : je viens de vous dire que les mainteneurs se noient sous les rapports générés par l’IA, et j’en ai envoyé plus de 30 moi-même. Oui, il y a un léger problème de cohérence. Voici ce que j’essaie de faire autrement :

Rien n’est soumis sans avoir été reproduit sur le vrai logiciel et/ou un vrai cluster
Chaque rapport est lu, compris et assumé par moi avant de partir. Si je ne peux pas l’expliquer aux mainteneurs sans le LLM, il ne part pas
Les constats à faible sévérité ou limite ne passent pas par les canaux sécurité : ils finissent en issues publiques ou en PR en upstream
Les notes sont contestées : pas de CVSS gonflé par le LLM
Sur les petits projets, les rapports partent un par un, en attendant le triage avant d’en envoyer d’autres

Les doublons arrivent quand même (9 pour l’instant), mais un doublon de vraie vulnérabilité reproduite coûte quelques minutes au triage sur des plateformes de bug bounty. Un rapport halluciné lui coûte potentiellement des heures, et beaucoup de la patience du maintainer.

Gardez une trace de tout

Ça, je l’avais pas vu venir.

Très très (très) vite, on est soi même ensevelli sous les reports. Après une trentaine de constats et une dizaine de rapports envoyés, je ne savais plus où j’en étais, honnêtement. Quel constat avait été reproduit ? Lequel avait déjà été soumis, et dans quel programme ? Quel rapport m’attendait, et lequel attendait les mainteneurs ? Un dossier de fichiers markdown ne passe pas à l’échelle, et les immenses tables markdown entretenues par le LLM sont vite devenues ingérables aussi.

Du coup, j’ai fini par faire “Clauder” mon tableau de bord de suivi (oui, l’ironie : Claude code avec plaisir une UI pour chasser des failles, il veut juste pas faire la chasse lui-même). La source de vérité est désormais une base JSON, que le LLM met à jour via des scripts (jamais en éditant le fichier à la main). À chaque commit, un tableau kanban HTML statique est régénéré à partir de celle-ci, en suivant chaque constat tout au long de son cycle de vie.

(Les titres ont été censurés pour des raisons évidentes)

Chaque constat est une carte qui progresse de gauche à droite :

Candidate : signalée par un subagent, pas encore vérifiée
Confirmée : a survécu à la contre-expertise et à la reproduction
Rédaction puis Prête : rapport en cours de rédaction, puis prêt à envoyer
Envoyé et Triage : soumis, en attente que le programme le regarde
Acceptée (embargo) : acceptée par le programme, correctif ou divulgation en attente
Corrigée : correctif publié
Fermée : rejetée comme doublon, wontfix ou informative

Chaque carte porte un score composite (CVSS + risque de wontfix + risque de doublon, on y revient dans la section suivante), le CVSS, combien de fois elle a été soumise, et si elle a déjà été remontée en upstream. Trier par score composite me dit quoi écrire ensuite. Filtrer par programme me dit combien de places il me reste avant d’atteindre la limite de soumission.

La vue stats, c’est aussi un bon retour à la réalité :

163 constats (après en avoir écarté 215 non-sécurité), sur 26 projets, et seulement 31 soumis.

La seule colonne “Prête” contient déjà 118 constats. En trouver, c’est trivial. Ce qui me limite, ce n’est plus le LLM : c’est mon temps à moi pour reproduire, rédiger et assumer chaque rapport (l’humain dans la boucle est le goulot d’étranglement), puis les plafonds de soumission des programmes. Et même dans ces conditions, être le premier et survivre au triage reste du ressort de la chance.

Quel que soit l’outil que vous utilisez (un tableur fait l’affaire aussi, voire JIRA lol), mettez ça en place avant de commencer à soumettre. Le rajouter après 10 rapports envoyés, en remuant les mails et les boîtes de réception des plateformes, c’est un exercice douloureux.

Vous n’êtes pas seul

Même quand le programme ne verse pas de bounty, attendez-vous à de la concurrence : via les plateformes de bug bounty ou des rapports GHSA (GitHub Security Advisory). Vous pouvez partir du principe que chaque problème “facile à repérer” a été trouvé il y a des mois, plusieurs fois. Sur les projets dont l’équipe sécurité est à bout, comptez plutôt des années.

Je ne peux pas encore donner de détails, mais je suis tombé sur une vulnérabilité qui avait été remontée il y a des années, avec un CVE réservé l’année d’avant, toujours ni corrigée ni publique.

Voilà l’état du triage de sécurité de l’open source aujourd’hui : la file d’attente est plus longue que ce qu’on arrive à traiter, et ça ne s’améliore pas.

Alors si vous visez à être le premier (pour le bounty, pour la gloire), il faut être plus stratégique que la moyenne :

Évitez les bugs qui se repèrent en lisant un seul fichier, ou qu’un outil SAST/DAST signalerait. Les LLM sont relativement doués pour ça, et vous pouvez être sûr que quelqu’un l’a trouvé avant vous. Malheureusement, c’est peut-être le seul type de constat que vous obtiendrez avec des modèles locaux/petits (ou il vous faut un harness très spécifique).
Ciblez en priorité du code qui n’est pas le plus audité. Ne visez pas une RCE pré-auth si vous ne savez pas ce que vous faites. Ce code a été audité par des gens bien meilleurs que vous. Visez plutôt du code récent en beta/GA, ou à l’inverse du vieux legacy qui paraît inoffensif.
Visez des problèmes qui supposent de savoir comment l’outil fonctionne, et ce qui ne devrait pas fonctionner. Les LLM sont mauvais là-dessus : si vous avez cette connaissance, vous avez un avantage.
Si vous ne payez pas au token, n’hésitez pas à donner le fichier entier au subagent. J’ai découvert par hasard qu’un agent qu’on restreint aux “fonctions sensibles” en rate ÉNORMÉMENT. C’est peut-être moins vrai pour les modèles frontier, mais c’est une vérité absolue pour les modèles moins bons.

De là, j’ai mis au point un score qui évalue mes vulnérabilités non seulement sur leur CVSS, mais aussi sur le risque de “wontfix” de la part des mainteneurs et le risque de “doublon” parce qu’elles étaient trop faciles à trouver.

Conclusion

Est-ce que ça marche ? Oui, absolument. J’ai trouvé des dizaines de vulnérabilités réelles, non corrigées, dans de l’open source en production, allant de sévérité moyenne à critique.

La vérité qui pique : j’ai envoyé plus de 30 rapports jusqu’ici. Sur les verdicts revenus, la plupart étaient des doublons - quelqu’un était arrivé avant moi (mon erreur de débutant : je pensais que les constats faciles passeraient, alors que “facile” signifie simplement que quelqu’un les a déjà trouvés). L’un m’a valu un CVE avec co-crédit, CVE-2026-77524, qui vient de sortir en public : une élévation critique namespace-admin vers cluster-admin dans KEDA ; un autre advisory a été accepté mais n’est pas encore public ; et un correctif a été mergé via une issue publique. Le reste est soit encore en triage, soit bloqué derrière des limites de débit. Certaines plateformes plafonnent les soumissions, par exemple 4 rapports par programme sur une fenêtre glissante de 30 jours, un peu plus si vous chassez sur plusieurs programmes, avec en plus un plafond global sur toute la plateforme.

Et quand un projet ne répond simplement pas ? Je n’ai pas encore de règle parfaite : je relance une fois après quelques semaines. La convention courante, c’est une publication publique après un embargo raisonnable (90 jours), mais je n’ai pas encore décidé si je l’appliquerai. Il y a aussi des paliers intermédiaires, comme escalader auprès d’une CNA, ou de GitHub Security Lab pour les projets hébergés sur GitHub. Un rapport qui pourrit dans une file privée n’aide personne, mais laisser une vulnérabilité non corrigée entre les mains des utilisateurs non plus.

Alors : exploitez cette contrainte. Transformez la faiblesse en atout. Tout le monde se concentre sur les mêmes cibles médiatiques (qui ne veut pas d’une RCE pré-auth ?) ou sur les failles évidentes et faciles. Si vous voulez des résultats (être le premier), laissez tomber les deux. Concentrez-vous sur les cas limites obscurs qui se retrouvent éparpillés sur 3 composants. Oui, ça demande plus de travail, de meilleurs LLM, et un peu de chance.

Si vous commencez maintenant, les victoires faciles sont déjà prises. Mais c’est précisément là que se trouve votre atout : savoir comment devraient se comporter les outils que vous utilisez tous les jours, c’est quelque chose que personne ne peut louer “au token”.

Retrouvez-moi à Cloud Nord 2026 et au DevFest Toulouse !

Mon, 21 Sep 2026 21:00:00 +0200

TL;DR : je serai speaker à Cloud Nord le 30 octobre pour un talk inédit sur Kubernetes tassé dans un Raspberry Pi Zero, et au DevFest Toulouse le 19 novembre pour présenter ma boîte à coucou des Guignols. De quoi finir l’année en beauté.

Cloud Nord 2026 - Kubernetes dans 512 Mo de RAM, et un peu de DOOM

Alors que je n’avais pas été retenu à la base, j’ai reçu un message de l’équipe d’organisation de Cloud Nord 2026, qui avait besoin d’un petit coup de main pour remplacer un speaker finalement absent.

Comme Cloud Nord c’est vraiment une conférence que j’adore, et surtout, que c’était pour un sujet que je n’avais pas encore présenté (et que je ne donnerai a priori qu’une seule fois), j’ai dit oui, sans réfléchir (Lille, c’est loin 😆).

Vous pourrez donc me voir à cloud nord pour : “J’ai mis Kubernetes dans 512 Mo de RAM. Et il restait de la place pour DOOM.” Rendez-vous le vendredi 30 octobre 2026, de 16h40 à 17h30, salle Amphi St Louis, pour voir jusqu’où on peut pousser un Raspberry Pi Zero 2 W.

Voici le pitch :

Kubernetes est souvent perçu comme une usine à gaz réservée à des clusters surdimensionnés et à des machines pleines de RAM.

Mais est-ce vraiment le cas ?

Dans cette conférence, je vais vous montrer, en live, comment on peut faire rentrer Kubernetes sur une machine à peine plus grosse qu’une clé USB, avec seulement 512 Mo de RAM et qui coûte 20 $ : un Raspberry Pi Zero 2 W.

En coupant tout ce qui dépasse, en optimisant l’OS jusqu’à l’os (ahah), et en jouant avec des recoins moins connus de Linux, on fera émerger un cluster Kubernetes mono-nœud parfaitement fonctionnel, malgré des contraintes matérielles extrêmes.

Et pour pousser l’expérience jusqu’à ses limites, on concluera par un stress test volontairement absurde mais révélateur : “Does it run DOOM ?”

C’est une conférence inspirée directement de l’article que j’ai publié dans Sysops Pratique au printemps. Mais cette version sera plus ludique, car en live, et probablement plus dangereuse pour la qualité de mon sommeil la veille du talk 🤞🏻.

La page de la session est ici et la billetterie est ouverte (ne trainez pas).

DevFest Toulouse 2026 — “Ah que coucou !”

Je l’ai déjà dit, mais vous l’avez peut être loupé : je serai AUSSI au DevFest Toulouse 2026, le 19 novembre au Diagora de Labège, pour un quickie absolument sérieux (non) : “Ah que coucou !” Recréer la boîte des Guignols avec ML embarqué, RaspberryPi et impression 3D.

Je vais y raconter le projet open source “a-que-coucou” que j’ai déjà présenté dans un article ici : une boîte à coucou pilotée par reconnaissance vocale, qui pousse un œuf quand quelqu’un dit “ah que coucou”.

Pitch :

Vous vous souvenez des Guignols de l’info ? La marionnette de Johnny Hallyday, la boîte mystérieuse, et l’œuf qui sort dès que quelqu’un dit “ah que coucou” ? J’ai décidé de construire cet objet pour de vrai. Avec un RPi 5, quelques composants électroniques, beaucoup de câbles et une imprimante 3D.

Dans ce talk, je vous montre comment construire cet objet de bout en bout : reconnaissance d’un wake word en français sans réseau, conception de toutes les pièces mécaniques en OpenSCAD, et orchestration sur un Raspberry Pi 5.

C’est un projet maker qui touche à tout. Vous repartirez en sachant comment implémenter un wake word offline, comment concevoir un objet physique piloté par du code, et surtout quels pièges éviter quand on mélange ML, audio et hardware.

Le projet est full open source en MPL 2.0, avec le code Python, les fichiers CAO pour OpenSCAD/3D, et un script de déploiement automatique. Le tout est sur github.com/zwindler/a-que-coucou.

La page de la session est là et les billets sont par ici.

Et BDX I/O ?

Il y a une troisième chose qui mijote, peut-être.

Peut-être que je serai à BDX I/O pour un autre projet, mais pas en tant que speaker cette fois.

Je n’en dis pas plus. Rien n’est fait.

Venez me faire (ah que) coucou

Si vous êtes dans le coin pour l’une de ces deux conférences, venez me voir. Que ce soit pour parler Kubernetes, Raspberry Pi, impression 3D, wake words, open source, ou juste prendre un coca zero, ça me fera vraiment plaisir.

See you there !

Non pas un, mais deux projets mêlant impression 3D et électronique embarquée

Fri, 17 Jul 2026 09:00:00 +0200

Après un silence quasi religieux depuis 1 mois et demi, vous vous demandez peut-être (ou non) ce que je fais de mes après-midi ?

Et bien je vais vous le dire (non non, ne partez pas)

En réalité, j’ai enchaîné deux projets “maker” qui méritent que je m’y attarde : une boîte à coucou pilotée par reconnaissance vocale, et un gyrophare connecté en open source. Et les deux partagent un ADN commun : impression 3D, OpenSCAD et de bidouille électronique du dimanche.

À que coucou !

Alors forcément, ça ne va pas parler aux plus jeunes d’entre vous… Mais dans les années 90, dans l’émission “Les guignols de l’info”, il y avait un running gag qui faisait rire “tout le monde”. La marionnette de Johnny Hallyday apportait une boîte noire, de laquelle sortait un coucou quand on prononçait “Ah que coucou”.

En réalité, c’est un side project qui traîne dans un coin de ma tête depuis au moins 2021 (essayé puis abandonné) et qui n’a pris vie que cette année.

Sur le papier, le principe est simple (hinhinhin, oui super simple, vraiment… non) :

Un microphone écoute en permanence
Quand “ah que coucou” est détecté, un moteur actionne un bidule qui pousse un œuf hors de la boîte
Un haut-parleur joue “coucou !”
Après quelques dixièmes de secondes, l’œuf rentre

Hardware (ça parlera aux amateurs) : un Raspberry Pi 5, un servo TowerPro SG90, un micro INMP441 I2S, un ampli MAX98357A I2S et une enceinte 4Ω 3W. Une breadboard 170pts, des Dupont, et environ 30 € de composants (hors Pi et imprimante).

Le Pi 5 fait tourner un orchestrateur Python qui utilise openWakeWord (ONNX Runtime) pour la détection (comme Home Assistant). Le modèle “ah que coucou” a été généré avec Coqui TTS. Le tout tourne sans internet avec une latence < 500ms. Cette partie était assez technique, d’autant que j’ai fait l’entraînement avec mon GPU (de quoi justifier ma RTX 5080 ? Pas sûr).

Mécanique : tout est conçu dans OpenSCAD… la boîte, l’œuf, le pignon de 40mm, la crémaillère de 110mm, le rail et le support servo. Ça s’imprime en 3D sans difficulté et ça se monte sans vis.

Le projet est en MPL 2.0 sur github.com/zwindler/a-que-coucou, avec tout le code Python, les STL/SCAD, et un script de déploiement automatisé.

Et j’en parlerai plus en détails au DevFest Toulouse pour un lightning talk en novembre, et peut-être sous un autre format (suspense) si j’arrive à passer entre les mailles des SPAM emails (celui qui sait, saura).

Alerte Rouge — mon Blinky à moi

Vous vous souvenez de ma série de reverse du Blinky ENIX en 2023 ? Le concept était excellent, mais c’était un produit fermé avec un firmware propriétaire et un SaaS obligatoire, qui a fermé depuis, faute de marché.

J’avais besoin d’un machin qui clignotte pour me dire que OpenCode ou Claude Code attend une réponse de ma part ou qui me prévienne quand la prod est pétée. Je me suis dit : pourquoi ne pas en refaire un moi-même, en open source ?

Alerte Rouge est donc, comme Blinky, un gyrophare connecté sur ESP32 + NeoPixel ring WS2812, avec un boîtier imprimé en 3D.

Hardware : un ESP32 (n’importe quel devkit), un anneau 16 LEDs en 60mm, un bouton poussoir, un condo 470µF et deux résistances. Câblage en 5 minutes.

Firmware : écrit au-dessus de MicroPython (le REPL c’est hyper pratique pour itérer), avec 16 patterns lumineux (flash_red, kitt, police, gyrophare, rainbow, comet, wave, theater, strobe… oui je me suis fait plaisir), une API REST, un webhook Prometheus Alertmanager, et même une page web de config embarquée. La pile d’alertes est en LIFO avec timeout et acquittement physique.

Boîtier : conçu dans OpenSCAD, base + dôme paramétriques, imprimable sans supports.

Le tout en AUSSI en MPL 2.0 (je l’aime d’amour cette licence) sur github.com/zwindler/alerte-rouge, avec le firmware, les CAO, un Makefile pour flasher/déployer en une commande, et les schémas de câblage.

Conclusion

J’ai donc fait un gros tunnel pour sortir deux projets que tout rassemble :

OpenSCAD pour toutes les pièces. Coder ses modèles plutôt que les dessiner dans Blender, ça change la vie.
Hardware simple. Une breadboard, quelques câbles, pas ou peu de soudure
Open source (MPL 2.0) pour que vous puissiez les reproduire, les améliorer, ou les forker
- zwindler/a-que-coucou
- zwindler/alerte-rouge

Have fun

zeropod v0.12.0 : un an après, le scale-to-zero tient-il ses promesses ?

Sat, 30 May 2026 12:00:00 +0200

Qu’est-ce que zeropod ?

Il y a un peu moins d’un an, j’avais publié un premier article sur un projet open source qui s’apelle zeropod.

Zeropod is a Kubernetes runtime (more specifically a containerd shim) that automatically checkpoints containers to disk after a certain amount of time of the last TCP connection.

While in scaled down state, it will listen on the same port the application inside the container was listening on and will restore the container on the first incoming connection.

À l’époque, la version stable était la v0.6.x, et j’avais testé sur un cluster k3s. Les résultats étaient mitigés : ça marchait dans les grandes lignes, mais avec des limitations rédhibitoires pour une utilisation un peu sérieuse (probes impossibles, comportement flaky sous charge, temps de checkpointing un peu élevés à mon gout).

Entre temps, le projet a pas mal évolué (maintenant v0.12.0), avec des promesses de corrections et d’améliorations. J’ai donc remis le couvert pour voir où on en est vraiment.

Autre changement : j’ai abandonné k3s pour cette série de tests, pour des raisons que je détaillerai au fil de l’article.

Prérequis

Cette fois-ci, j’ai utilisé un serveur fraîchement provisionné chez mon hébergeur préféré :

Un serveur Ubuntu 24.04.3 LTS (Noble), kernel 6.17.0-35 HWE, 7.7 Gi RAM, 100G disk
Un cluster Kubernetes monté avec kubeadm, flannel comme CNI
containerd vanilla
local-path-provisioner (Rancher) pour avoir un stockage local
Pas de cert-manager ni d’Ingress, on va au plus simple cette fois

Installation

J’ai déjà installé kubeadm plein de fois et certainement que vous aussi donc je ne vous fait pas l’affront de refaire un énième tuto.

# Installer kubeadm, kubelet, kubectl + containerd
sudo kubeadm init --pod-network-cidr=10.42.0.0/16
kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml
kubectl taint nodes --all node-role.kubernetes.io/control-plane-

Une fois le cluster fonctionnel, l’installation de zeropod est triviale :

# Appliquer le kustomize générique
kubectl apply -k https://github.com/ctrox/zeropod/config/generic

# Ajouter un label à notre unique node
kubectl label node <votre-node> zeropod.ctrox.dev/node=true

# Vérifier que le pod tourne
kubectl -n zeropod-system wait --for=condition=Ready pod -l app.kubernetes.io/name=zeropod-node

C’est tout. Pas de flag spécial, pas de configuration supplémentaire. Sur kubeadm, kubelet est un binaire natif (/usr/bin/kubelet) détecté automatiquement par zeropod.

Note sur k3s : sur k3s, la documentation de zeropod est un peu différente puisque la config à utiliser est config/k3s. Le kustomize ajoute un flag -probe-binary-name=k3s sur l’initContainer pour que le shim sache que le kubelet est embarqué dans le binaire k3s. Lors de mes tests, j’ai constaté que même avec ce flag, le comportement n’était pas celui attendu (le socket tracker ne filtrait pas correctement les probes). Avec la config par défaut, le flag est sur l’initContainer mais pas sur le manager. J’avais suspecté qu’il y avait un autre composant à patcher, mais je n’ai pas creusé plus que ça.

Le DaemonSet déploie les images suivantes :

ghcr.io/ctrox/zeropod-manager:v0.12.0
ghcr.io/ctrox/zeropod-installer:v0.12.0
ghcr.io/ctrox/zeropod-criu:v4.2 (CRIU a été mis à jour depuis v0.6.x)

Vérifions que la runtimeClass zeropod est bien disponible :

kubectl get runtimeclass
NAME HANDLER AGE
zeropod zeropod 30m

Premier test : nginx

Comme la dernière fois, commençons par un test simple avec nginx. On déploie un pod tout bête :

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx
spec:
 replicas: 1
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 annotations:
 zeropod.ctrox.dev/scaledown-duration: 10s
 labels:
 app: nginx
 spec:
 runtimeClassName: zeropod
 containers:
 - image: nginx
 name: nginx
 ports:
 - containerPort: 80

Le passage important, c’est l’annotation zeropod.ctrox.dev/scaledown-duration: 10s et runtimeClassName: zeropod.

Peu après le déploiement, zeropod détecte l’absence de trafic. Le container est checkpointé. Si on regarde les logs du manager :

{"time":"2026-05-29T14:26:37.269453861Z","level":"INFO","msg":"status event","container":"nginx","pod":"nginx-bench-7c65c8874-6pts7","phase":"RUNNING","duration":"0s"}

Puis 10 secondes plus tard :

{"time":"2026-05-29T14:26:47.465510937Z","level":"INFO","msg":"status event","container":"nginx","pod":"nginx-bench-7c65c8874-6pts7","phase":"SCALED_DOWN","duration":"191.259383ms"}

Le champ duration dans le log SCALED_DOWN correspond au temps de checkpoint : 191ms. C’est déjà nettement mieux que les ~400ms de v0.6.x sur k3s (probablement grâce à une mise à jour, peut être CRIU 4.2 ?).

Restauration

Quand on envoie une requête HTTP, le container se réveille :

time curl http://<POD_IP>/ -s -o /dev/null -w "%{http_code} (%{time_total}s)"
HTTP 200 (0.101s)

real 0m0.101s
user 0m0.003s
sys 0m0.003s

101ms pour restaurer nginx et servir une page. C’est comparable aux ~92ms de l’article original.

Petite nouveauté : sous v0.6.x, kubectl top pods retournait une erreur pour les pods checkpointés :

# v0.6.x
kubectl top pods
error: Metrics not available for pod default/php-xxx

Ce bug a été corrigé dans la v0.9.0. Désormais, les pods en SCALED_DOWN retournent 0m 0Mi :

kubectl top pods
NAME CPU(cores) MEMORY(bytes)
nginx 0m 0Mi

C’est plus élégant.

Test des liveness probes

C’était LA limitation majeure de la v0.6.x : zeropod était incompatible avec les probes Kubernetes. Si vous mettiez une liveness probe httpGet sur votre container, la sonde déclenchait le timer de scale-down, et votre container ne passait jamais en SCALED_DOWN. Résultat : probes inutilisables, donc zeropod inutilisable en production.

Ce qui a changé

Deux correctifs ont été apportés entre la v0.6.x et la v0.12.0 :

L’activator (le composant eBPF qui écoute le trafic pendant le SCALED_DOWN) : il intercepte les probes et répond 200 directement, sans réveiller le container. Ça, c’est le comportement “après scale-down”.
Le socket tracker (le composant qui ignore les connexions pendant l’état RUNNING) : depuis la PR #72 (merged août 2025), zeropod est capable de détecter les connexions provenant du kubelet et de ne pas les compter comme du “vrai” trafic. Ça, c’est le comportement “avant scale-down”.

Test grandeur nature

J’ai déployé nginx avec une liveness probe agressive (periodSeconds: 5) et un scaledown-duration: 10s :

spec:
 runtimeClassName: zeropod
 containers:
 - image: nginx
 name: nginx
 livenessProbe:
 httpGet:
 path: /
 port: 80
 periodSeconds: 5

Sur k3s, ce test m’avait donné du fil à retordre : le socket tracker n’arrivait pas à filtrer les connexions des probes, qui resettaient le timer de scale-down en permanence. L’activator par contre (qui filtre les probes une fois le scale down passé) fonctionnait.

Sur kubeadm, le résultat est immédiat :

kubectl get pod -l app=nginx-probe -o json | jq -r '.items[0].metadata.labels["status.zeropod.ctrox.dev/nginx"]'
SCALED_DOWN

Le socket tracker filtre correctement les connexions du kubelet natif. La règle periodSeconds > scaledown-duration que j’avais dû utiliser sur k3s n’est plus nécessaire.

Un mot sur les évolutions entre v0.6.x et v0.12.0

Le tableau des améliorations entre les deux versions :

Point	v0.6.x	v0.12.0
`kubectl top pods` en scaled-down	❌ Erreur	✅ `0m 0Mi` (fix v0.9.0)
Checkpoint (nginx)	~400ms	~185ms (-54%)
Restauration (nginx)	~92ms	~99ms (stable)
CRIU	v3.x	v4.2
Gestion d’échec checkpoint	basique	métriques + events (v0.11.0)
Proxy timeouts configurables	❌	✅ (v0.11.0)
Migration inter-node	basique	améliorée + timeouts (v0.10.0)
Probes	❌ Incompatible	✅ Activator + socket tracker

Note technique intéressante sur les flags CRIU : zeropod a retiré l’option --tcp-established en septembre 2025. Auparavant, les connexions TCP actives étaient sauvegardées et restaurées avec le container. Désormais, zeropod utilise --tcp-skip-in-flight (quand runc >= 1.3 le supporte). Conséquence pratique : si votre container a des connexions TCP sortantes au moment du checkpoint, elles seront perdues. Il faudra les rétablir après restore.

Déploiement de WordPress (le cas d’usage réaliste :trollface:)

Bon, nginx c’est bien, mais c’est pas très représentatif. Déployons une vraie app avec du PHP, Apache et une base de données.

Reprenons le manifest WordPress de l’article original, sans zeropod sur MySQL :

apiVersion: apps/v1
kind: Deployment
metadata:
 name: wordpress
spec:
 replicas: 1
 selector:
 matchLabels:
 app: wordpress
 template:
 metadata:
 annotations:
 zeropod.ctrox.dev/scaledown-duration: 10s
 zeropod.ctrox.dev/container-names: wordpress
 zeropod.ctrox.dev/ports-map: wordpress=80
 labels:
 app: wordpress
 spec:
 runtimeClassName: zeropod
 initContainers:
 - name: wait-for-mysql
 image: mysql:8
 command:
 - sh
 - -c
 - |
 until mysql -h mysql -u root -p${MYSQL_ROOT_PASSWORD} -e "SELECT 1"; do
 echo "Waiting for MySQL..."
 sleep 3
 done
 mysql -h mysql -u root -p${MYSQL_ROOT_PASSWORD} -e "CREATE DATABASE IF NOT EXISTS wordpress;"
 env:
 - name: MYSQL_ROOT_PASSWORD
 value: verySecurePassword
 containers:
 - image: wordpress:latest
 name: wordpress
 ports:
 - containerPort: 80
 env:
 - name: WORDPRESS_DB_HOST
 value: mysql
 - name: WORDPRESS_DB_USER
 value: root
 - name: WORDPRESS_DB_PASSWORD
 value: verySecurePassword
 - name: WORDPRESS_DB_NAME
 value: wordpress

MySQL (sans zeropod) :

apiVersion: v1
kind: Service
metadata:
 name: mysql
spec:
 ports:
 - port: 3306
 selector:
 app: mysql
 clusterIP: None
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: mysql
spec:
 serviceName: mysql
 replicas: 1
 selector:
 matchLabels:
 app: mysql
 template:
 metadata:
 labels:
 app: mysql
 spec:
 containers:
 - image: mysql:8
 name: mysql
 ports:
 - containerPort: 3306
 env:
 - name: MYSQL_ROOT_PASSWORD
 value: verySecurePassword
 volumeMounts:
 - mountPath: /var/lib/mysql
 name: data
 volumeClaimTemplates:
 - metadata:
 name: data
 spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 5Gi

Le checkpoint de WordPress (Apache + PHP) :

{"time":"2026-05-29T14:33:35.915988635Z","phase":"SCALED_DOWN","duration":"313.286787ms"}

Les checkpoints mettent autour de 300ms. La restauration est autour de 200 ms :

{"time":"2026-05-29T14:34:31.56806589Z","phase":"RUNNING","duration":"206.33005ms"}

La première requête curl confirme :

time curl http://<POD_IP>/ -s -o /dev/null -w "%{http_code} (%{time_total}s)"
HTTP 302 (0.212s)

212ms, c’est environ 2 fois plus rapide que les 454ms de l’article original.

Et maintenant, le test qui tue : cascade WordPress + MySQL

Dans l’article original, j’avais tenté le test ultime : mettre les deux pods (WordPress ET MySQL) avec runtimeClassName: zeropod, puis envoyer une requête HTTP sur WordPress pendant que les deux sont checkpointés.

Le scénario est le suivant :

Au bout de quelques secondes, WordPress est SCALED_DOWN, MySQL est SCALED_DOWN aussi
Un client envoie une requête HTTP à WordPress
L’activator de WordPress intercepte la requête et restore le container WordPress
WordPress (Apache+PHP) démarre, exécute le code PHP qui nécessite une connexion MySQL
WordPress se connecte à MySQL sur le port 3306
L’activator de MySQL intercepte la connexion et restore MySQL
MySQL répond, WordPress génère la page, Apache renvoie la réponse HTTP

Du vrai scale to zero qui scale toute l’app, pas juste le front/back.

Note importante : je sais que vous ne voudrez probablement jamais scaler votre base de données à zéro en production, mais ce test montre que cette approche (eBPF + CRIU) fonctionne au-delà du simple scale-to-zero de serveurs web, ce que d’autres outils sur le marché font déjà très bien.

Sur k3s : pas de chance, sur kubeadm : victoire

Sur k3s, je n’ai pas encore réussi à faire fonctionner ce scénario : WordPress se restaurait mais ne répondait pas sur le port 80. J’ai passé pas mal de temps à essayer de comprendre, sans succès.

Même test, même version de zeropod, mais sur kubeadm :

curl http://<POD_IP>/ -s -o /dev/null -w "%{http_code} (%{time_total}s)"
HTTP 302 (0.224s)

224ms. Les deux pods sont passés de SCALED_DOWN à RUNNING, la page WordPress s’affiche. J’ai répété le test 5 fois de suite :

Cycle	Temps (curl)	HTTP
1	229ms	302
2	192ms	302
3	227ms	302
4	230ms	302
5	211ms	302

Les logs zeropod confirment le réveil des deux containers :

WordPress: SCALED_DOWN → RUNNING
MySQL: SCALED_DOWN → RUNNING

Ce qui a vraiment changé depuis v0.6.x

Les probes (enfin !)

C’était mon grief principal dans le premier article. Aujourd’hui, c’est résolu :

Avant : impossible de mettre des probes Kubernetes → zeropod inutilisable dans un usecase un minimum sérieux
Après : l’activator intercepte les probes en SCALED_DOWN (répond 200 sans restore), et le socket tracker filtre les connexions kubelet en RUNNING

La stabilité

Le comportement flaky (perte de pods sous charge simultanée) a disparu. Là où j’avais des échecs sous l’article original, les tests de charge séquentiels et simultanés passent tous.

Les performances

Le checkpoint a gagné ~50% en vitesse (185ms vs 400ms). La restauration aussi (200ms vs 454ms). Merci CRIU v4.2 et les optimisations de zeropod.

kubectl top pods

Ce petit détail faisait tache — kubectl top pods plantait sur les pods checkpointés. Corrigé en v0.9.0.

Mais quelques limitations résiduelles

Je serais malhonnête si je disais que tout est parfait. Voilà ce qui reste problématique :

depuis septembre 2025, zeropod n’utilise plus --tcp-established pour CRIU. Ça veut dire que si votre container a des connexions TCP sortantes au moment du checkpoint, elles seront perdues. Dans la pratique, pour un serveur web, ça veut dire qu’il faut reconnecter la base de données après restore. Avec zeropod, la connexion MySQL est refaite automatiquement (la requête PHP en cours échoue, la suivante réussit). C’est un détail qui peut avoir son importance selon les cas.
Je n’ai testé que WordPress (Apache + mod_php) et MySQL. Les applications avec des websockets, du streaming, ou des connexions longues pourraient se comporter différemment.
J’ai eu des difficultés à le faire correctement fonctionner sur k3s.
J’ai observé un glitch (segfault Apache) sur le premier restore d’un pod WordPress fraîchement créé. Ce n’est pas reproductible après un cycle checkpoint/restore normal, mais si vous redéployez souvent vos pods, vous pourriez le rencontrer.

Verdict

Un an après, zeropod me parait un peu plus tenir ses promesses :

Même si ce n’était pas rédhibitoire, le performances de checkpoint/restore se sont nettement améliorées (~50% plus rapide), ce qui est toujours bon à prendre
Le support des probes Kubernetes a été ajouté, le blocage principal selon moi est levé
La stabilité générale est meilleure
Le test cascade (WordPress + MySQL) fonctionne

Je reste toujours aussi hypé par l’idée qu’on puisse freezer un container et le restaurer 10 secondes plus tard comme si de rien n’était. La magie de CRIU et d’eBPF combinés commence à se matérialiser, après des années d’attente.

Est-ce que je mettrais ça en production ? Disons que c’est moins risqué qu’il y a un an. Pour rigoler sur mon cluster perso, pourquoi pas. Pour une base de données en prod avec des connexions longues, je pense que je passe toujours mon tour ;-).

Mais franchement, pour le coup, le projet a bien évolué et mérite qu’on s’y attarde.

Test de CKE, le Kubernetes managé chez Clever Cloud (partie 2 - stockage)

Sun, 24 May 2026 18:00:00 +0200

Rappel de la partie 1

Dans la partie 1, on avait vu comment créer un cluster CKE, parcouru son anatomie (Exherbo Linux, Cilium, Materia etcd, konnectivity…), mesuré les temps de boot (~57s pour le control plane, excellent), testé les NodeGroups, et activé le CSI.

Dans cette deuxième partie, on va creuser ce qui touche au stockage et à des cas d’usages “un peu” avancés : cycle de vie des volumes, resize online, snapshots, et déploiement de vCluster avec données persistantes.

Activer le CSI et monter son premier volume

Comme on l’a vu en partie 1, le CSI n’est pas activé par défaut, mais un petit coup de CLI corrige ça rapidement :

clever k8s add-persistent-storage moncluster

Cette commande déploie le provisioner Ceph RBD et crée une StorageClass csi-rbd-sc qui devient la classe par défaut.

$ kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION
csi-rbd-sc (default) rbd.csi.ceph.com Delete Immediate true

On notera au passage ALLOWVOLUMEEXPANSION: true : on y reviendra.

Créons un PVC tout bête :

# pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: mon-pvc
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 1Gi
 storageClassName: csi-rbd-sc

$ kubectl apply -f pvc.yaml
$ kubectl get pvc mon-pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES
mon-pvc Bound pvc-2c2f058c-dc85-4006-865c-3437856462f5 1Gi RWO

Le binding prend environ 30 secondes (le temps que le provisioner crée l’image RBD dans le pool Ceph et l’attache). Rien de spécial, c’est du Kubernetes standard.

On monte le volume dans un pod, on écrit un fichier, on supprime le pod, on le recrée : les données sont toujours là. Jusque là, pas de surprise.

vCluster : un cas d’usage concret du stockage persistant

Maintenant qu’on a du stockage persistant, on peut faire des choses intéressantes. Généralement mon troll préféré, c’est de déployer Wordpress parce que évidemment Kubernetes c’est la meilleure plateforme pour déployer un Wordpress (/s).

Bon, cette fois ci j’ai décidé d’innover un peu et on va déployer vCluster (un cluster Kubernetes virtuel qui tourne dans votre cluster).

Note : à quoi ça sert, me direz vous ? Et bien, les usecases sont pas aussi clairs qu’on pourrait penser. vCluster vous donne un cluster Kubernetes complet, isolé, mais qui partage l’infrastructure du cluster hôte, y compris le CSI. En théorie ça permet de donner le cluster-admin à des gens sans donner les clés de l’infra complète à tout le monde. Je suis pas hyper convaincu par cette approche. Un usecase qui me parait moins dangereux, c’est pour des usages de type CI sans devoir monter un cluster complet, mais il y a des limitations aussi.

Installation :

vcluster create test-vcluster -n vcluster-test

Deux options pour s’y connecter :

Option 1 —> port-forward (le plus simple) :

$ vcluster connect test-vcluster -n vcluster-test -- kubectl get nodes
NAME STATUS ROLES AGE
control-plane-c367382a-22b1-4cef-b0cd-372bf83263c4-node Ready <none> 2m

vcluster connect monte un tunnel port-forward via l’API server (comme kubectl port-forward) et exécute la commande dans le contexte du vCluster. Ça marche sur CKE comme sur n’importe quel cluster Kubernetes.

Option 2 —> LoadBalancer (pour un accès durable sans tunnel) :

vcluster delete test-vcluster -n vcluster-test
vcluster create test-vcluster -n vcluster-test --expose --connect=false

Le flag --expose crée un Service LoadBalancer. On récupère l’IP et on génère un kubeconfig autonome :

$ LB_IP=$(kubectl get svc -n vcluster-test test-vcluster -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
$ vcluster connect test-vcluster -n vcluster-test \
 --server https://$LB_IP:443 \
 --insecure --print > /tmp/kube-vcluster.config

Le flag --insecure évite les soucis de certificat auto-signé, avec les risques de sécu que ça implique. A vos risques et périls… 💀

$ kubectl --kubeconfig /tmp/kube-vcluster.config get nodes
NAME STATUS ROLES AGE
test-vcluster Ready <none> 2m

Ce node test-vcluster contient tout notre cluster virtuel. Maintenant, la partie intéressante : créer un PVC dans le vCluster :

$ kubectl --kubeconfig /tmp/kube-vcluster.config apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: test-pvc
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 1Gi
 storageClassName: csi-rbd-sc
EOF

C’est là où c’est sympa : le vCluster délègue la création du volume au cluster hôte, qui le provisionne via Ceph RBD. On a pas besoin de reconfigurer le CSI, les storage classes, les secrets, etc. C’est totalement transparent.

Petite vérification côté CKE :

$ kubectl get pvc -A | grep test-vcluster
vcluster-test pvc-<...> Bound 1Gi RWO csi-rbd-sc

Le PVC est bien créé dans le namespace du vCluster sur le cluster hôte.

Overhead mesuré :

Pod	CPU	RAM
`test-vcluster-0`	~80m	~342 Mi
coredns (vCluster)	~2m	~13 Mi

C’est tout à fait raisonnable. 342 MiB pour un control plane K8s complet, c’est dans les clous.

Conclusion vCluster : ça marche, y compris avec de la persistance. Si vous avez besoin d’isoler des environnements tout en gardant accès au CSI, vCluster sur CKE est une option fonctionnelle.

Note : il est aussi possible d’exposer le vCluster via un LoadBalancer (flag --expose) pour un accès direct sans tunnel. Pratique si le vCluster doit rester accessible après la fermeture de votre terminal.

Volume expansion : agrandir un volume à chaud

Vous avez une base de données qui grossit, vous avez provisionné 1Gi au départ et maintenant c’est juste. Avec allowVolumeExpansion: true sur la StorageClass, on peut agrandir le volume sans downtime.

kubectl patch pvc mon-pvc -p '{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}'

Côté Ceph, l’image RBD est redimensionnée immédiatement. Le PV passe à 2Gi :

$ kubectl get pv
NAME CAPACITY ACCESS MODES STATUS CLAIM
pvc-<...> 2Gi RWO Bound default/mon-pvc

Mais le PVC côté utilisateur reste à 1Gi et le filesystem XFS n’a pas encore été agrandi. Le kubelet finira par détecter le changement et déclencher le NodeExpandVolume tout seul (la synchronisation est périodique), mais on peut accélérer en supprimant et recréant le pod qui monte le volume :

$ kubectl delete pod mon-app --force --grace-period=0
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
 name: mon-app
spec:
 containers:
 - name: app
 image: alpine
 command: ["sleep", "3600"]
 volumeMounts:
 - mountPath: /data
 name: data
 volumes:
 - name: data
 persistentVolumeClaim:
 claimName: mon-pvc
EOF

Dès que le volume est monté, le kubelet détecte qu’il a grandi et appelle le driver CSI pour un NodeExpandVolume. Le filesystem XFS est agrandi à chaud (xfs_growfs) et le PVC passe effectivement à 2Gi :

$ kubectl exec mon-app -- df -h /data
Filesystem Size Used Avail Use% Mounted on
/dev/rbd0 1.9G 47M 1.9G 1% /data

$ kubectl get pvc mon-pvc
NAME STATUS CAPACITY ACCESS MODES
mon-pvc Bound 2Gi RWO

VolumeSnapshots : le plus technique

Dernière fonctionnalité, et pas la plus simple : les snapshots de volumes.

Le driver Ceph RBD supporte les snapshots nativement. On le vérifie en regardant les logs du sidecar csi-snapshotter au moment de la création :

$ kubectl logs -n kube-system deployment/csi-rbdplugin-provisioner -c csi-snapshotter --tail=5
I0524 19:50:53.470970 snapshot_controller.go:339] createSnapshotWrapper: Creating snapshot for content snapcontent-<...> through the plugin ...

Pas d’erreur côté driver, la demande est acceptée et traitée.

Mais sur CKE, rien n’est pré-installé pour utiliser les snapshots. Il faut assembler les briques soi-même :

Étape 1 : installer les CRDs et le snapshot-controller

Les CRDs volumesnapshot* ne sont pas déployées sur CKE. Il faut les installer depuis le projet upstream external-snapshotter, ainsi que le snapshot-controller :

VERSION=v8.4.0
# CRDs
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
# Snapshot-controller (RBAC + deployment)
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml

Deux composants travaillent ensemble :

Le snapshot-controller (standalone) écoute les objets VolumeSnapshot et crée les VolumeSnapshotContent correspondants
Le csi-snapshotter (sidecar dans le provisioner) détecte les VolumeSnapshotContent et appelle le driver Ceph RBD pour créer/supprimer les snapshots

Les deux sont nécessaires.

Étape 2 : le piège des GroupSnapshot CRDs

Une fois les CRDs installées, vous créez votre VolumeSnapshotClass, votre VolumeSnapshot, et… rien ne se passe. Le VolumeSnapshotContent reste readyToUse: false indéfiniment.

Si vous regardez les logs du sidecar csi-snapshotter dans le provisioner, vous ne voyez aucune tentative de création de snapshot.

Pourquoi ? Parce que le sidecar est lancé avec un feature gate activé :

--feature-gates=CSIVolumeGroupSnapshot=true

Ce feature gate active le support des VolumeGroupSnapshot (la possibilité de snapshotter plusieurs volumes en une fois). Mais le sidecar attend les CRDs correspondantes pour initialiser son cache. Sans ces CRDs, le cache sync est bloqué, et le controller ne traite aucun VolumeSnapshot, pas même les snapshots unitaires (normaux, pas “group” quoi).

La solution : installer les CRDs groupsnapshot* :

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/groupsnapshot.storage.k8s.io_volumegroupsnapshotclasses.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/groupsnapshot.storage.k8s.io_volumegroupsnapshotcontents.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/groupsnapshot.storage.k8s.io_volumegroupsnapshots.yaml

Puis redémarrer le provisioner pour que le sidecar recharge sa config. Attention : le provisioner a une anti-affinity qui empêche deux pods de cohabiter sur le même node. Sur un cluster ALL_IN_ONE (1 node), ça bloque le rollout. Il faut supprimer directement l’ancien pod :

kubectl delete pod -n kube-system -l app=csi-rbdplugin-provisioner --force

Ce problème est spécifique aux clusters ALL_IN_ONE. Sur DEDICATED_COMPUTE ou DISTRIBUTED (multi-nodes), l’anti-affinity ne sera probablement pas bloquante.

Étape 3 : le secret Ceph dans le VolumeSnapshotClass

Une fois le sidecar relancé, les logs montrent… une erreur :

rpc error: code = Internal desc = provided secret is empty

Le driver Ceph RBD a besoin des credentials Ceph pour créer un snapshot, exactement comme pour créer un volume. Vous les trouverez dans le secret csi-rbd-secret du namespace kube-system. La StorageClass les référence déjà pour le provisionning :

parameters:
 csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret
 csi.storage.k8s.io/provisioner-secret-namespace: kube-system

Mais ces paramètres ne sont pas reportés automatiquement dans le VolumeSnapshotClass. Il faut les ajouter manuellement :

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
 name: csi-rbd-snapclass
driver: rbd.csi.ceph.com
deletionPolicy: Delete
parameters:
 clusterID: <votre-cluster-id>
 csi.storage.k8s.io/snapshotter-secret-name: csi-rbd-secret
 csi.storage.k8s.io/snapshotter-secret-namespace: kube-system

Le clusterID est celui de la StorageClass (visible dans kubectl get sc csi-rbd-sc -o yaml).

Étape 4 : le snapshot fonctionne

$ kubectl apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
 name: mon-snapshot
spec:
 volumeSnapshotClassName: csi-rbd-snapclass
 source:
 persistentVolumeClaimName: mon-pvc
EOF

$ kubectl get volumesnapshot mon-snapshot
NAME READYTOUSE SOURCEPVC RESTORESIZE AGE
mon-snapshot true mon-pvc 1Gi 6s

READYTOUSE: true immédiatement. Le snapshot Ceph RBD est créé en quelques secondes.

Étape 5 : restaurer un volume depuis un snapshot

Pour être VRAIMENT sûr que ça fonctionne, on peut faire un test (et oui, ça fonctionne)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pvc-restored
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 1Gi
 dataSource:
 name: mon-snapshot
 kind: VolumeSnapshot
 apiGroup: snapshot.storage.k8s.io
 storageClassName: csi-rbd-sc

$ kubectl apply -f pvc-restored.yaml
$ kubectl get pvc pvc-restored
NAME STATUS VOLUME CAPACITY
pvc-restored Bound pvc-... 1Gi

Bilan global

Deuxième partie, deuxième bilan. Qu’est-ce qu’on retient ?

Les points forts :

CSI Ceph RBD : là encore, un bon choix. Ceph, ça fonctionne bien dans Kubernetes. Provisionning, persistence, resize online — tout fonctionne et ce n’est pas une surprise.
vCluster + CSI : pour faire plaisir à Akanoa, j’ai fait du kubeception (Kubernetes in Kubernetes) et ça m’a permis de tester une feature de vCluster que j’avais jamais essayée => la délégation transparente du CSI vers le CSI de l’hôte

Les points d’attention :

Les snapshots ne sont pas “out of the box” : CRDs manquantes, feature gate inattendu, secret à recopier. Je ferai un petit email aux copain⋅es parce que ça me parait dommage de pas l’ajouter

Encore merci à l’équipe Clever Cloud pour m’avoir donné accès en avant-première et pour avoir pris le temps d’échanger sur mes retours. Je ne sais pas s’il y aura un 3ème article ou non. Wait and see ;-P

Zwindler's Reflection

Talos : un certificat en lecture seule qui reboot votre serveur

TL;DR

Contexte

Talos et ses rôles en deux minutes

Le bug : un HasPrefix qui ne protège rien

open() n’est pas une lecture : le cas du watchdog

Repro sur mon lab

Les autres impacts

Le maintainer m’a mieux noté que moi

Le fix : trois couches, defense in depth

“Takeaways”

Cloud Nord 2026 - Récap de ma journée à Lille

De retour de Cloud Nord 2026

Keynote d’ouverture : IA, souveraineté et cloud

IA for Ops on Scaleway

Coupable ! Le procès d’un container malveillant dans Kubernetes

Houston, on a un problème avec ETCD

Platform Engineering à l’échelle de Decathlon, ce qu’on a appris en 5 ans

Pause avant ma conf

J’ai mis Kubernetes dans 512 Mo de RAM. Et il restait de la place pour DOOM.

Fin de journée

Remerciements

BDX I/O 2026 : dédicace de mon livre, jeudi matin !

Les infos pratiques

Un retour aux sources

J’insiste un peu

Trouver des vulnérabilités dans l'open source quand on n'est pas spécialiste en sécurité

TL;DR

Pourquoi faire ça, au départ ?

Quel est le but, au juste ?

Ok ok, assez d’introduction : les LLM peuvent-ils trouver des failles sans expérience en cybersécurité ?

Vous avez déjà raté le coche

Parlons modèles (choisissez vos armes)

Et les modèles locaux ?

Mon pipeline

Contre-expertise

Noter à la juste valeur

Appropriez-vous le rapport

Ne faites pas partie du problème

Gardez une trace de tout

Vous n’êtes pas seul

Conclusion

Retrouvez-moi à Cloud Nord 2026 et au DevFest Toulouse !

Cloud Nord 2026 - Kubernetes dans 512 Mo de RAM, et un peu de DOOM

DevFest Toulouse 2026 — “Ah que coucou !”

Et BDX I/O ?

Venez me faire (ah que) coucou

Non pas un, mais deux projets mêlant impression 3D et électronique embarquée

À que coucou !

Alerte Rouge — mon Blinky à moi

Conclusion

zeropod v0.12.0 : un an après, le scale-to-zero tient-il ses promesses ?

Qu’est-ce que zeropod ?

Prérequis

Installation

Premier test : nginx

Restauration

Test des liveness probes

Ce qui a changé

Test grandeur nature

Un mot sur les évolutions entre v0.6.x et v0.12.0

Déploiement de WordPress (le cas d’usage réaliste :trollface:)

Et maintenant, le test qui tue : cascade WordPress + MySQL

Sur k3s : pas de chance, sur kubeadm : victoire

Ce qui a vraiment changé depuis v0.6.x

Mais quelques limitations résiduelles

Verdict

Test de CKE, le Kubernetes managé chez Clever Cloud (partie 2 - stockage)

Rappel de la partie 1

Activer le CSI et monter son premier volume

vCluster : un cas d’usage concret du stockage persistant

Volume expansion : agrandir un volume à chaud

VolumeSnapshots : le plus technique

Étape 1 : installer les CRDs et le snapshot-controller

Étape 2 : le piège des GroupSnapshot CRDs

Étape 3 : le secret Ceph dans le VolumeSnapshotClass

Étape 4 : le snapshot fonctionne

Étape 5 : restaurer un volume depuis un snapshot

Bilan global

Le bug : un `HasPrefix` qui ne protège rien

`open()` n’est pas une lecture : le cas du watchdog