Linter manifestów Kubernetes

Manifesty Kubernetes są zazwyczaj przeglądane na oko podczas pull requesta, przez co wciąż do produkcji trafiają te same błędy bezpieczeństwa: Deployment bez limitu pamięci, który zostaje ubity przez OOM i ciągnie za sobą węzeł, kontener uruchamiany jako root, bo nikt nie ustawił runAsNonRoot, czy Pod przypięty do tagu `:latest`, który po cichu zmienia się podczas wdrożenia. Ten linter wyłapuje tę klasę problemów od razu po wklejeniu manifestu — bez działającego klastra, kontekstu kubectl czy jakichkolwiek poświadczeń.

Pod spodem kryje się niewielki, własny parser YAML napisany specjalnie dla realistycznego podzbioru YAML, którego faktycznie używają manifesty Kubernetes: dokumenty rozdzielone `---`, zagnieżdżenia oparte na wcięciach, mapowania `klucz: wartość` i blokowe, elementy sekwencji `- ` łącznie z listami map, skalary cytowane i niecytowane, komentarze oraz skalary blokowe `|`/`>` dla wielowierszowych wartości ConfigMap lub adnotacji. Nie korzystamy z żadnej zewnętrznej biblioteki YAML — zarówno parser, jak i silnik reguł są osadzone w narzędziu i działają w całości w Twojej przeglądarce.

Tabela reguł została opracowana na podstawie uznanych wytycznych bezpieczeństwa klastrów — CIS Kubernetes Benchmark, kube-score i profilu „Restricted” Pod Security Standards — i sprawdza każdy kontener pod kątem: brakujących żądań/limitów zasobów, możliwości uruchamiania jako root lub w trybie uprzywilejowanym, braku sond liveness i readiness w obciążeniach długoterminowych (Deploymenty, StatefulSety, DaemonSety), montowań wolumenów hostPath dających dostęp do systemu plików hosta, użycia hostNetwork oraz niereprodukowalnych obrazów z tagiem `:latest` lub bez tagu. Znaleziska są grupowane według dokumentu i kontenera, z wyraźnym oznaczeniem poziomu error/warning, abyś wiedział, co jest naprawdę ryzykowne, a co jedynie podpowiedzią dobrej praktyki.

Narzędzie działa na pojedynczych manifestach i całych plikach wielodokumentowych wklejonych wprost z wyniku `helm template` lub `kustomize build`, rozpoznając zasoby Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet i CronJob. Ponieważ wszystko odbywa się lokalnie, możesz bezpiecznie wklejać manifesty zawierające wewnętrzne nazwy serwisów, rzeczywiste rozmiary zasobów czy cokolwiek, czego nie chciałbyś wysyłać do zewnętrznego API — przydatne jako szybki test przed commitem, pomoc przy code review czy po prostu nauka, jak wygląda „utwardzony” manifest w praktyce.