Cette faille critique dans Kubernetes, révélée en janvier 2026, exploite la permission RBAC nodes/proxy GET pour exécuter du code à distance dans n’importe quel Pod du cluster, sans laisser de trace dans les logs d’audit. Cette vulnérabilité repose sur un contournement des vérifications d’autorisation : le Kubelet, via une connexion WebSocket, autorise l’exécution de commandes (/exec) en validant uniquement un GET initial, sans exiger le verbe CREATE normalement requis. L’absence de logs d’audit côté Kubelet aggrave le risque, permettant des attaques discrètes, notamment sur des composants système comme etcd ou kube-apiserver.
L’article souligne que des ServiceAccounts aux noms évocateurs, comme rook-ceph-system, combinés à des permissions étendues (accès en lecture aux Secrets), constituent des cibles privilégiées pour une élévation de privilèges. Une analyse des Roles et ClusterRoles est recommandée, avec des outils comme le script de détection du chercheur Graham Helton. Parmi les composants vulnérables figurent des outils courants comme l’OpenTelemetry Collector, dont les ServiceAccounts associés pourraient être exploités pour compromettre l’ensemble du cluster.
Pour atténuer ce risque, l’auteur propose plusieurs correctifs et mesures préventives, comme l’activation de la feature gate KEP-2862 pour un contrôle granulaire des autorisations Kubelet, l’utilisation de CiliumNetworkPolicy pour bloquer l’accès au port 10250, ou encore l’application de politiques Kyverno pour interdire la création de Roles incluant nodes/proxy. La surveillance des audit logs et la mise à jour des composants (comme Rook-Ceph) sont également essentielles, bien que Kubernetes ait classé cette faille comme un "comportement intentionnel" non corrigé en l’état.
Ce billet présente le test de CKE (Clever Kubernetes Engine), l'offre Kubernetes managée de Clever Cloud, par l'auteur du blog. L'idée principale est de mettre en avant une solution Vanilla Kubernetes sans verrouillage propriétaire, avec des particularités comme une implémentation serverless de l'API etcd (Materia) et une infrastructure souveraine en France. L'activation de CKE, initialement cachée, nécessite un feature flag via la CLI ou l'onglet Labs de la console Clever Cloud.
L'auteur détaille ensuite la création d'un cluster, possible en ligne de commande ou via un formulaire intuitif, avec des options comme la version Kubernetes, la topologie (Essential, Business, Enterprise) ou le stockage persistant. Les topologies sont expliquées directement dans l'interface, et le déploiement est suivi en temps réel. La tarification et les performances (temps de boot, réseau, sécurité) sont également évoquées, avec des retours sur des bugs rencontrés en phase bêta.
Mise + Krew : gérer ses plugins kubectl de manière déclarative
L’article présente une solution combinant Mise et Krew pour versionner et configurer les plugins kubectl de façon reproductible. Mise, un gestionnaire d’outils en Rust, permet de déclarer les versions des plugins dans un fichier mise.toml, évitant ainsi les problèmes de synchronisation en équipe. Krew, le gestionnaire officiel de plugins kubectl, manque en effet de fonctionnalités de versionnage, ce que Mise comble grâce à son approche déclarative et ses backends multiples (GitHub, Aqua, etc.).
L’auteur explique comment Mise automatise l’activation des versions des outils dès l’entrée dans un répertoire contenant un fichier de configuration, simplifiant la gestion des environnements. Il souligne aussi l’avantage de Mise par rapport à des alternatives comme asdf, notamment pour son intégration avec des outils comme direnv et ses tâches intégrées. La solution proposée permet ainsi de standardiser les environnements Kubernetes en équipe, avec une configuration centralisée et versionnée.
L’article compare les solutions d’admission Kubernetes en 2026, un mécanisme crucial pour valider et modifier les requêtes avant leur persistance dans le cluster. Avec Kubernetes 1.36, les politiques natives (VAP pour la validation et MAP pour la mutation) deviennent viables, réduisant la dépendance aux solutions externes comme Kyverno ou OPA Gatekeeper. Ces dernières évoluent aussi, notamment Kyverno 1.17 qui adopte CEL comme moteur principal, aligné sur les politiques natives, mais conserve des avantages comme la génération de ressources.
Le choix entre ces solutions impacte la sécurité, la fiabilité et la maintenabilité du cluster. L’article évalue chaque option selon des critères concrets : complexité opérationnelle, dépendance externe, expressivité des politiques, capacité de mutation, et outils de test (audit, dry-run). Les politiques natives offrent une intégration directe à l’API server, limitant les risques de fail-open et les latences, tandis que Kyverno ou Gatekeeper proposent des fonctionnalités avancées comme la génération automatique de ressources.
L’objectif est d’aider les équipes à sélectionner la solution la plus adaptée à leurs besoins, en fonction de leur maturité opérationnelle et des exigences de leur environnement.
L’article explique comment configurer un backend HTTPS avec un certificat auto-signé dans Kubernetes en utilisant Gateway API et trust-manager, en remplacement des annotations simplistes d’Ingress-NGINX. L’auteur détaille la migration d’une ressource Ingress vers une HTTPRoute couplée à une BackendTLSPolicy, qui impose une validation stricte du certificat backend, contrairement à NGINX qui permet de désactiver cette vérification. La solution repose sur l’intégration d’une autorité de certification (CA) interne dans un ConfigMap, référencée par la BackendTLSPolicy pour valider le certificat auto-signé.
L’auteur souligne que Gateway API, bien que plus sécurisé et déclaratif, ne propose pas d’option pour ignorer la validation du certificat backend, contrairement à NGINX. La méthode proposée utilise trust-manager pour injecter automatiquement la CA dans le cluster, simplifiant ainsi la gestion des certificats auto-signés. Cette approche garantit une configuration cohérente et sécurisée, alignée sur les bonnes pratiques Kubernetes.
Kloak est un outil innovant conçu pour sécuriser les secrets dans Kubernetes en les injectant directement au niveau du noyau via eBPF, sans que l'application ne les manipule jamais en clair. L'idée centrale est d'intercepter le trafic TLS sortant à l'aide d'uprobes eBPF, remplaçant des placeholders par les vrais secrets juste avant le chiffrement, ce qui empêche leur exposition même en cas de compromission du conteneur. Contrairement aux solutions traditionnelles comme OpenBao ou les sidecars, Kloak évite que les secrets ne résident en mémoire de l'application, réduisant ainsi les risques d'exfiltration.
L'architecture de Kloak repose sur deux plans distincts : un control-plane qui gère les Shadow Secrets et synchronise les eBPF maps, et un data-plane qui intercepte les appels TLS via des hooks sur SSL_write et crypto/tls.(*Conn).Write. Le controller, déployé en tant que DaemonSet, surveille les secrets labellisés et réécrit les montages de pods via un Mutating Admission Webhook, garantissant une intégration transparente sans modification du code applicatif.
L'auteur présente un Proof of Concept (PoC) détaillant les défis rencontrés, notamment avec Flannel et Cilium, ainsi que des méthodes d'analyse via les logs et les compteurs eBPF. Bien que le projet soit récent et open-source, il offre une approche prometteuse pour renforcer la sécurité des secrets dans les environnements Kubernetes, en alignement avec les principes zero-trust.
L’article analyse les UserNamespaces dans Kubernetes, une fonctionnalité présentée comme révolutionnaire mais souvent mal comprise. L’auteur souligne que ces espaces de noms réduisent l’impact d’une évasion de container en mappant l’UID 0 (root dans le container) vers un utilisateur non privilégié sur l’hôte, limitant ainsi les dégâts en cas de compromission. Cependant, il critique les promesses exagérées des infographies, qui présentent cette fonctionnalité comme une solution miracle contre les risques de sécurité, alors qu’elle ne couvre qu’un scénario spécifique (l’escape de container).
L’auteur détaille les cas d’usage concrets des UserNamespaces, comme l’exécution de builds sans privilèges (Buildah, Podman rootless) ou la gestion de legacy systems (Postfix, Dovecot) nécessitant des UID fixes. Il rappelle aussi que cette fonctionnalité ne remplace pas les bonnes pratiques de sécurité, comme le multi-tenancy ou la gestion des vulnérabilités kernel, et que son efficacité dépend d’une configuration rigoureuse. Les UserNamespaces sont utiles, mais leur adoption doit s’inscrire dans une stratégie globale.
Enfin, l’article met en garde contre une confiance excessive dans cette fonctionnalité, soulignant que les risques de sécurité applicative (mauvaise configuration, secrets exposés) ou opérationnelle (mauvaise gestion des ressources) restent critiques. L’auteur conclut que les UserNamespaces sont une avancée, mais qu’ils ne doivent pas occulter les priorités réelles en matière de sécurité Kubernetes.
Ce billet de blog résume le troisième et dernier jour de la conférence DevoxxFR 2026, marqué par la présentation d’une session sur le scheduling dans Kubernetes par l’auteur. L’intervention, axée sur la simplification de concepts comme les requests, limits, QoS et PriorityClasses, a été saluée pour sa clarté, son humour et ses démos techniques réussies, avec une note moyenne de 4,91/5. L’auteur évoque aussi son expérience sur scène, entre stress et satisfaction, ainsi qu’un enregistrement au Studio Devoxx où il a discuté de Kubernetes et de son livre.
La journée a également inclus une conférence sur l’optimisation de la JVM dans Kubernetes, abordant des thèmes comme le warmup, la compilation tiered, l’impact des ressources CPU sur le démarrage des applications Java, et les évolutions récentes de Java pour mieux s’adapter aux conteneurs. L’auteur souligne l’importance des fondamentaux et des démonstrations pratiques pour illustrer ces concepts.
Enfin, le billet reflète l’épuisement post-conférence et la satisfaction d’avoir partagé des connaissances techniques de manière accessible, tout en notant l’engagement positif du public et des retours encourageants.
L’auteur partage son expérience pour obtenir le titre de Kubestronaut, décerné par la CNCF à ceux ayant validé cinq certifications Kubernetes simultanément. Il détaille son parcours, incluant les examens CKA, CKAD et CKS (les plus exigeants), ainsi que les QCMs KCNA et KCSA, soulignant l’importance de ces certifications pour structurer ses compétences, notamment en tant qu’autodidacte.
Il aborde aussi les coûts élevés de ces certifications (environ 400 $ chacune), justifiés par leur format pratique nécessitant une infrastructure dédiée. L’auteur mentionne des réductions possibles lors d’événements comme le Cyber Monday, et remercie son employeur pour son soutien financier et logistique dans cette démarche.
L’article présente talosctl-oidc, un outil conçu pour simplifier l’authentification sur Talos Linux, un système d’exploitation minimaliste pour Kubernetes. L’auteur souligne les limites du système actuel basé sur des certificats mTLS (mutual TLS), qui impose une gestion manuelle fastidieuse des accès, notamment dans un contexte d’équipe. Plutôt que de régénérer manuellement des certificats pour chaque utilisateur, l’outil propose une solution intégrant l’OIDC (OpenID Connect) via un serveur d’échange de certificats, permettant une authentification centralisée via un fournisseur d’identité comme Authentik ou Keycloak.
Le fonctionnement repose sur un serveur intermédiaire qui génère des certificats Talos temporaires à partir des identités validées par l’OIDC. L’article détaille les étapes techniques, de l’installation à la configuration, en passant par la création d’un client OIDC dans l’IdP et la gestion des rôles via RBAC. L’outil automatise également le renouvellement des certificats et simplifie la révocation des accès, évitant ainsi la régénération complète de la CA en cas de départ d’un collaborateur. Cette approche s’inscrit dans une logique de cloud-native, alignée sur les bonnes pratiques modernes d’infrastructure.
Enfin, l’auteur évoque l’absence de solution native pour intégrer l’OIDC directement dans Talos, justifiant ainsi le développement de cet outil open source. Bien que conçu pour des environnements minimalistes ou air-gapped, talosctl-oidc offre une alternative pragmatique aux solutions centralisées comme Omni, tout en restant compatible avec les clusters existants. Le projet illustre une réflexion sur l’automatisation et la sécurité des accès dans les infrastructures Kubernetes.
Tetragon est un outil de sécurité conçu pour surveiller et détecter les comportements malveillants dans les clusters Kubernetes en temps réel. Développé par Isovalent, il s’appuie sur la technologie eBPF pour analyser les événements au niveau du noyau Linux, comme les lancements de processus, les accès aux fichiers ou les connexions réseau, offrant ainsi une visibilité complète sur l’activité des pods. Contrairement à un EDR classique, Tetragon se concentre sur le runtime, permettant une détection précoce des intrusions avant qu’elles ne causent des dommages.
L’article explique que Tetragon fonctionne en traduisant des politiques de traçage (définies en YAML) en programmes eBPF exécutés directement dans le noyau, générant des logs détaillés à chaque événement correspondant. Bien que l’utilisation de Tetragon ne nécessite pas de maîtriser eBPF, une compréhension approfondie du noyau Linux et de cette technologie est essentielle pour en exploiter pleinement les capacités, notamment pour créer des politiques avancées.
Enfin, l’auteur annonce une série d’articles pratiques, commençant par une démonstration d’installation hors Kubernetes, avant d’aborder son déploiement dans des environnements plus complexes. L’objectif est d’aider les utilisateurs à évaluer l’outil, à l’installer et à l’étendre selon leurs besoins, tout en répondant aux questions sur son adéquation avec leurs infrastructures.
L’article explique comment créer des boucles dans les templates Helm en utilisant l’instruction range, qui permet d’itérer sur des listes ou des maps définies dans le fichier values.yaml afin de générer dynamiquement des blocs YAML répétés, évitant ainsi la duplication manuelle et rendant les charts plus flexibles. Il insiste notamment sur la gestion du contexte dans les templates (avec . et $ pour accéder aux données globales) et montre que ces boucles sont essentielles pour produire des configurations adaptables selon les valeurs fournies, par exemple pour créer plusieurs entrées à partir d’une liste de paramètres.
Cet article compare deux méthodes pour étendre l'API Kubernetes : les CRD (Custom Resource Definitions) et les APIService. Les CRD permettent de définir des ressources personnalisées directement gérées par Kubernetes (stockage, validation via OpenAPI), tandis que les APIService délèguent la gestion à un serveur HTTP externe via le kube-aggregator. L'auteur explique que dans 90% des cas, les CRD sont la solution la plus simple et recommandée, illustrant la différence avec un exemple concret de création d'une ressource Cafe. Un bon guide pour choisir la bonne approche selon ses besoins ! ☕️
Fault est un outil de chaos engineering conçu pour tester la résilience des microservices en injectant volontairement des perturbations (latence, erreurs, coupures) dans les communications HTTP afin d’observer leur comportement face aux défaillances et d’identifier leurs faiblesses. Il agit comme un proxy intermédiaire qui rend les échanges volontairement instables, permettant par exemple de reproduire des retards ou des pannes de dépendances et de détecter des problèmes concrets comme des fuites de ressources ou une mauvaise gestion des erreurs, dans l’objectif d’améliorer la tolérance aux pannes et la robustesse globale du système.
L'auteur partage son expérience avec un outil Kubernetes simplifié, kubectl-debug-pvc, développé en deux sessions de 30 minutes grâce à l'IA (Claude Opus). Face à un besoin réel en production (accéder à un volume PVC en ReadWriteOnce sans shell), il contourne les limites de kubectl debug avec une solution automatisée via un plugin Krew. Le projet, plus léger que son prédécesseur PodSweeper, illustre l'efficacité de l'IA pour des tâches ciblées, tout en soulignant l'importance de la supervision humaine. Une démonstration de la puissance des outils GenAI pour le DevOps ! 🚀
L'auteur partage son expérience avec Kyverno, un outil puissant pour Kubernetes, lors d'une mise à jour de cluster vers la version 1.34. L'upgrade a provoqué un deadlock entre les nouvelles fonctionnalités réseau de Kubernetes et Kyverno, rendant l'API Server injoignable. L'incident, initialement perçu comme un problème réseau, était en réalité causé par une collision entre la création automatique d'un objet ServiceCIDR par Kubernetes et l'interception par le webhook Kyverno. L'auteur détaille le mécanisme du deadlock et propose des solutions pour éviter de tels incidents à l'avenir.
Cet article détaille trois retours d’expérience marquants. Sellsy a partagé sa migration réussie de 50 000 bases de données d’un monolithe MariaDB vers une architecture distribuée PostgreSQL/Kubernetes, sans interruption de service, en utilisant CloudNativePG et ZFS pour optimiser les performances et réduire les coûts. Ubisoft a expliqué comment rationaliser l’usage de Kubernetes à grande échelle avec Capsule et une Internal Developer Platform, permettant une gestion multi-tenant efficace et scalable. Enfin, l’INSEE a présenté son approche MLOps pour industrialiser l’entraînement et le déploiement de modèles d’IA, en brisant les silos entre data scientists et développeurs, et en automatisant les pipelines avec Argo Workflows. Une journée riche en enseignements techniques et organisationnels !
Le 3 février 2026, Ippon Technologies a participé aux Cloud Native Days France (ex-Kubernetes Community Days), un événement dédié au Cloud Native, au DevOps et à la souveraineté numérique. La journée a débuté par une keynote sur la souveraineté et l’open source, soulignant l’importance de contribuer activement à ces écosystèmes pour réduire la dépendance aux acteurs américains. Plusieurs interventions ont illustré ces enjeux, comme celle du CERN, qui gère des pétaoctets de données grâce à une infrastructure cloud native optimisée, ou celles de la DINUM et de Scaleway, mettant en avant des solutions souveraines basées sur OpenStack et Kubernetes. Une table ronde a également abordé la formation à Kubernetes et les défis du platform engineering. Enfin, la présentation de Kubo, une distribution Kubernetes open source française, a détaillé son architecture multi-tenant sécurisée, utilisant Capsule et Keycloak pour une gestion fine des droits et une authentification moderne. L’événement a marqué un tournant avec son nouveau nom, symbolisant une plus grande liberté éditoriale et une ouverture accrue.
Le premier jour de la conférence Touraine Tech 2026 a été riche en découvertes et en échanges. L’événement, désormais organisé sur deux jours à l’Université de Sciences de Tours, a débuté par une keynote marquante de Clément Hammel-Cazenave (Agoratlas) sur la guerre informationnelle et les ingérences numériques, illustrée par l’analyse de 500k tweets autour de la crise agricole. L’outil open source D3lta (Viginum) a été présenté pour détecter les contenus dupliqués et lutter contre ces manipulations. Les participants ont aussi pu découvrir des projets techniques variés : la modernisation de trains Jouef avec des Raspberry Pi et TinyGo, un talk sur Kubernetes (avec ses démos improvisées), et une présentation inspirante sur Metal-As-A-Service (MAAS) pour gérer le bare-metal comme des machines virtuelles, avec des économies d’énergie significatives. Enfin, une session sur les agents IA a permis d’explorer les workflows et frameworks pour organiser le chaos des intelligences artificielles. Une journée intense, entre innovation, partage et réflexion collective ! 🚀
L'article explique comment obtenir un ASN (Autonomous System Number) personnel pour annoncer ses plages d'IP sur Internet via le protocole BGP (Border Gateway Protocol). Il commence par définir ce qu'est un ASN et son rôle dans la communication entre réseaux autonomes. L'auteur partage son expérience personnelle, détaillant les étapes pour obtenir un ASN sans se ruiner, comment annoncer ses routes, et comment configurer BGP dans un environnement Kubernetes avec MetalLB. L'article met en lumière l'importance des protocoles de routage dynamique comme BGP pour optimiser les chemins de réseau, surtout dans des infrastructures complexes.