Лінтер маніфестів Kubernetes

Маніфести Kubernetes зазвичай перевіряють "на око" під час рев'ю pull request-а, тому одні й ті самі помилки захисту знову й знову потрапляють у продакшн: Deployment без ліміту пам'яті, який рано чи пізно приведе до OOM-kill і потягне за собою вузол; контейнер, що спокійно працює від root, бо ніхто не встановив runAsNonRoot; або Pod, прив'язаний до тегу образу `:latest`, який непомітно змінюється під час наступного розгортання. Цей лінтер виявляє такі проблеми одразу після вставлення маніфесту — без потреби в живому кластері, kubectl-контексті чи будь-яких облікових даних.

Під капотом інструмент має невеликий, написаний з нуля YAML-парсер, розрахований саме на той реалістичний підмножина YAML, який справді використовують маніфести Kubernetes: документи, розділені `---`, вкладеність на основі відступів, пари `ключ: значення` та вкладені блокові мапи, елементи послідовностей `- `, зокрема списки мап, лапкові й безлапкові скаляри, коментарі, а також блокові скаляри `|`/`>` для багаторядкових значень на кшталт даних ConfigMap чи анотацій. Жодної зовнішньої YAML-бібліотеки не використовується — і парсер, і механізм правил постачаються разом з інструментом і працюють повністю у вашому браузері.

Таблиця правил побудована на основі відомих рекомендацій щодо захисту кластера — CIS Kubernetes Benchmark, kube-score та профілю "Restricted" зі стандартів Pod Security Standards — і перевіряє кожен контейнер на відсутність запитів/лімітів ресурсів, можливість працювати від root або у привілейованому режимі, відсутність проб готовності й живучості для довготривалих навантажень (Deployment, StatefulSet, DaemonSet), монтування томів hostPath, що відкривають доступ до файлової системи хоста, використання hostNetwork, а також невідтворювані образи з тегом `:latest` або взагалі без тегу. Знахідки групуються за документом і контейнером, з чіткою позначкою рівня серйозності (помилка/попередження), щоб було видно, що справді небезпечно, а що — лише порада щодо кращих практик.

Інструмент працює як з окремими маніфестами, так і з цілими багатодокументними файлами, вставленими прямо з рендеру Helm-шаблону чи виводу `kustomize build`, розпізнаючи ресурси Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet і CronJob. Оскільки все виконується локально, безпечно вставляти маніфести з внутрішніми назвами сервісів, реальними розмірами ресурсів чи будь-чим іншим, що ви не хотіли б надсилати стороннім API — зручно для швидкої перевірки перед комітом, як допоміжний інструмент рев'ю коду або просто щоб побачити, як насправді виглядає "захищений" маніфест.