Kubernetes Manifest Analyzer
Füge ein Kubernetes-Manifest ein, um fehlende Ressourcenlimits, riskante Sicherheitseinstellungen und zu weite RBAC-Regeln zu finden, mit vorgeschlagenem Patch.
Läuft im Browser · es wird nichts gesendetKubernetes & IaCNeu
Alles läuft in deinem Browser. Es wird nichts gesendet, auch keine Image-Namen, Namespaces oder Labels aus deinem Manifest.
So geht’s
- Kopiere ein Manifest mit "kubectl get deployment <name> -o yaml" oder aus deinen Quelldateien.
- Füge das YAML in das Tool ein (nutze "---" zwischen Dokumenten, wenn du mehr als eines hast).
- Sieh dir die Ergebnisse und die Ressourcentabelle an.
- Öffne „Vorgeschlagene Änderungen“ für einen Patch zum Einfügen in dein Manifest und exportiere den Bericht bei Bedarf.
Typische Szenarien
Prüfe, ob Ressourcenlimits, Probes und ein sicherer Security-Context vorhanden sind, bevor du ein Manifest zusammenführst.
Füge eine Role oder ClusterRole ein, um auf Wildcard-Rechte oder Secret-Zugriff zu prüfen, bevor du sie an ein Service-Account bindest.
Erklärung
Füge ein oder mehrere Kubernetes-Manifeste ein (durch "---" getrennt, wenn es mehrere sind), und das Tool prüft jeden Workload (Pod, Deployment, StatefulSet, DaemonSet, Job, CronJob) auf fehlende Ressourcenlimits und -anforderungen, einen fehlenden oder riskanten Security-Context (privilegierte Container, erlaubte Privilege Escalation, ein beschreibbares Root-Dateisystem, gefährliche Linux-Capabilities), fehlende Liveness- und Readiness-Probes und einen nicht fixierten Image-Tag. Zusätzlich prüft es jede Role und ClusterRole auf zu weite RBAC-Regeln, etwa ein Wildcard sowohl bei Ressourcen als auch bei Verbs, oder Lesezugriff auf Secrets. Für jeden Container mit etwas Fehlendem schlägt das Tool einen Patch vor, den du in dein Manifest einfügen kannst. Alles läuft lokal; das Manifest verlässt deinen Browser nie.
🔒 Deine Eingabe bleibt in deinem Browser und wird nirgendwohin gesendet.
Häufige Fragen
Validiert das gegen die Kubernetes-API oder einen Cluster?
Nein. Es parst nur das eingefügte YAML und prüft es gegen einen festen Regelsatz, ohne sich mit einem Cluster oder API-Server zu verbinden.
Warum wird ein fehlendes "runAsNonRoot: true" gemeldet, auch wenn das Image bereits einen Non-Root-Benutzer verwendet?
Ohne die explizite Einstellung darf der Container trotzdem als Root laufen, falls das Image irgendwann durch eines ersetzt wird, das standardmäßig Root nutzt, absichtlich oder nicht. Die explizite Einstellung macht diesen Fehler unmöglich statt nur unwahrscheinlich.
Was enthält der vorgeschlagene Patch?
Nur die Felder, die dieses Tool wirklich prüft: Ressourcenanforderungen und -limits, einen sichereren Security-Context und Beispiel-Liveness/Readiness-Probes. Die Beispielwerte (besonders Ressourcenlimits) sind ein Ausgangspunkt, keine Messung deines Workloads, also passe sie an das an, was der Container wirklich braucht.
Werden CronJob und Dateien mit mehreren Dokumenten unterstützt?
Ja. CronJob wird über sein verschachteltes jobTemplate geprüft, und du kannst mehrere Dokumente einfügen, getrennt durch "---", einschließlich einer Mischung aus Workloads und RBAC-Ressourcen.
Wie geht es weiter?
Problem gefunden oder einen Vorschlag? Schreib uns