Un overlay de production avec des littéraux secretGenerator comme DB_PASSWORD=... place le mot de passe de la base de données dans git pour tous ceux qui ont accès au dépôt, et le Secret qu'il génère n'est encodé qu'en base64. Une base distante écrite sous la forme https://github.com/org/platform//base sans ?ref= déploie ce que contient la branche par défaut le jour du build. Et un overlay qui ne définit jamais de namespace envoie les objets de production dans le namespace qu'utilise le contexte kubectl courant. Ce skill détecte ces erreurs et les autres erreurs Kustomize ci-dessous, et vous indique comment corriger chacune d'elles.

Votre agent exécute un scanner sur chaque fichier kustomization.yaml, kustomization.yml et Kustomization (kustomizations et components). Il suit les bases locales comme ../../base pour voir si l'une d'elles définit un namespace, et ouvre les fichiers env et les fichiers lus par secretGenerator pour vérifier s'ils contiennent de vraies valeurs et si .gitignore les tient hors de git. Il connaît les champs et dépréciations actuels de Kustomize v5, les formes d'URL distantes, et sait qu'un ref peut être une branche, un tag ou un hash de commit complet. Les fichiers env chiffrés avec SOPS, les placeholders ${VAR} et les objets Kustomization de Flux ne sont pas signalés. Il n'exécute jamais kustomize, kubectl, helm ni git. Il renvoie BLOCK, REVIEW ou NOT FLAGGED, avec le fichier, la ligne, la raison et une approche plus sûre. Les secrets ne sont jamais affichés.

Ce qui est vérifié

BLOCK (à corriger avant la mise en production)

• K01 : secrets écrits dans la kustomization : littéraux secretGenerator, littéraux configMapGenerator avec des noms de secrets, valeurs secrètes et variables d'environnement secrètes dans valuesInline de helmCharts, data de Secret ou valeurs env secrètes dans des patchs inline, un mot de passe dans une URL distante, ou un token GitHub, GitLab, Slack, npm ou AWS n'importe où dans le fichier (les clés qui ne font que nommer un Secret, comme tlsSecret: proxy-tls, sont ignorées)
• K02 : fichiers env et fichiers de clés de secretGenerator (ou fichiers env de configMapGenerator avec des noms de secrets) conservés dans le dépôt avec de vraies valeurs et sans règle .gitignore
• K03 : bases git distantes, resources ou components sans ref ni version
• K04 : resources distantes, bases ou dépôts de charts Helm en http:// non chiffré

REVIEW (à vérifier avant la publication)

• K11 : refs distantes mouvantes : une branche (main, stable, release-1.28), un hash de commit court, une URL de fichier raw sur une branche, un téléchargement releases/latest ou une URL de fichier sans version
• K12 : helmCharts sans version, en latest ou avec une plage de versions
• K13 : images avec newTag latest, main, nightly ou un autre tag mouvant et sans digest
• K14 : champs obsolètes (bases, patchesStrategicMerge, patchesJson6902, vars, imageTags, helmChartInflationGenerator), ainsi que env d'un générateur, l'ancienne forme au singulier de envs que kustomize edit fix fusionne dans envs
• K15 : commonLabels, qui réécrit aussi des sélecteurs qui ne peuvent pas changer sur des workloads en cours d'exécution
• K16 : disableNameSuffixHash: true, si bien qu'une configuration modifiée ne redéploie pas les pods
• K17 : overlays qui ne définissent ni namespace, ni namePrefix, ni nameSuffix, sur une base locale qui ne définit pas non plus de namespace (les bases composées uniquement de types à portée cluster comme ClusterIssuer ou ClusterRole sont ignorées)
• K18 : fichiers chargés depuis l'extérieur du dossier de la kustomization, que le load restrictor par défaut refuse

Ce qui est inclus

• Le scanner (Python 3.9+, bibliothèque standard uniquement)
• Un guide des règles avec la raison, l'approche plus sûre et la source officielle de chaque règle
• Un dépôt d'exemple risqué et un dépôt sûr (une base, un overlay de production et une kustomization de plateforme), ainsi que le rapport réel produit par le scanner sur l'exemple risqué

Limites

Il lit les fichiers kustomization tels qu'ils sont écrits et n'exécute pas le build : ce que produisent les patchs, components, replacements et templates Helm, ainsi que les manifestes Kubernetes eux-mêmes, n'est donc pas vérifié. Les bases et charts distants ne sont pas téléchargés. Le fait qu'un fichier soit commité est déterminé uniquement à partir des fichiers .gitignore. Les tags et les branches sont distingués par leur nom. Un namespace défini par une Application Argo CD ou une Kustomization Flux n'est pas connu. NOT FLAGGED n'est pas une garantie.

Contenu

Un fichier ZIP contenant 27 fichiers : SKILL.md, le scanner dans scripts/ (8 fichiers Python), references/rules.md (chaque règle avec sa raison et son approche plus sûre) et examples/ (16 fichiers d'exemple plus report.md, la sortie réelle du scanner sur l'exemple risqué).

Utilisation : Il s'agit d'un skill pour agent : un dossier contenant un fichier SKILL.md et des scripts Python qu'un agent de programmation IA comme Claude Code, Cursor ou Codex CLI peut exécuter. Décompressez-le dans le dossier des skills de votre agent (pour Claude Code : ~/.claude/skills/), puis demandez à votre agent de vérifier votre projet. Les scripts fonctionnent aussi de manière autonome avec Python 3.9 ou plus récent, sans rien à installer. Ils se contentent de lire vos fichiers : aucun accès réseau, et rien n'est envoyé nulle part.