Linter de manifests Kubernetes

Les manifests Kubernetes sont généralement relus visuellement dans une pull request, ce qui explique que les mêmes erreurs de durcissement se retrouvent régulièrement en production : un Deployment sans limite mémoire qui finit par être tué par OOM et emporte un nœud avec lui, un conteneur qui s'exécute allègrement en root parce que personne n'a défini runAsNonRoot, ou un Pod épinglé à un tag d'image comme `:latest` qui change silencieusement en cours de déploiement. Ce linter détecte ce type de problème dès que vous collez un manifest, sans avoir besoin d'un cluster en cours d'exécution, d'un contexte kubectl ni d'aucune information d'identification.

Sous le capot, il intègre un petit analyseur YAML maison, conçu spécifiquement pour le sous-ensemble réaliste de YAML qu'utilisent réellement les manifests Kubernetes : documents séparés par `---`, imbrication par indentation, couples `clé: valeur` et blocs de correspondances imbriqués, éléments de séquence `- ` incluant des listes de correspondances, scalaires entre guillemets et sans guillemets, commentaires, et scalaires blocs `|`/`>` pour les valeurs ConfigMap multi-lignes ou les annotations. Aucune bibliothèque YAML externe n'est utilisée — l'analyseur et le moteur de règles sont tous deux intégrés à l'outil et s'exécutent entièrement dans votre navigateur.

La table de règles s'inspire des guides de durcissement de cluster bien connus — le CIS Kubernetes Benchmark, kube-score et le profil « Restricted » des Pod Security Standards — et vérifie pour chaque conteneur l'absence de requêtes/limites de ressources, les conteneurs pouvant s'exécuter en root ou en mode privilégié, l'absence de sondes de vivacité et de disponibilité sur les charges de travail à longue durée (Deployments, StatefulSets, DaemonSets), les montages de volumes hostPath qui exposent le système de fichiers de l'hôte, l'utilisation de hostNetwork, et les images de conteneur non reproductibles avec le tag `:latest` ou sans tag. Les résultats sont regroupés par document et par conteneur, avec une sévérité claire erreur/avertissement pour chacun, afin de distinguer ce qui est réellement risqué de ce qui n'est qu'un rappel de bonne pratique.

Il fonctionne sur des manifests uniques ou des fichiers multi-documents entiers, collés directement depuis le rendu d'un template Helm ou la sortie d'un `kustomize build`, en prenant en charge les ressources Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet et CronJob. Comme tout s'exécute en local, vous pouvez coller en toute sécurité des manifests contenant des noms de service internes, des tailles de ressources réelles ou toute autre information que vous ne voudriez pas envoyer à une API tierce — pratique pour une vérification rapide de cohérence en pré-commit, une aide à la revue de code, ou simplement pour apprendre ce à quoi ressemble vraiment un manifest « durci » en pratique.