Quand Ubuntu s’éteint : le playbook du CTO pour miroirs, proxys OCI et builds hermétiques

Si une attaque DDoS contre l’infrastructure d’Ubuntu peut bloquer votre CI/CD pendant des heures, votre chaîne d’approvisionnement logicielle est trop fragile. Les pannes d’Ubuntu de la semaine dernière n’avaient rien d’exotique — juste assez de douleur réseau pour faire bloquer apt update, ralentir les pulls Docker et faire exploser vos fenêtres de patch. La leçon : partez du principe que les amonts tomberont au pire moment, et concevez votre système en conséquence.

Ce billet est le cadre de décision et la feuille de route de build que j’aimerais voir sur le bureau de chaque CTO : comment durcir votre organisation avec des miroirs apt locaux, des proxys de registres OCI, des caches pour les écosystèmes de packages, et des builds hermétiques. Ce n’est pas du théâtre marketing. C’est un effort de deux à six semaines qui transforme le chaos amont en non‑événement.

Ce qui a réellement cassé — et pourquoi vous l’avez ressenti

Quand les services d’Ubuntu ont été bridés, vous avez probablement vu tout ou partie de ceci :

• Des builds bloqués sur apt update et apt install pour les images de base ou les AMIs.
• docker pull ubuntu:22.04 ou des images runtime en time‑out parce qu’un registre public était lent et non mis en cache.
• Des nœuds Kubernetes incapables de démarrer des pods parce que les pulls d’images depuis Docker Hub ou GHCR étaient soumis au rate limiting et non passés par un proxy.
• Des fenêtres de patch passant de 30 minutes à plusieurs heures parce que les miroirs étaient incohérents.

Rien de tout cela n’est propre à Ubuntu. Debian, Alpine, npm, PyPI, crates.io, Docker Hub — tous les services publics subissent des pannes et des limites de débit. La vraie question est de savoir si votre pipeline se dégrade gracieusement ou s’arrête de livrer.

Cadre de décision : Cache, Miroir ou Hermétique ?

Vous avez trois leviers, par ordre croissant d’effort et de réduction du rayon d’impact :

1. Mettre en cache les artefacts publics derrière des proxys locaux. Rapide à mettre en place. Excellent pour la bande passante et les courtes pannes. Dépend toutefois de l’amont en cas de miss du cache.
2. Mirrorer des dépôts spécifiques dans votre propre stockage et les servir en interne. Plus de travail. Élimine la plupart des dépendances à la disponibilité amont pour les versions connues et validées.
3. Builds hermétiques avec entrées épinglées, images adressées par contenu (digest) et politique d’egress sur liste d’autorisation. C’est l’effort le plus élevé. Vous obtenez de la reproductibilité et un vrai contrôle de la supply chain.

Choisissez selon deux facteurs : votre cadence de release et votre appétence au risque. Si vous shippez chaque semaine et opérez sur des marchés réglementés (fintech, santé, infra), visez au minimum Miroirs maintenant et Hermétique le trimestre prochain. Si vous êtes pre‑product ou avec burn limité, commencez par des Caches dès ce sprint et montez en gamme ensuite.

L’architecture cible (pragmatique, pas parfaite)

Voici la stack que nous déployons pour des startups US avec notre équipe plateforme basée au Brazil — 6–8 heures de recouvrement horaire, et en général 20–30 % moins chère qu’un sprint SRE US, mais surtout livrée en semaines, pas en trimestres :

• Proxy de registre OCI avec cache (Harbor, Artifactory ou registry:2 en mode proxy) pour Docker Hub, GHCR, Quay et vos propres registres privés.
• Mise en cache apt et snapshots via apt-cacher-ng pour des gains immédiats, plus un miroir sélectionné et versionné avec aptly ou reprepro pour les Ubuntu/Debian que vous utilisez réellement.
• Dépôts de packages des langages proxifiés en local : Verdaccio pour npm, devpi pour PyPI, Nexus/Artifactory pour Maven/Gradle, Athens ou goproxy pour Go, un miroir d’index sparse pour Cargo.
• Couche de build hermétique pour vos services les plus critiques avec Bazel ou Nix, images de base des conteneurs épinglées par digest, émission d’un SBOM et signature d’images via Sigstore cosign.
• Politique d’egress qui force les nœuds de build et de CI à ne passer que par vos proxys et miroirs ; la préproduction dispose d’un kill switch en un clic pour l’internet amont afin de tester la résilience.

Cela fonctionne en cloud (EKS/GKE/AKS) et on‑prem. Vous pouvez commencer par des caches en une journée, ensuite snapshotter/miroiter les chemins chauds, puis verrouiller avec des builds hermétiques au fil du refactoring de vos Dockerfiles et pipelines.

Étape 1 : Épinglez et proxifiez vos images de conteneurs

La plupart des lenteurs de CI commencent par un FROM ubuntu:22.04 et un pull dynamique depuis un registre public. Deux correctifs changent la donne :

• Épingler par digest. Au lieu de FROM ubuntu:22.04, utilisez FROM ubuntu@sha256:… Cela élimine la dérive des tags et garantit une reproductibilité bit‑à‑bit. Chaque image de base non épinglée est une panne et un bug de supply chain en puissance.
• Introduire un registre proxy. Déployez Harbor ou registry:2 avec cache proxy pour docker.io, ghcr.io et quay.io. Pointez tous les agents de build et clusters vers votre proxy comme miroir de registre par défaut. La plupart des organisations réduisent le temps de pull de 50 à 80 % sur hit de cache et deviennent immunes aux limites de débit publiques.

Arbitrages : vous devez opérer un stockage qui passe à l’échelle (S3/GCS/Azure Blob conviennent), surveiller le taux de hit du cache et sauvegarder les métadonnées. Mais la charge opérationnelle reste modeste — pensez à une petite VM t3.medium plus du stockage objet pour démarrer.

Étape 2 : Stabilisez apt avec caches et snapshots

Commencez par apt-cacher-ng pour réduire immédiatement la lenteur d’apt. Un proxy, une entrée DNS, et les builds arrêtent d’errer sur la ferme de miroirs publics à chaque installation de paquet.

Puis passez à un miroir avec snapshots pour que votre ensemble de paquets cesse de changer sous vos pieds :

• Ne miroitez que ce que vous utilisez. Utilisez aptly ou reprepro pour créer un miroir Ubuntu/Debian sélectionné pour vos architectures et composants (par ex., jammy main, universe, security). Publiez des snapshots vers S3 et servez‑les via CloudFront ou une petite VM NGINX dans votre VPC.
• Un snapshot par release. Créez un instantané daté à chaque coupe de branche de release ; pointez la CI vers cette URL de snapshot. Vous obtiendrez des résultats apt install déterministes et pourrez faire évoluer les snapshots à votre rythme.

Oui, vous pouvez vous contenter de caches. Mais le jour où un paquet est retiré ou qu’une dépendance bouge en dessous de vous, vous regretterez de ne pas avoir un snapshot pour revenir en arrière.

Étape 3 : Ramenez les écosystèmes de langages à l’intérieur du périmètre

La panne d’Ubuntu n’a pas touché que les paquets OS. Si npm, PyPI ou crates.io clignent des yeux, votre monorepo cale. Faites passer tout cela par vos propres endpoints :

• npm : Verdaccio avec uplinks vers registry.npmjs.org. Hébergez aussi vos paquets privés ici.
• PyPI : devpi ou Artifactory. Pré‑mettez en cache vos wheels les plus courantes — les builds sont bien plus rapides en évitant les builds depuis les sources.
• Maven/Gradle : Sonatype Nexus ou Artifactory en proxy et hébergeur. Pointez votre settings.xml dessus et c’est terminé.
• Go : exécutez Athens ou configurez GOPROXY vers votre propre serveur goproxy.
• Rust : utilisez le protocole de registre sparse de Cargo et miroitez l’index ; vous pouvez héberger un registre interne pour vos crates propriétaires.

Bonus : une fois ces écosystèmes proxifiés, vous pouvez épingler des versions exactes dans vos lockfiles sans craindre les 404 ni le rate limiting. Vos SBOMs de supply chain prennent du sens, car les entrées ne flottent plus.

Étape 4 : Rendez les services critiques hermétiques

Des builds hermétiques signifient que chaque entrée est déclarée, épinglée et récupérée depuis un emplacement de confiance que vous contrôlez. C’est le ticket d’entrée si vous prenez SLSA et la reproductibilité au sérieux. Une façon pragmatique de démarrer :

• Choisissez 2–3 services critiques (p. ex. billing, auth, ingestion). Convertissez leurs Dockerfiles pour utiliser des images de base épinglées par digest et déplacez la logique de build dans des règles Bazel ou des dérivations Nix.
• Générez des SBOMs (CycloneDX ou SPDX) pendant le build et signez les images avec cosign en utilisant votre KMS cloud. Faites appliquer la vérification des signatures au déploiement via un contrôleur d’admission (Kyverno ou OPA Gatekeeper).
• Préférez des bases Distroless ou Wolfi

Utilisez les images minimalistes Distroless ou Chainguard Wolfi pour réduire drastiquement les pièces mobiles. Mise en garde : la musl libc d’Alpine peut casser certaines dépendances IA/ML et liées à glibc ; Wolfi propose des variantes compatibles glibc, et Distroless a des options glibc. Testez avant une adoption massive.

Arbitrages : Bazel/Nix ajoutent une courbe d’apprentissage et du travail CI. Faites‑le là où le retour est maximal d’abord. Sur un trimestre, migrez le reste de la flotte à mesure que vous touchez les services.

Étape 5 : Verrouillez l’egress et entraînez la panne

La résilience que vous n’exercez pas est du théâtre. Deux gestes opérationnels la rendent réelle :

• Restreignez l’egress de la CI/des builds à vos proxys et miroirs. En cloud, utilisez des passerelles d’egress VPC et des security groups ; on‑prem, une liste d’autorisation sur le pare‑feu. L’objectif est simple : si un build ne peut pas atteindre un amont directement, vous saurez que vous n’en dépendez pas en douce.
• Faites des exercices de panne. Une fois par sprint, activez un feature flag qui bloque l’accès internet sortant sur un cluster de préproduction et le sous‑réseau de votre CI. Vos builds finissent‑ils ? De nouveaux pods se planifient‑ils ? Vous trouverez des trous — corrigez‑les.

Mesurez le succès avec un KPI simple : le pourcentage de builds qui réussissent avec la connectivité amont coupée. Démarrez probablement sous 20 %. Visez 90 % et plus en un trimestre pour les services principaux.

Ce que cela coûte (et ce que ça économise)

La facture cloud d’abord : un petit proxy de registre et des proxys d’artefacts coûtent quelques centaines de dollars par mois en temps de VM et stockage. Les miroirs avec snapshots ajoutent du stockage S3/Blob qui croît avec votre volume de paquets ; attendez‑vous à quelques dizaines à quelques centaines de Go sur plusieurs mois. En retour, vous économisez sur :

• Temps développeur : si votre org fait 300 builds/jour et que 20 % d’entre eux pendent 10 minutes lors d’une instabilité amont, cela fait 600 minutes/jour perdues. À un taux chargé d’ingénierie de 150 $/heure, vous brûlez 1,5 k$/jour pour rien — aisément plus que le coût mensuel d’un bon setup proxy/miroir.
• Frais d’egress : les caches proxy réduisent les téléchargements répétés entre CI et clusters. En multi‑région, cela économise réellement.
• Agitation d’incident : réveiller l’infra à 1 h du matin pour expliquer pourquoi apt est lent est la définition même de la corvée évitable.

Temps de mise en œuvre avec un·e ingénieur·e plateforme senior ou un binôme SRE nearshore :

• Semaine 1 : registre proxy en ligne, apt-cacher-ng opérationnel, proxys npm/PyPI configurés, CI routée via les proxys.
• Semaines 2–3 : miroir apt sélectionné + snapshots, premier service en build hermétique avec SBOM + signature, liste d’autorisation d’egress appliquée en CI/préproduction.
• Semaines 4–6 : étendez le modèle hermétique au top 5 des services, déployez les politiques d’admission en prod, exercices de chaos routiniers.

Arbitrages à reconnaître d’emblée

• Vous opérez plus d’infra. Oui — des services petits et ennuyeux. Gardez‑les en code (Terraform/manifests Kubernetes), avec métriques et sauvegardes.
• L’épinglage ralentit les workflows « on met juste à jour ». C’est le but. Vous mettez à jour à votre rythme, avec tests, pas un mardi aléatoire pendant un DDoS.
• Les builds hermétiques ne sont pas gratuits. Bazel/Nix ajoutent de la charge cognitive. Commencez là où ça compte ; ne l’imposez pas partout dès le premier jour.
• Les images minimales peuvent nuire au débogage. Ajoutez une variante de debug, ou utilisez des sidecars éphémères pour le troubleshooting, pas dans les images de production.

Durcir Kubernetes pour que les pods puissent toujours pull

Deux patterns empêchent les pulls d’images de devenir votre prochain incident à 3 h du matin :

• Registres locaux au nœud : exécutez un daemonset qui fournit un cache proxy local par nœud. Cela évite que N pods sur M nœuds ne se ruent en troupeau sur un proxy distant.
• Préchauffez le cache : pré‑puller les images critiques avec un daemonset au déploiement, ou intégrez‑les dans les AMIs de nœud avec Packer. Définissez imagePullPolicy à IfNotPresent pour les services stables afin de réduire le churn.

Combinez cela avec la vérification de signature : n’admettez que les images signées par votre clé, récupérées via votre proxy. Si une image malveillante apparaît sur un registre public pendant une panne, ce ne sera pas vous qui la pullerez.

Bonus conformité : une reproductibilité que l’on respecte

SOC 2, ISO 27001 et surtout SLSA vous poussent vers des builds traçables et reproductibles. Avec des digests épinglés, des SBOMs et des artefacts signés, vos preuves cessent d’être du PowerPoint et deviennent une vérité cryptographique. Si votre roadmap inclut la vente aux entreprises ou au secteur public, vous aurez besoin de cette posture de toute façon. Le faire maintenant pour la résilience paye double.

Plan 30‑60‑90 jours réellement exécutable

Jours 0–30

• Montez Harbor ou registry:2 en mode proxy avec backend de stockage objet ; routez la CI et les clusters vers lui.
• Déployez apt-cacher-ng ; ajoutez une configuration de proxy apt globale pour les builders et les images AMI.
• Mettez en place Verdaccio et devpi ; reconfigurez les gestionnaires de paquets dans la CI.
• Commencez à épingler les images de base par digest pour tous les Dockerfiles touchés ce mois‑ci.
• Introduisez un blocage d’egress en préproduction et exécutez votre premier exercice « upstream‑off ».

Jours 31–60

• Construisez un miroir sélectionné Ubuntu/Debian avec aptly ou reprepro ; publiez des snapshots vers des endpoints internes ; pointez la CI vers ces snapshots.
• Convertissez deux services critiques en builds hermétiques avec Bazel ou Nix ; générez des SBOMs et signez les images avec cosign ; appliquez la vérification des signatures en préproduction.
• Pré‑puller les images runtime critiques via un daemonset ; intégrez‑les aux images de nœud quand c’est pertinent.
• Instrumentez les métriques : taux de hit du cache, succès des builds avec upstream coupé, temps moyen de pull d’image.

Jours 61–90

• Étendez les builds hermétiques à vos 5–8 services principaux ; déployez les politiques d’admission en production.
• Cadrez le change management autour de l’avancement des snapshots et des mises à jour d’images de base avec une cadence hebdo et des plans de rollback.
• Organisez une vraie journée de panne simulée : bloquez les amonts pendant 4 heures ; produisez un post‑mortem avec écarts et actions.

Pourquoi maintenant

Deux signaux sont tombés la même semaine : une instabilité de l’infrastructure Ubuntu et une faille de sécurité Linux largement discutée, trouvée via une analyse assistée par IA. Traduction : les amonts restent fragiles, et les attaquants deviennent meilleurs pour trouver les fissures. Les deux problèmes appellent la même réponse — réduire les pièces mobiles, tirer depuis des endroits de confiance, et rendre vos builds reproductibles.

Vous n’avez pas besoin d’une réécriture de plateforme sur 12 mois. Vous avez besoin d’un mois de travail focalisé et de la volonté de verrouiller des portes que vous vouliez déjà fermer. Si vous n’avez pas la capacité, confiez‑la à une équipe qui l’a ; nos SREs au Brazil livrent ce pattern sur un périmètre fixe. Dans tous les cas, n’attendez pas la prochaine panne pour apprendre deux fois la même leçon.

Points clés

• Arrêtez de dépendre des amonts publics au moment du build. Ajoutez des caches proxy pour l’OCI et les écosystèmes de langages dès ce sprint.
• Mirrorez et snapshottez les paquets OS que vous utilisez réellement ; pointez la CI vers des snapshots pour des apt install déterministes.
• Épinglez les bases de conteneurs par digest, générez des SBOMs et signez avec cosign ; appliquez la vérification via un contrôleur d’admission.
• Restreignez l’egress de la CI aux proxys et faites des exercices réguliers « upstream‑off » ; visez 90 % et plus de succès de build avec l’internet bloqué.
• Démarrez les builds hermétiques là où ça compte et étendez sur un trimestre ; des bases minimales comme Distroless ou Wolfi réduisent le risque et le bloat.
• Le coût est faible comparé au temps développeur perdu ; les bénéfices de conformité sont un bonus dont vous aurez de toute façon besoin.