Ein Produktions-Overlay mit secretGenerator-Literalen wie DB_PASSWORD=... legt das Datenbankpasswort für alle mit Zugriff auf das Repository in Git ab, und das daraus erzeugte Secret ist nur base64-kodiert. Eine Remote-Basis, die als https://github.com/org/platform//base ohne ?ref= angegeben ist, deployt das, was am Tag des Builds im Standard-Branch liegt. Und ein Overlay, das nie einen Namespace setzt, schickt Produktionsobjekte in den Namespace, den der aktuelle kubectl-Kontext gerade verwendet. Dieser Skill findet diese und die weiteren unten aufgeführten Kustomize-Fehler und zeigt Ihnen, wie Sie jeden davon beheben.

Ihr Agent führt einen Scanner über jede Datei kustomization.yaml, kustomization.yml und Kustomization aus (Kustomizations und Components). Er folgt lokalen Basen wie ../../base, um festzustellen, ob eine davon einen Namespace setzt, und öffnet die env-Dateien und Dateien, die secretGenerator liest, um zu prüfen, ob sie echte Werte enthalten und ob .gitignore sie aus Git heraushält. Er kennt die aktuellen Felder und Deprecations von Kustomize v5, die Formen von Remote-URLs und weiß, dass ein ref ein Branch, ein Tag oder ein vollständiger Commit-Hash sein kann. Mit SOPS verschlüsselte env-Dateien, ${VAR}-Platzhalter und Flux-Kustomization-Objekte werden nicht gemeldet. Er führt nie kustomize, kubectl, helm oder git aus. Er liefert BLOCK, REVIEW oder NOT FLAGGED mit Datei, Zeile, Begründung und einem sichereren Ansatz. Secrets werden nie ausgegeben.

Was geprüft wird

BLOCK (vor dem Ausliefern beheben)

• K01: Secrets, die in der Kustomization stehen: secretGenerator-Literale, configMapGenerator-Literale mit Secret-Namen, Secret-Werte und Secret-Umgebungsvariablen in valuesInline von helmCharts, Secret-data oder Secret-env-Werte in Inline-Patches, ein Passwort in einer Remote-URL oder ein Token von GitHub, GitLab, Slack, npm oder AWS irgendwo in der Datei (Schlüssel, die nur ein Secret benennen, etwa tlsSecret: proxy-tls, bleiben unberührt)
• K02: env-Dateien und Schlüsseldateien von secretGenerator (oder env-Dateien von configMapGenerator mit Secret-Namen), die mit echten Werten und ohne .gitignore-Regel im Repository liegen
• K03: Remote-Git-Basen, Resources oder Components ohne ref oder Version
• K04: Remote-Resources, Basen oder Helm-Chart-Repositories über unverschlüsseltes http://

REVIEW (vor dem Release prüfen)

• K11: bewegliche Remote-Refs: ein Branch (main, stable, release-1.28), ein kurzer Commit-Hash, eine Raw-Datei-URL auf einem Branch, ein releases/latest-Download oder eine Datei-URL ohne Version
• K12: helmCharts ohne Version, mit latest oder mit einem Versionsbereich
• K13: Images mit newTag latest, main, nightly oder einem anderen beweglichen Tag und ohne Digest
• K14: veraltete Felder (bases, patchesStrategicMerge, patchesJson6902, vars, imageTags, helmChartInflationGenerator) sowie env eines Generators, die ältere Singularform von envs, die kustomize edit fix in envs zusammenführt
• K15: commonLabels, das auch Selektoren umschreibt, die sich bei laufenden Workloads nicht ändern lassen
• K16: disableNameSuffixHash: true, sodass eine geänderte Konfiguration die Pods nicht neu ausrollt
• K17: Overlays, die weder namespace noch namePrefix oder nameSuffix setzen, auf einer lokalen Basis, die ebenfalls keinen Namespace setzt (Basen nur aus clusterweiten Kinds wie ClusterIssuer oder ClusterRole bleiben unberührt)
• K18: Dateien, die von außerhalb des Kustomization-Ordners geladen werden und die der standardmäßige Load Restrictor ablehnt

Was enthalten ist

• Der Scanner (Python 3.9+, nur Standardbibliothek)
• Ein Regelleitfaden mit Begründung, sichererem Ansatz und offizieller Quelle für jede Regel
• Ein riskantes und ein sicheres Beispiel-Repository (eine Basis, ein Produktions-Overlay und eine Plattform-Kustomization) sowie der echte Bericht, den der Scanner für das riskante Beispiel erzeugt

Grenzen

Er liest die Kustomization-Dateien so, wie sie geschrieben sind, und führt den Build nicht aus, daher werden das Ergebnis von Patches, Components, Replacements und Helm-Templates sowie die Kubernetes-Manifeste selbst nicht geprüft. Remote-Basen und Charts werden nicht abgerufen. Ob eine Datei committet ist, wird nur anhand der .gitignore-Dateien entschieden. Tags und Branches werden anhand ihrer Namen unterschieden. Ein Namespace, der durch eine Argo-CD-Application oder eine Flux-Kustomization gesetzt wird, ist nicht bekannt. NOT FLAGGED ist keine Garantie.

Inhalt

Eine ZIP-Datei mit 27 Dateien: SKILL.md, der Scanner in scripts/ (8 Python-Dateien), references/rules.md (jede Regel mit Begründung und sichererem Ansatz) und examples/ (16 Beispieldateien plus report.md, die echte Scanner-Ausgabe für das riskante Beispiel).

Verwendung: Dies ist ein Agent-Skill: ein Ordner mit einer SKILL.md-Datei und Python-Skripten, die ein KI-Coding-Agent wie Claude Code, Cursor oder Codex CLI ausführen kann. Entpacken Sie ihn in den Skills-Ordner Ihres Agenten (für Claude Code: ~/.claude/skills/) und bitten Sie dann Ihren Agenten, Ihr Projekt zu prüfen. Die Skripte laufen auch eigenständig mit Python 3.9 oder neuer, ohne dass etwas installiert werden muss. Sie lesen nur Ihre Dateien: kein Netzwerkzugriff, und nichts wird irgendwohin gesendet.