Rootless n’a jamais été sans risque : un playbook pour CTO après CopyFail (CVE-2026-31431)

Si vous avez dû appliquer en urgence des correctifs à des nœuds Linux la semaine dernière, vous avez déjà reçu le message : rootless ne veut pas dire inoffensif. CopyFail (CVE-2026-31431) a percé un nouveau trou à travers les espaces de noms utilisateur et rappelé à tous que le noyau est la véritable surface d’attaque. Les conteneurs rootless réduisent le rayon d’explosion ; ils n’éliminent pas le risque lié au noyau. Si vos équipes laissent du code non approuvé s’exécuter dans des conteneurs rootless, vous pariez votre cluster sur un espoir et une table de syscalls.

Ce que CopyFail a changé (et pourquoi c’était prévisible)

Le gouvernement américain a publié une alerte sévère sur CopyFail touchant les principales versions de Linux, et les équipes sécurité se sont activées. Les premiers billets ont montré comment un bogue dans un chemin critique du noyau pouvait permettre une évasion de conteneur — même sous des configurations « rootless » que beaucoup d’entre nous utilisaient comme couverture de sécurité pour les machines des développeurs, les bacs à sable de CI ou des fonctionnalités SaaS multi‑locataires.

Ce n’est pas un événement isolé. Nous avons déjà vu cela : Dirty COW (CVE-2016-5195), Dirty Pipe (CVE-2022-0847), l’évasion de conteneur de runc (CVE-2019-5736), et une litanie régulière de bizarreries autour des espaces de noms utilisateur et d’overlayfs. La leçon en une est la même à chaque fois : si le noyau fait partie de votre frontière de confiance, vous perdrez tôt ou tard face à un bogue du noyau. Rootless aide, mais ce n’est pas un bac à sable. C’est un autre ensemble de façons de se tirer une balle dans le pied.

En parallèle, les attaquants exploitent massivement d’autres points faibles (voir la vague de bogues cPanel). Lorsqu’il existe un chemin facilement militarisable vers root ou l’évasion, Internet devient votre red team. Supposez une fenêtre de 24 à 72 heures entre un PoC et des scans à grande échelle. Si votre processus de patch est plus lent que cela, vous n’avez pas un problème de vulnérabilité — vous avez un problème d’opérations.

Pour les CTO : transformez cela en une décision d’isolation claire

Votre rôle n’est pas de devenir expert du noyau. Votre rôle est de fixer une politique : quelles charges obtiennent quel niveau d’isolation, à quelle vitesse vous patchez, et ce que vous faites quand le bac à sable échoue. Voici un cadre concret que nous utilisons avec nos clients.

1) Classer les charges selon la confiance et la portée d’impact

• Tier 0 (Services internes de confiance) : Votre propre application et votre infra, single-tenant, sans code ni binaires fournis par des clients.
• Tier 1 (Parcours de code étendus par des partenaires) : Plugins, filtres WASM, transformations de données construits par des partenaires de confiance avec contrats et audits.
• Tier 2 (Logique/données fournies par des clients avec exécution) : Fonctions client, générateurs de rapports, UDF SQL, adaptateurs de modèles, builds de prévisualisation de PR.
• Tier 3 (Hostiles/Non approuvés – Internet) : Soumissions publiques, CI pour dépôts externes, bacs à sable éphémères, agents exécutant des outils arbitraires, tout ce qui analyse et/ou exécute en masse des entrées utilisateur.

La règle de décision est simple : si un bogue du noyau ou du runtime pouvait permettre à une charge Tier 2/3 d’atteindre l’hôte ou un autre locataire, basculez‑la dès maintenant vers un bac à sable plus fort.

2) Choisir l’isolation adaptée au niveau

• Conteneurs simples (rootful ou rootless) sur un noyau partagé : Acceptable pour Tier 0 si vous appliquez un durcissement (seccomp, AppArmor/SELinux, root en lecture seule, pas d’escalade de privilèges). Utilisez rootless spécifiquement pour les ordinateurs des développeurs et une CI légère, mais considérez‑le comme une commodité, pas comme une frontière de sécurité.
• gVisor (runsc) / GKE Sandbox / équivalent Azure Kata-WSL2 : Un bac à sable de compatibilité des appels système qui s’interpose sur l’API du noyau. Adapté à Tier 1–2. Surcharge typique : 10–30 % sur les charges intensives en syscalls, quasi‑natif sur les charges liées au CPU, pénalité de latence p99 mineure (+0,5–2 ms) pour les microservices à trafic réseau important. Les chiffres varient ; mesurez sur votre code.
• Kata Containers avec microVM Firecracker/KVM : Virtualisation matérielle avec microVM par pod. Adapté à Tier 2–3. CPU quasi natif (3–10 % de surcharge), taxe mémoire ~50–120 Mo par bac à sable, cold starts +150–400 ms. Isolation forte entre locataires avec un coût modérément prévisible.
• VM complètes ou FaaS managé avec bacs à sable durcis : Pour le véritablement hostile. Si vous exécutez du code public, de l’analyse de malwares, ou des marketplaces d’agents, c’est votre valeur par défaut. Plus lourd opérationnellement sauf si vous utilisez un service managé.

Reality check : si une charge est Tier 2 ou 3 et que vous êtes encore sur des conteneurs rootless parce que « c’est plus simple », vous acceptez un rayon d’explosion « kernel‑day » que CopyFail vient de rendre très tangible.

3) Budgétez le surcoût de manière adulte

L’isolation n’est pas gratuite. Planifiez‑la :

• CPU : Kata/Firecracker ajoute ~3–10 % dans des microservices typiques ; gVisor 10–30 % pour les parcours riches en syscalls. Pour l’inférence ou la compression liées au calcul, la surcharge peut être inférieure à 5 %.
• Mémoire : Les microVM coûtent ~50–120 Mo/pod de plus que des conteneurs simples. 100 pods ≈ 5–12 Go de RAM supplémentaires sur le pool de nœuds. Sur des nœuds contraints par la mémoire, c’est le facteur limitant.
• Latence : gVisor ajoute souvent moins de 2 ms au p99 ; les cold starts de Kata augmentent de 150–400 ms par pod sauf si vous mettez en pool ou pré‑chauffez les bacs à sable. Les services de longue durée amortissent cela ; le trafic en pics nécessite des pools chauds.

Traduisez ceci en dollars. Si votre cluster coûte 80 k$ par mois en calcul, migrer 20 % des pods vers Kata peut ajouter 5–8 % de coût (4–6 k$ par mois). C’est moins cher qu’un seul incident de sécurité avec compromission d’hôte et notifications aux clients.

Votre plan de durcissement en 6 volets pour 2026

1) Stratégie noyau et OS

• Figez sur des noyaux LTS avec backports éditeur (Ubuntu LTS HWE, RHEL, Bottlerocket). Évitez d’exécuter deux branches de noyau différentes dans le même cluster — la diversité complique les patchs d’urgence.
• Runbook « exploit = panne » : Traitez une CVE critique d’évasion de conteneur comme un Sev‑1. Évacuez (drain) et patchez en moins de 24 heures. Visez 6 heures pour les bogues exploitables via Internet. Entraînez‑vous deux fois par an.
• Évitez les combinaisons exotiques de systèmes de fichiers et d’espaces de noms sauf si elles sont testées en charge (idmapped mounts, fonctionnalités de bord d’overlayfs). Elles élargissent votre surface d’attaque du noyau.

2) Contrôles du runtime qui mordent vraiment

• Profils seccomp par défaut : Bloquez les appels système dangereux partout. Docker et containerd fournissent des valeurs par défaut sensées ; personnalisez par service. Si une équipe demande des syscalls sans borne, traitez‑le comme une exception avec validation.
• SELinux/AppArmor en mode enforcing : Choisissez‑en un et laissez‑le activé. Des LSM désactivés sont le canari d’une culture laxiste.
• No-new-privileges, root en lecture seule, suppression des capacités par défaut : Refusez CAP_SYS_ADMIN, CAP_NET_RAW, CAP_SYS_MODULE partout sauf s’il existe un ticket et une exception bornée dans le temps.
• Sécuriser correctement le « rootless » : Utilisez userns remap, restreignez les montages hôte, et considérez rootless comme une couche de confort pour les machines des développeurs — pas une dérogation de politique pour des charges non approuvées.

3) Politiques Kubernetes qui envoient les bons pods vers les bons bacs à sable

• RuntimeClass : Définissez des classes comme native, gvisor, kata. Le contrôle d’admission (Kyverno/Gatekeeper) doit imposer que les espaces de noms Tier 2–3 ne déploient que sur kata ou gvisor.
• Sécurité des pods : Appliquez des politiques baseline ou restricted à l’échelle du cluster. Refus par défaut de hostNetwork, hostPID, hostIPC et privileged. Exigez readOnlyRootFilesystem: true.
• Pools de nœuds et taints : Séparez les pools de nœuds pour les runtimes sandboxés. Marquez‑les (taints) afin que seuls les pods demandant le RuntimeClass correspondant y soient planifiés.
• Options managées d’abord : GKE Sandbox (gVisor) est clé en main. AKS prend en charge Kata via Confidential Containers. EKS prend en charge Kata avec containerd et Bottlerocket. Utilisez la plomberie du cloud sauf si vous avez besoin d’un contrôle sur mesure.

4) Choix supply chain qui réduisent la portée d’impact

• Images distroless/minimales : Moins de binaires, moins de sous‑systèmes, moins de surprises. Analysez la présence de fichiers setuid ; bloquez‑les.
• Signer et vérifier : Utilisez Sigstore/cosign et imposez la vérification à l’admission. Maintenez des SBOM et alertez en cas de dérive.
• Images de base immuables : Cadence de rafraîchissement mensuelle avec backports de sécurité. Si une image a plus de 60 jours, refusez le déploiement sans exception.

5) Observabilité qui détecte les comportements « impossibles »

• Détection d’anomalies de syscalls : Falco ou des capteurs eBPF peuvent repérer les pivots conteneur‑vers‑hôte. N’en faites pas un bouclier ; utilisez‑les pour raccourcir le temps de détection.
• Indicateurs de référence par runtime : Suivez les cold starts, le RSS par bac à sable, et les deltas p99 vs la référence. Si Kata ajoute 300 ms sur un parcours avec un SLO de 200 ms, c’est un problème de conception, pas de sécurité.
• Canaris d’exploit : Conservez un pod de test qui tente des comportements connus d’évasion de bac à sable en non‑prod. Alertez si quelque chose d’atypique réussit après un cycle de patch.

6) Humains et processus : la vitesse est votre rempart

• Définissez un SLO de patch : Les CVE critiques d’évasion de conteneur patchées sous 24 heures. Auditez‑le comme la disponibilité.
• Processus d’exception avec bouton d’arrêt : Si une équipe a besoin de hostNetwork ou de capacités supplémentaires, faites expirer l’exception sous 14 jours et notifiez la sécurité lors du renouvellement.
• Autonomisation des équipes nearshore : Donnez aux ingénieurs à distance des bacs à sable en self‑service avec le bon RuntimeClass intégré. Ne laissez pas la commodité les ramener à « juste run docker avec --privileged ».

Où rootless garde du sens

Ne jetez pas complètement rootless. Cela vous apporte encore de la sécurité concrète sur les machines des développeurs et certains runners CI :

• Ordinateurs portables des développeurs : Rootless + remappage des espaces de noms utilisateur signifie moins de modifications accidentelles de l’hôte et des schémas de montage moins risqués. Associez‑le à une VM dédiée de développement, et vous réduisez encore le rayon d’explosion.
• CI basique pour votre propre code : Rootless convient pour construire et tester vos services avec des bases immuables et sans compilateurs ni interprètes tiers récupérant depuis Internet pendant le build. Au moment où vous acceptez des PR non approuvées ou des chaînes d’outils arbitraires, passez à Kata ou gVisor.

Le modèle mental : Rootless est un ciseau bien affûté dans un bois familier. Les microVM sont les gants de sécurité quand vous tendez le ciseau à un inconnu.

Comment déployer cela sans réécriture

Semaines 0–2 : Décider et prouver

• Taguez 10 services comme Tier 2 ou 3. Choisissez‑en deux à migrer d’abord — un sensible à la latence, un intensif CPU.
• Montez un pool sandbox : Un groupe de nœuds avec Kata et un avec gVisor (managé si possible). Définissez des objets RuntimeClass et appliquez des taints aux nœuds.
• Mesurez avant/après : Établissez la référence de latence p50/p99, CPU, RSS, cold start et taux d’erreurs pour ces deux services. Acceptez que +5–10 % soit le coût de faire des affaires avec du code hostile.

Semaines 3–6 : Faire appliquer la politique

• Contrôle d’admission activé : Règles Gatekeeper/Kyverno qui forcent les espaces de noms Tier 2/3 à utiliser kata ou gvisor ; bloquent les flags privilégiés ; exigent readOnlyRootFilesystem.
• Garde-fous supply chain : Vérification Cosign obligatoire ; images âgées de plus de 60 jours rejetées ; aucun fichier setuid autorisé dans les images.
• SLO de patch en production : Exercez le runbook de drain‑and‑patch. Suivez le temps moyen de patch et publiez‑le comme la disponibilité.

Semaines 7–12 : Optimiser et étendre

• Dimensionnez correctement les pools : La mémoire est votre limite avec Kata. Si chaque bac à sable coûte +80 Mo et que vous planifiez 300 pods par groupe de nœuds, c’est +24 Go. Dimensionnez les nœuds en conséquence ou réduisez la densité de pods.
• Pré‑chauffer les bacs à sable : Pour les systèmes en pics, maintenez un pool de VM Kata chaudes ou basculez ces parcours vers gVisor si la latence prime.
• Élargissez la couverture : Migrez le reste de Tier 2 et tout service Tier 1 qui analyse des formats complexes contrôlés par des attaquants (PDF, archives, images, poids de modèles).

À ne pas faire

• Ne faites pas confiance à « privilégié mais prudent ». Les conteneurs privilégiés sont un shell sur l’hôte avec du marketing. Si vous en avez besoin, isolez‑les dans un pool de nœuds dédié derrière un bastion et traitez‑les comme des machines particulières.
• Ne supposez pas que la supervision vous sauvera. La détection réduit la portée après compromission ; elle ne la prévient pas. Les bogues de la classe CopyFail exigent prévention et patch rapide.
• Ne confondez pas commodité dev et politique prod. Rootless est excellent localement. Cela n’en fait pas une stratégie multi‑locataire.

Rattacher cela à votre feuille de route (et votre budget)

Ce changement n’exige pas de réécrire la plateforme. C’est une décision de runtime plus de la discipline opérationnelle :

• Décision de runtime : Faites correspondre les niveaux à RuntimeClass et aux pools de nœuds. Utilisez d’abord les options managées du cloud.
• Discipline opérationnelle : Faites respecter les valeurs par défaut de sécurité, patchez vite, et mesurez le surcoût. Prévoyez une augmentation de 5–10 % du coût de calcul pour la fraction de charges qui nécessitent vraiment une isolation plus forte.
• Alignement business : Dites au produit et à la finance : nous rachetons une classe de risques extrêmes pour quelques dizaines de milliers par an. C’est moins cher qu’une seule brèche avec réponse à incident, gestes commerciaux, et érosion de la confiance.

CopyFail n’a pas changé la physique des conteneurs ; il a percé le récit selon lequel « rootless équivaut à suffisamment sûr ». La bonne réponse n’est pas la panique. C’est la clarté. Décidez du code auquel vous faites réellement confiance. Donnez au reste un vrai bac à sable. Et entraînez‑vous à patcher jusqu’à ce que ce soit ennuyeux.

Points clés

• Rootless réduit le rayon d’explosion mais ne met pas le noyau en bac à sable. Considérez‑le comme une commodité, pas une sécurité, pour du code non approuvé.
• Utilisez gVisor pour les charges Tier 1–2 et Kata/Firecracker pour Tier 2–3 ; budgétez 3–30 % de surcoût selon la charge.
• Faites appliquer RuntimeClass, la sécurité des pods et des règles d’admission pour que les bons pods atterrissent par défaut sur la bonne isolation.
• Figez sur des noyaux LTS, répétez un SLO de patch de 6–24 heures pour les CVE d’évasion de conteneur, et évitez les fonctionnalités noyau exotiques dont vous n’avez pas besoin.
• Attendez‑vous à +50–120 Mo de RAM par bac à sable Kata et +150–400 ms aux cold starts ; pré‑chauffez ou mettez en pool pour tenir vos SLO.
• Signez les images, utilisez des bases distroless, et rejetez les images âgées de plus de 60 jours ou contenant des fichiers setuid.
• Mesurez le surcoût d’isolation sur votre propre code ; publiez les chiffres pour que les équipes puissent concevoir en conséquence.