Продакшн-оверлей із літералами secretGenerator на кшталт DB_PASSWORD=... кладе пароль бази даних у git для всіх, хто має репозиторій, а Secret, який він створює, закодований лише в base64. Віддалена база, записана як https://github.com/org/platform//base без ?ref=, розгортає те, що лежить у гілці за замовчуванням у день збирання. А оверлей, який ніде не задає namespace, надсилає продакшн-об'єкти в той namespace, який використовує поточний контекст kubectl. Цей навик знаходить такі помилки та інші помилки Kustomize, наведені нижче, і пояснює, як виправити кожну з них.

Ваш агент запускає сканер на кожному файлі kustomization.yaml, kustomization.yml і Kustomization (kustomization і components). Він проходить локальними базами на кшталт ../../base, щоб з'ясувати, чи задає якась із них namespace, і відкриває env-файли та файли, які читає secretGenerator, щоб перевірити, чи містять вони реальні значення і чи виключає їх .gitignore з git. Він знає актуальні поля та застарілі елементи Kustomize v5, форми віддалених URL і те, що ref може бути гілкою, тегом або повним хешем коміту. Env-файли, зашифровані SOPS, плейсхолдери ${VAR} і об'єкти Flux Kustomization не позначаються. Він ніколи не запускає kustomize, kubectl, helm чи git. Результат: BLOCK, REVIEW або NOT FLAGGED із зазначенням файлу, рядка, причини та безпечнішого підходу. Секрети ніколи не виводяться.

Що перевіряється

BLOCK (виправити до випуску)

• K01: секрети, записані в kustomization: літерали secretGenerator, літерали configMapGenerator із секретними іменами, секретні значення та секретні змінні середовища у valuesInline у helmCharts, data Secret або секретні значення env в inline-патчах, пароль у віддаленому URL, а також токен GitHub, GitLab, Slack, npm чи AWS будь-де у файлі (ключі, які лише називають Secret, наприклад tlsSecret: proxy-tls, не зачіпаються)
• K02: env-файли та файли ключів secretGenerator (або env-файли configMapGenerator із секретними іменами), що зберігаються в репозиторії з реальними значеннями і без правила в .gitignore
• K03: віддалені git-бази, resources або components без ref чи версії
• K04: віддалені resources, бази або репозиторії Helm-чартів через звичайний http://

REVIEW (перевірити перед релізом)

• K11: рухомі віддалені посилання: гілка (main, stable, release-1.28), короткий хеш коміту, URL raw-файлу в гілці, завантаження releases/latest або URL файлу без версії
• K12: helmCharts без версії, з latest або з діапазоном версій
• K13: образи з newTag latest, main, nightly чи іншим рухомим тегом і без дайджесту
• K14: застарілі поля (bases, patchesStrategicMerge, patchesJson6902, vars, imageTags, helmChartInflationGenerator), а також env у генератора, стара форма envs в однині, яку kustomize edit fix об'єднує в envs
• K15: commonLabels, який також переписує селектори, що їх неможливо змінити в робочих навантаженнях, які вже працюють
• K16: disableNameSuffixHash: true, через що змінена конфігурація не перезапускає поди
• K17: оверлеї, які не задають namespace, namePrefix чи nameSuffix, поверх локальної бази, яка теж не задає namespace (бази лише з кластерних типів, як-от ClusterIssuer чи ClusterRole, не зачіпаються)
• K18: файли, що завантажуються з-поза меж папки kustomization, які стандартний load restrictor відхиляє

Що входить до комплекту

• Сканер (Python 3.9+, лише стандартна бібліотека)
• Посібник із правил із причиною, безпечнішим підходом і офіційним джерелом для кожного правила
• Ризикований і безпечний приклади репозиторію (база, продакшн-оверлей і платформний kustomization), а також реальний звіт сканера щодо ризикованого прикладу

Обмеження

Він читає файли kustomization у тому вигляді, в якому вони записані, і не виконує збирання, тому результат патчів, components, replacements і шаблонів Helm, а також самі маніфести Kubernetes не перевіряються. Віддалені бази та чарти не завантажуються. Чи закомічений файл, визначається лише за файлами .gitignore. Теги та гілки розрізняються за назвами. Namespace, заданий в Application Argo CD або у Flux Kustomization, невідомий. NOT FLAGGED не є гарантією.

Вміст

Один ZIP-файл із 27 файлами: SKILL.md, сканер у scripts/ (8 файлів Python), references/rules.md (кожне правило з причиною та безпечнішим підходом) і examples/ (16 файлів прикладів плюс report.md, реальний вивід сканера щодо ризикованого прикладу).

Як користуватися: Це навик для агента: папка з файлом SKILL.md і скриптами Python, які може запускати ШІ-агент для програмування, наприклад Claude Code, Cursor або Codex CLI. Розпакуйте його в папку навиків вашого агента (для Claude Code: ~/.claude/skills/), потім попросіть агента перевірити ваш проєкт. Скрипти також працюють самостійно з Python 3.9 або новішим, нічого встановлювати не потрібно. Вони лише читають ваші файли: без доступу до мережі, і нічого нікуди не надсилається.