Linter du manifeste Kubernetes

Les manifestes Kubernetes sont généralement examinés à l'oeil nu dans une pull request, ce qui signifie que la même poignée d'erreurs de durcissement continuent d'arriver en production : un déploiement sans limite de mémoire qui finit par être tué par le MOO et emporte un nœud avec lui, un conteneur qui s'exécute avec plaisir en tant que root parce que personne n'a défini runAsNonRoot, ou un pod épinglé à une balise d'image comme `:latest` qui change silencieusement sous un déploiement. Ce linter détecte cette classe de problèmes au moment où vous collez un manifeste, sans avoir besoin d'un cluster en cours d'exécution, d'un contexte kubectl ou d'informations d'identification.

Sous le capot, il comprend un petit analyseur YAML roulé à la main écrit spécifiquement pour le sous-ensemble réaliste de YAML que Kubernetes manifeste utilise réellement : `---`-documents séparés, imbrication basée sur l'indentation, `key: value` et mappages de blocs imbriqués, `- ` éléments de séquence comprenant des listes de cartes, des scalaires entre guillemets et non cités, des commentaires et des scalaires de bloc `|`/`>` pour des choses comme les lignes multiples. Valeurs ou annotations ConfigMap. Aucune bibliothèque YAML externe n'est impliquée : l'analyseur et le moteur de règles sont tous deux fournis avec l'outil et s'exécutent entièrement dans votre navigateur.

La table de règles est calquée sur des conseils bien connus en matière de renforcement des clusters - le CIS Kubernetes Benchmark, kube-score et le profil "Restricted" des normes de sécurité des pods - et vérifie chaque conteneur pour les demandes/limites de ressources manquantes, les conteneurs qui peuvent s'exécuter en tant que root ou en mode privilégié, les sondes d'activité et de préparation manquantes sur les charges de travail de longue durée (déploiements, StatefulSets, DaemonSets), les montages de volume hostPath qui exposent le système de fichiers hôte, Utilisation de hostNetwork et images de conteneur `:latest` non reproductibles ou non balisées. Les résultats sont regroupés par document et par conteneur, avec une gravité d'erreur/avertissement claire pour chacun afin que vous puissiez distinguer ce qui est réellement risqué de ce qui n'est qu'un simple coup de pouce en matière de bonnes pratiques.

Il fonctionne sur des manifestes uniques ou des fichiers multidocuments entiers collés directement à partir d'un rendu de modèle Helm ou d'une sortie « kustomize build », comprenant les ressources Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet et CronJob. Étant donné que tout s'exécute localement, il est possible de coller en toute sécurité des manifestes contenant des noms de services internes, le dimensionnement réel des ressources ou tout autre élément que vous ne voudriez pas envoyer à une API tierce - utile pour une vérification rapide de l'intégrité avant la validation, une aide à la révision du code ou simplement pour apprendre à quoi ressemble réellement le "renforcé" dans la pratique.