Kubernetes manifest analyzer
Plak een Kubernetes-manifest om ontbrekende resource-limieten, risicovolle beveiligingsinstellingen en te brede RBAC-regels te vinden, met een voorgestelde patch.
Draait in je browser · er wordt niets verstuurdKubernetes & IaCNieuw
Alles draait in je browser. Er wordt niets verstuurd, ook geen imagenamen, namespaces of labels uit je manifest.
Zo gebruik je het
- Kopieer een manifest met "kubectl get deployment <naam> -o yaml" of uit je broncode.
- Plak de YAML in de tool (gebruik "---" tussen documenten als je er meer dan één hebt).
- Bekijk de bevindingen en de resourcetabel.
- Open "Voorgestelde wijzigingen" voor een patch om in je manifest samen te voegen, en exporteer het rapport indien nodig.
Veelvoorkomende situaties
Controleer of resource-limieten, probes en een veilige security context aanwezig zijn voordat je een manifest samenvoegt.
Plak een Role of ClusterRole om te controleren op wildcard-rechten of Secret-toegang voordat je hem aan een service account koppelt.
Uitleg
Plak een of meer Kubernetes-manifesten (gescheiden door "---" als het er meerdere zijn) en de tool controleert elke workload (Pod, Deployment, StatefulSet, DaemonSet, Job, CronJob) op ontbrekende resource-limieten en -requests, een ontbrekende of risicovolle security context (privileged containers, toegestane privilege escalation, een schrijfbaar root-bestandssysteem, gevaarlijke Linux-capabilities), ontbrekende liveness- en readiness-probes, en een niet-vastgezette image-tag. Daarnaast controleert de tool elke Role en ClusterRole op te brede RBAC-regels, zoals een wildcard op zowel resources als verbs, of leestoegang tot Secrets. Voor elke container met iets ontbrekends stelt de tool een patch voor die je in je manifest kunt samenvoegen. Alles draait lokaal; het manifest verlaat je browser nooit.
🔒 Je invoer blijft in je browser en wordt nergens naartoe gestuurd.
Veelgestelde vragen
Valideert dit tegen de Kubernetes-API of een cluster?
Nee. De tool parset alleen de geplakte YAML en controleert die tegen een vaste set regels, zonder verbinding met een cluster of API-server.
Waarom wordt een ontbrekende "runAsNonRoot: true" gemeld, ook als de image al een non-root gebruiker gebruikt?
Zonder de expliciete instelling mag de container alsnog als root draaien als de image ooit vervangen wordt door een die standaard root gebruikt, bewust of niet. Door het expliciet in te stellen maak je die fout onmogelijk in plaats van alleen onwaarschijnlijk.
Wat staat er in de voorgestelde patch?
Alleen de velden die deze tool echt controleert: resource-requests en -limieten, een veiligere security context, en voorbeeld liveness/readiness-probes. De voorbeeldwaarden (vooral resource-limieten) zijn een startpunt, geen meting van je workload, dus pas ze aan op wat de container echt nodig heeft.
Ondersteunt dit CronJob en bestanden met meerdere documenten?
Ja. CronJob wordt gecontroleerd via zijn geneste jobTemplate, en je kunt meerdere documenten plakken gescheiden door "---", inclusief een mix van workloads en RBAC-resources.
Wat nu?
Een probleem gevonden of een suggestie? Laat het ons weten