L’article explique comment sécuriser les secrets Kubernetes en utilisant OVHcloud Secret Manager (un service managé compatible HashiCorp Vault KV v2) couplé à External Secrets Operator (ESO), une solution automatisée pour synchroniser les secrets entre le gestionnaire externe et le cluster. L’auteur souligne les avantages de cette approche, notamment la simplicité de déploiement et la réduction des coûts (environ 0,03 € par secret/mois), tout en évitant les pratiques risquées comme le stockage direct dans Git ou les Secrets Kubernetes non protégés.

Le tutoriel détaille les étapes techniques : installation de la CLI OVHcloud, configuration d’un compte de service IAM avec des droits minimaux, puis déploiement d’ESO via Helm. L’opérateur permet de synchroniser automatiquement les secrets depuis OVHcloud Secret Manager vers Kubernetes, avec un chiffrement au repos et une gestion centralisée des accès via des tokens IAM. L’auteur compare cette solution à des alternatives comme OpenBao, jugées plus complexes à maintenir pour des clusters légers.

Enfin, l’article aborde la question budgétaire, précisant que le coût reste très faible pour un usage modéré, et propose une méthode pour regrouper plusieurs valeurs sous un même secret afin d’optimiser la facturation. La démarche est présentée comme une alternative efficace aux solutions auto-hébergées, idéale pour les environnements éphémères ou les équipes cherchant à simplifier leur gestion des secrets.

Ce wiki personnel partage des astuces et tutoriels techniques axés principalement sur l’environnement GNU/Linux, couvrant des sujets variés comme la bureautique, l’administration système et le développement. L’auteur y propose des solutions concrètes, comme l’utilisation de Conky pour surveiller les ressources système ou des outils comme Redshift pour réduire la fatigue visuelle. Les sections dédiées aux clusters Kubernetes et aux conseils pratiques en informatique illustrent son expertise, notamment acquise via son activité de bénévole sur un forum.

Les contenus sont organisés par grandes thématiques, avec des guides détaillés comme le déploiement de clusters avec Talos Linux ou la récupération de données après une panne. L’auteur insiste sur le caractère expérimental de ses méthodes, invitant à une utilisation prudente et responsable des tutoriels fournis. Le ton reste pragmatique, reflétant une approche basée sur l’expérience terrain.

Le site sert aussi de vitrine pour ses réflexions personnelles, avec une section dédiée à ses pages personnelles, tout en restant un espace collaboratif ouvert aux contributions externes. L’accent est mis sur la simplicité et l’efficacité, avec des outils comme VLC ou des scripts pour automatiser des tâches sous Linux.

L’article explore l’intégration de Karpenter avec Cluster API (CAPI) pour automatiser l’autoscaling des nœuds Kubernetes, notamment sur OVH. L’auteur compare deux solutions : Cluster Autoscaler, qui gère des groupes de machines prédéfinis, et Karpenter, qui provisionne dynamiquement des nœuds en fonction des besoins des pods, sans nécessiter de configuration manuelle de groupes. Karpenter, initialement conçu pour AWS, est désormais agnostique grâce à sa donation à la CNCF, avec des providers tiers comme karpenter-provider-cluster-api pour CAPI, permettant une intégration avec des clouds comme OVH.

L’auteur détaille le fonctionnement de Karpenter, notamment ses ressources clés comme les NodePools, qui définissent les règles de provisionnement, et son approche par pods en attente (Pending). Contrairement à son mode natif (standalone), l’utilisation avec CAPI impose un cluster de management supplémentaire, ce qui complexifie légèrement l’architecture. Le texte souligne aussi les différences philosophiques entre les deux outils : Karpenter optimise les coûts en choisissant des instances adaptées (y compris Spot), tandis que Cluster Autoscaler se base sur des groupes de nœuds préconfigurés.

Enfin, l’article présente un retour d’expérience pratique avec des tests de scale-up et scale-down, mettant en lumière les défis rencontrés, comme la gestion des taints ou les limites du scale-to-zero. L’auteur conclut en comparant Karpenter et Cluster Autoscaler, soulignant les avantages de Karpenter pour les charges irrégulières, tout en notant les contraintes liées à son intégration avec CAPI.

L’article explique comment configurer Mimir, le backend de stockage long terme pour les métriques Prometheus développé par Grafana, afin d’améliorer l’observabilité dans un environnement Kubernetes. Il détaille d’abord l’installation locale de Mimir sur le même serveur que Grafana et Prometheus, avec une authentification basic auth et un certificat TLS pour sécuriser l’accès au port 9009. La configuration repose sur un fichier YAML simplifié, où les données sont stockées localement et les composants (ingester, querier, etc.) sont définis pour une instance unique.

Ensuite, l’auteur décrit le déploiement de Grafana Alloy sur Kubernetes pour collecter les métriques et les logs, en s’appuyant sur une infrastructure existante. Un namespace monitoring est créé, ainsi qu’un secret pour l’authentification, tandis qu’un fichier Helm (alloy-values.yml) configure Alloy en tant que daemonset avec des volumes spécifiques pour accéder aux métriques système des nœuds Kubernetes. La configuration inclut aussi le relabeling des cibles Prometheus pour identifier correctement les instances.

Enfin, l’article souligne l’intégration entre Alloy et Mimir, où Alloy scrappe les métriques des nœuds et les envoie vers Mimir via remote_write, permettant ainsi une observabilité centralisée. La solution est présentée comme une alternative pour remplacer ou compléter des outils comme Prometheus en stockage long terme, tout en garantissant une configuration sécurisée et adaptée à Kubernetes.

Cet article explique la mise en place d’un stockage persistant sur un cluster Kubernetes on-premise en utilisant Longhorn. L’auteur détaille les prérequis nécessaires, comme un cluster kubeadm sous Debian 13 avec trois nœuds équipés chacun d’un disque dédié de 100 Go, ainsi que la stack Traefik, cert-manager et MetalLB pour l’ingress. La préparation des nœuds inclut l’installation de paquets comme open-iscsi et nfs-common, et la configuration du disque dédié via mkfs.ext4 et fstab.

L’installation de Longhorn s’effectue via Helm, avec une configuration par défaut pointant vers le chemin /var/lib/longhorn-disk et une réplication des données sur trois nœuds. L’auteur vérifie ensuite le bon fonctionnement des pods et la création automatique d’une classe de stockage Longhorn. Un test de stockage persistant est réalisé avec un PersistentVolumeClaim, confirmant l’apparition du volume dans l’interface utilisateur de Longhorn avec trois réplicas.

Enfin, l’article couvre l’exposition sécurisée de l’interface utilisateur de Longhorn via HTTPS avec une authentification basique et un certificat Let’s Encrypt. La configuration inclut la création d’un secret pour l’authentification, un Middleware Traefik pour l’authentification basique, et un certificat TLS. La mise à jour de la Gateway Traefik permet d’accéder à l’interface Longhorn de manière sécurisée.

L’auteur partage son expérience pour déployer un cluster Kubernetes managé (MKS) avec Cilium sur OVH Cloud, en comparant les approches CLI et interface web. Il explique que la version gratuite utilise Calico par défaut, tandis que Cilium n’est disponible qu’avec le plan standard payant, nécessitant aussi une gateway. L’interface graphique simplifie la création du réseau privé et du cluster, contrairement à la CLI qui s’avère complexe pour cette configuration.

Le tutoriel détaille ensuite les étapes techniques : configuration de l’authentification via la CLI OVH, récupération du Kubeconfig, et création d’un cluster avec un nodepool de deux nœuds. L’auteur souligne l’importance de bien préparer l’environnement (région compatible, réseau privé, gateway) avant de procéder à l’installation, et recommande des outils comme Terraform pour des déploiements plus sérieux.

Enfin, il explore les fonctionnalités de Cilium, comme l’observation du réseau, la gestion des Pods et des CRD, ainsi que la configuration avancée via CiliumNodeConfig, incluant l’activation de WireGuard pour le chiffrement. L’article sert de guide pratique pour intégrer Cilium dans un cluster OVH, avec des conseils concrets pour surmonter les défis techniques.

Kubernetes est un outil open source d’orchestration de conteneurs, développé initialement par Google, conçu pour gérer des applications conteneurisées de manière scalable et résiliente. Il s’impose comme une solution clé dans l’industrie, notamment avec l’adoption des microservices et la multiplication des conteneurs. Parmi ses fonctionnalités principales figurent la haute disponibilité, la scalabilité, la reprise après sinistre et la gestion des configurations via des composants comme ConfigMap et Secret.

L’architecture de Kubernetes repose sur des pods, unités de base regroupant un ou plusieurs conteneurs, et des services qui assurent une adresse IP permanente pour les applications, indépendamment du cycle de vie des pods. Les déploiements permettent de maintenir plusieurs instances d’une application pour éviter les temps d’arrêt, tandis que les StatefulSets gèrent les bases de données de manière ordonnée. Les volumes offrent une solution pour la persistance des données, car Kubernetes ne gère pas nativement leur stockage.

Au niveau des nœuds, trois processus essentiels fonctionnent : le Kubelet, qui supervise les conteneurs sur un nœud en suivant les instructions du plan de contrôle, le Kube-proxy, qui gère les règles réseau pour les services, et un moteur d’exécution de conteneurs (comme Docker ou containerd). Ces éléments collaborent pour assurer une orchestration efficace des applications dans un cluster.

L’article explique comment sécuriser une application via Envoy Gateway en utilisant OIDC (OpenID Connect) et JWT pour l’authentification, ainsi que l’autorisation par groupes. L’auteur montre comment configurer une SecurityPolicy dans un cluster Kubernetes pour appliquer une authentification centralisée avec Keycloak, sans avoir besoin d’un outil supplémentaire comme oauth2-proxy.

La configuration repose sur une HTTPRoute pour router le trafic vers l’application, avec une règle dédiée pour le callback OIDC. La SecurityPolicy est ensuite attachée à cette route, définissant l’URL du fournisseur OIDC, les identifiants du client et les chemins de callback et de déconnexion. L’autorisation par groupe est évoquée, mais son implémentation détaillée n’est pas abordée dans cet article.

L’exemple utilise un cluster Kubernetes sur Clever Cloud avec un add-on Keycloak, mais la configuration de Keycloak et l’exposition via Gateway API sont supposées déjà en place. L’approche simplifie la gestion de l’authentification en intégrant directement ces fonctionnalités dans Envoy Gateway.

Ce billet de blog, deuxième partie d’un test sur CKE (Clever Cloud Kubernetes Engine), explore les fonctionnalités avancées de stockage sur ce service managé. L’auteur détaille notamment l’activation du Container Storage Interface (CSI) via une commande simple, permettant l’utilisation de Ceph RBD pour des volumes persistants, avec une StorageClass configurée par défaut et la possibilité d’étendre les volumes à chaud. Il illustre ensuite le déploiement d’un PersistentVolumeClaim (PVC) et son utilisation dans un pod, confirmant la persistance des données après redémarrage.

L’article aborde également des cas d’usage concrets comme le déploiement de vCluster, un cluster Kubernetes virtuel fonctionnant dans le cluster hôte, partageant son infrastructure de stockage. L’auteur teste cette solution, soulignant ses avantages potentiels pour l’isolation des environnements (comme des environnements CI) tout en partageant les ressources, bien qu’il reste sceptique sur certains aspects de sécurité.

Enfin, le billet conclut sur les fonctionnalités de gestion du cycle de vie des volumes, incluant les snapshots et la restauration de données, avec une procédure technique détaillée en plusieurs étapes. L’auteur résume son expérience en mettant en avant la simplicité de mise en œuvre et la flexibilité offerte par CKE pour des besoins de stockage avancés dans Kubernetes.

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.