Linter manifestu Kubernetes

Manifesty Kubernetesa są zwykle przeglądane wzrokowo w żądaniu ściągnięcia, co oznacza, że do środowiska produkcyjnego trafiają te same błędy związane z wzmacnianiem zabezpieczeń: wdrożenie bez limitu pamięci, które ostatecznie zostaje zabite przez OOM i zabiera ze sobą węzeł, kontener, który bez problemu działa jako root, ponieważ nikt nie ustawił runAsNonRoot, lub Pod przypięty do znacznika obrazu, takiego jak „:latest”, który cicho zmienia się pod wpływem wdrożenia. Ten linter wychwytuje problemy tej klasy w momencie wklejenia manifestu, bez konieczności uruchamiania klastra, kontekstu kubectl ani żadnych poświadczeń.

Pod maską zawiera mały, ręcznie napisany parser YAML napisany specjalnie dla realistycznego podzbioru YAML, którego faktycznie używają manifesty Kubernetes: `---`-dokumenty oddzielone, zagnieżdżanie oparte na wcięciach, `klucz: wartość` i zagnieżdżone mapowania bloków, `- ` elementy sekwencji, w tym listy map, skalary w cudzysłowie i bez cudzysłowu, komentarze i skalary blokowe `|`/`>` dla rzeczy takich jak wielowierszowe Wartości lub adnotacje ConfigMap. Nie ma tu żadnej zewnętrznej biblioteki YAML — zarówno parser, jak i silnik reguł są dołączone do narzędzia i działają całkowicie w przeglądarce.

Tabela reguł jest wzorowana na dobrze znanych wskazówkach dotyczących wzmacniania klastrów — CIS Kubernetes Benchmark, kube-score i profil „Restricted” standardów bezpieczeństwa Pod — i sprawdza każdy kontener pod kątem brakujących żądań/limitów zasobów, kontenerów, które mogą działać jako root lub w trybie uprzywilejowanym, brakujących sond żywotności i gotowości w przypadku długotrwałych obciążeń (wdrożeń, zestawów stanowych, zestawów demonów), montowań woluminów hostPath ujawniających host system plików, wykorzystanie sieci hostNetwork i nieodtwarzalne `:latest` lub nieoznaczone obrazy kontenerów. Wyniki są pogrupowane według dokumentów i kontenerów, z wyraźną wagą błędu/ostrzeżenia dla każdego z nich, dzięki czemu można odróżnić, co jest faktycznie ryzykowne, od tego, co jest jedynie podpowiedzią najlepszych praktyk.

Działa na pojedynczych manifestach lub całych plikach zawierających wiele dokumentów wklejonych bezpośrednio z renderowania szablonu Helm lub wyników kompilacji „kustomize”, rozumiejąc zasoby Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet i CronJob. Ponieważ wszystko działa lokalnie, można bezpiecznie wkleić manifesty zawierające wewnętrzne nazwy usług, rzeczywisty rozmiar zasobów lub cokolwiek innego, czego nie chciałbyś wysyłać do interfejsu API strony trzeciej — przydatne do szybkiego sprawdzenia poprawności przed zatwierdzeniem, pomocy przy przeglądaniu kodu lub po prostu dowiedzenia się, jak faktycznie wygląda „zaostrzony” w praktyce.