Kubernetes : Sécurité et configuration en tant que données

Temps de lecture : 10 min

Pourquoi la configuration en tant que code ne passe pas l’épreuve de la gestion fleet-wise

Je suis souvent confronté à des équipes qui se demandent : dans mes nombreux clusters, quels namespaces n’ont pas de NetworkPolicy restrictive par défaut ? Est-ce que la posture de sécurité d’une appli est cohérente entre dev, staging et prod ? Qui a accès en lecture aux Secrets sur tout le fleet ?

Concrètement, si ta configuration vit dans des chartes Helm, des overlays Kustomize, du CDK8s TypeScript ou du Jsonnet, tu ne peux pas exécuter ces requêtes directement contre tes fichiers sources. Ces formats sont du code, des programmes qui génèrent des manifests à la volée pendant le déploiement. Il n’existe pas de store centralisé contenant « tous mes namespaces, sur tous mes clusters ». La parade classique consiste à lire les clusters en direct avec kubectl, mais le vrai problème arrive quand il faut corriger.

Si tu modifies directement le cluster, tu dérives de ta source. Si tu retournes modifier la charte, tu dois d’abord faire le chemin inverse : trouver le fichier de template correspondant, comprendre comment y injecter le changement dans le bon format, et lancer la procédure git push. Et si tu n’es pas le propriétaire de la charte, c’est encore plus complexe. Le lieu où tu découvres le problème (un cluster live) et le lieu où tu le résous (un programme) sont deux systèmes différents. Pour l’instant, seuls un humain ou un agent IA peut faire la conversion, avec tous les risques d’hallucination.

ConfigHub : la configuration en tant que données

L’approche de ConfigHub est simple : on stocke chaque ressource Kubernetes sous forme de YAML complet (valeurs littérales, pas de templates). Plus précisément, on obtient ainsi un système de référence uniforme où chaque champ de chaque ressource dans chaque namespace est requêtable et modifiable via des fonctions servieuses, avec traçabilité complète.

Ce n’est pas un simple scraper qui duplique l’état live. C’est la véritable source de vérité : le jeu de données qu’on lit est le même qu’on modifie, et il s’applique à l’ensemble du fleet. Et ça change tout parce que tu peux construire des outils qui lisent et écrivent en même temps.

Trois outils CLI pour une sécurité fleet-wide

Pour démontrer la puissance de cette approche, j’ai développé trois outils open-source (env. une demi-journée chacun) : cub-namespace, cub-netpol et cub-rbac. L’idée n’est pas de réinventer la roue, mais de montrer qu’à partir d’un modèle unifié, on peut bâtir des outils prêts à l’emploi.

1. Diagnostiquer tout le fleet en une commande

D’abord, l’inventaire. Avec ConfigHub, on peut répondre à la question : quels namespaces n’ont pas leur enveloppe de sécurité (NetworkPolicy + labels standards) ? C’est une propriété join sur plusieurs types de ressources, qu’aucun admission controller per-objet ne peut voir. Puis, la question de cohérence : chaque appli a-t-elle son namespace identique sur tous ses environnements ? En configuration as code, c’est un vrai casse-tête car chaque environnement a un fichier values différent.

Avec une seule requête, je vérifie sept composants sur toutes leurs variantes. Si l’un d’eux dérive, l’outil le signale et pointe l’endroit exact. Ensuite, la question sécurité de base : qui peut lire les Secrets partout ? J’obtiens en une ligne la liste des cinq accès à travers tout le fleet, y compris un groupe break-glass avec cluster-admin.

L’outil cub-netpol répond au pendant réseau : qui peut joindre telle charge de travail ? C’est un calcul effectif de l’accessibilité, en combinant toutes les règles NetworkPolicy du namespace. Pas besoin de simuler des sélecteurs à la main. Et le résultat donne exactement les workloads autorisés, là où tout auditeur attend.

2. Trouver une faille → corriger en données → sur tout le fleet

Le diagnostic ne vaut que si on peut corriger. Imaginons qu’on supprime volontairement une NetworkPolicy restrictive sur l’application appvote dans ses deux clusters. L’outil cub-netpol le détecte immédiatement, avec les workloads exposés nommés. Ensuite, une seule commande génère la politique manquante pour tous les namespaces non couverts du fleet, en dry-run d’abord. Le résultat est un nouveau fichier de configuration versionné, prêt à être appliqué après validation. Pas de kubectl edit qui dérive, pas de commit/push fastidieux.

Le même pattern s’applique aux enveloppes de namespaces (cub-namespace apply-envelope) et au RBAC (cub-rbac fleet-edit). On peut même basculer ces vérifications en mode bloquant via des validation triggers, si une régression survient.

Pourquoi le code de configuration ne peut pas faire ça

Concrètement, les outils de configuration en tant que code (Helm, Kustomize, CDK8s) génèrent des manifests à la volée, dispersés dans une myriade de dépôts git. Pour évaluer des problèmes de sécurité, on scrape les clusters live. Pour corriger, on édite le cluster (dérive) ou on remonte manuellement dans le template. Il n’y a pas de modèle de données uniforme pour construire des outils fleet-wide.

À l’inverse, la configuration en tant que données de ConfigHub offre du YAML complet, versionné, en base de données. L’évaluation et la correction se font via des requêtes sur la même donnée. L’équipe platforme peut construire des outils sur mesure pour chaque besoin, et ce, en un après-midi.

J’utilise cette approche depuis des années sur des projets comme GymLog (mon app Android fitness) et des workflows d’automatisation n8n. La capacité à requêter et modifier toute la config en un coup change radicalement la gestion de la sécurité.

Si tu galères avec la dérive des outils de sécurité existants, ou si tu passes du temps à forker et améliorer des chartes Helm manuellement, je suis curieux de savoir comment tu gères ça. Tu préfères Kustomize ou les umbrella charts ? Tu utilises Cloud Query pour scraper tes clusters ? Laisse un commentaire ou contacte-moi sur LinkedIn ou Bluesky.

ConfigHub est actuellement en preview. Si ce sujet t’intéresse, tu trouveras d’autres articles de ma série Kubernetes.