Kubernetes Manifest Linter

Kubernetes-manifester bliver som regel gennemgået med øjnene i et pull request, hvilket betyder, at den samme håndfuld hardening-fejl bliver ved med at slippe igennem til produktion: en Deployment uden memory-limit, der til sidst bliver OOM-dræbt og tager en node med sig, en container, der uden videre kører som root, fordi ingen satte runAsNonRoot, eller en Pod, der er låst til et billedtag som `:latest`, der ændrer sig lydløst midt i en rollout. Denne linter fanger den slags problemer i det øjeblik, du indsætter en manifest, uden at du har brug for en kørende klynge, kubectl-kontekst eller nogen form for legitimationsoplysninger.

Under motorhjelmen indeholder den en lille, håndskrevet YAML-parser, der er skrevet specifikt til den realistiske delmængde af YAML, som Kubernetes-manifester rent faktisk bruger: `---`-adskilte dokumenter, indrykningsbaseret indlejring, `key: value` og indlejrede block mappings, `- ` listepunkter inklusive lister af maps, citerede og uciterede skalarer, kommentarer og `|`/`>`-blokskalarer til f.eks. flerlinjede ConfigMap-værdier eller annoteringer. Der er intet eksternt YAML-bibliotek involveret – både parseren og regel-maskinen er indbygget i værktøjet og kører udelukkende i din browser.

Regeltabellen er baseret på velkendt cluster-hardening-vejledning – CIS Kubernetes Benchmark, kube-score og Pod Security Standards "Restricted"-profilen – og tjekker hver container for manglende resource requests/limits, containere, der kan køre som root eller i privileged mode, manglende liveness- og readiness-probes på længerevarende workloads (Deployments, StatefulSets, DaemonSets), hostPath-volumemounts, der blotlægger værtens filsystem, brug af hostNetwork og ikke-reproducerbare `:latest`- eller utaggede containerbilleder. Fund grupperes efter dokument og container med en tydelig fejl-/advarselsgrad på hver enkelt, så du kan se, hvad der reelt er risikabelt i forhold til, hvad der blot er et venligt puf mod best practice.

Den virker på enkelte manifester eller hele multi-dokumentfiler indsat direkte fra et Helm template-render eller et `kustomize build`-output og forstår ressourcetyperne Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet og CronJob. Fordi alting kører lokalt, er det sikkert at indsætte manifester, der indeholder interne servicenavne, reel ressource-dimensionering eller andet, du ikke ønsker at sende til en tredjeparts-API – praktisk til et hurtigt pre-commit-sanitytjek, en hjælp til code review eller bare til at lære, hvordan "hardened" egentlig ser ud i praksis.