Kubernetes löst Ihre Anwendungssicherheitsprobleme nicht – es legt lediglich eine Orchestrierungsebene darüber. Jeder Cluster führt eine Control Plane, eine Node Runtime, ein Identitätsmodell, ein softwaredefiniertes Netzwerk und einen Secrets Store ein, jeweils mit eigenen Fehlerursachen. Ein einziges übermäßig permissives RoleBinding oder ein privileged: true Pod kann einen Web-Bug mit geringer Schwere in eine vollständige Cluster-Übernahme verwandeln und von dort aus zu einer Kompromittierung des dahinterliegenden Cloud-Kontos führen.
Dieser Leitfaden beschreibt, wie man eine Kubernetes-Umgebung tatsächlich testet: die Angriffsfläche, die Fehlkonfigurationen, die in fast jedem Audit auftauchen, die Container-Escape-Vektoren, die einen kompromittierten Pod zu Root auf dem Node machen, und wie die drei Disziplinen – Image Scanning, Runtime Testing und Cluster Penetration Testing – zusammenpassen.
Die Kubernetes-Angriffsfläche
Bevor Sie testen, erfassen Sie, was ein Angreifer sieht. Ein Kubernetes-Cluster legt vier hochwertige Komponenten offen, und jede davon ist ein eigenständiges Ziel mit eigenen Fehlerursachen.
Der API-Server
Der kube-apiserver ist die Eingangstür zu allem. Jeder kubectl-Befehl, jeder Controller, jede Workload, die mit dem Cluster kommuniziert, läuft über ihn. Das Testen des API-Servers bedeutet zu überprüfen, ob der anonyme Zugriff deaktiviert ist, dass die Authentifizierung erzwungen wird (nicht nur eine RBAC-Autorisierung hinter einer offenen Tür), dass die Flags --anonymous-auth=false und für das Audit-Logging gesetzt sind und dass der Endpunkt nicht unnötig dem öffentlichen Internet ausgesetzt ist. Eine überraschende Anzahl von verwalteten und selbst gehosteten Clustern lässt den API-Server immer noch von überall her erreichbar, nur mit tokenbasierter Absicherung.
The kubelet
Jeder Node führt ein kubelet aus, das eine API (Standardport 10250) zur Verwaltung von Pods auf diesem Node bereitstellt. Wenn das kubelet unauthentifizierten oder schreibgeschützten Zugriff erlaubt (der Legacy-Port 10255), kann ein Angreifer, der einen Node erreicht – oder ein Pod, der dorthin routen kann –, laufende Pods aufzählen, deren Umgebung lesen und in falsch konfigurierten Clustern Befehle innerhalb von Containern ausführen. Das kubelet ist der klassische Pivot-Punkt, nach dem kube-hunter sucht.
etcd
etcd ist die Datenbank des Clusters. Es speichert jedes Objekt, einschließlich Secrets, im Klartext, es sei denn, die Verschlüsselung im Ruhezustand ist explizit aktiviert. Direkter Zugriff auf etcd ist gleichbedeutend mit cluster-admin: Sie können jede Anmeldeinformation lesen und den Cluster-Status umschreiben. Tests überprüfen, ob etcd nur von der Control Plane aus erreichbar ist, gegenseitiges TLS erfordert und --encryption-provider-config so konfiguriert ist, dass Secrets nicht im Klartext vorliegen.
RBAC und Identität
Die rollenbasierte Zugriffssteuerung ist das verbindende Element. Sie entscheidet, welche Subjekte welche Ressourcen berühren dürfen. Da RBAC additiv ist und leicht zu viele Berechtigungen vergeben werden können, ist es die häufigste Quelle für Privilege-Escalation-Pfade in realen Clustern – im Folgenden ausführlich behandelt.
Häufige Cluster-Fehlkonfigurationen
Der Ausdruck Kubernetes-Cluster-Sicherheitsfehlkonfiguration umfasst eine vorhersehbare Reihe von Mustern. Dies sind die Ergebnisse, die in fast jeder Ersterhebung auftauchen, grob geordnet danach, wie oft sie zu einer tatsächlichen Kompromittierung führen.
Privilegierte und übermäßig fähige Pods
Ein Pod mit securityContext.privileged: true hat effektiv uneingeschränkten Zugriff auf den Host. Selbst ohne volle Privilegien geben gefährliche Fähigkeiten wie CAP_SYS_ADMIN, allowPrivilegeEscalation: true oder die Ausführung als UID 0 einem Angreifer weit mehr, als die Workload benötigt. Die Lösung ist ein restriktiver Sicherheitskontext, der überall angewendet wird:
hostPath-Mounts und gemeinsame Namespaces
Ein hostPath-Volume bindet ein Verzeichnis vom Knoten in den Pod ein. Bindet man /, /var/run/docker.sock oder /etc/kubernetes ein, kann der Container das Dateisystem des Hosts lesen oder schreiben – eine sofortige Fluchtmöglichkeit. Dasselbe gilt für hostPID, hostNetwork und hostIPC, die die Isolationsgrenze zwischen Pod und Knoten durchbrechen. Tests kennzeichnen jede Workload, die diese anfordert, es sei denn, es gibt einen dokumentierten, geprüften Grund (z. B. ein CNI oder ein Monitoring DaemonSet).
Standard-Service-Account-Tokens
Standardmäßig erhält jeder Pod das default-Service-Account-Token des Namespace, das unter /var/run/secrets/kubernetes.io/serviceaccount/token gemountet ist. Wenn dieser Service-Account über aussagekräftige RBAC-Berechtigungen verfügt – oder wenn die Workload überhaupt keinen API-Zugriff benötigt – ist das Token freies Anmeldeinformationen-Material für jeden, der den Pod kompromittiert. Setzen Sie automountServiceAccountToken: false für Workloads, die die API nicht aufrufen, und beschränken Sie die Berechtigungen derjenigen, die es tun.
Fehlende NetworkPolicies
Standardmäßig ist das Kubernetes-Netzwerk flach: Jeder Pod kann jeden anderen Pod in jedem Namespace erreichen. Ohne NetworkPolicies kann ein einzelner kompromittierter Front-End-Pod direkt mit Ihrer Datenbank, Ihren internen Admin-Diensten und dem Cloud-Metadaten-Endpunkt kommunizieren. Eine Default-Deny-Policy pro Namespace, mit expliziten Erlaubnisregeln, ist die Grundlage:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all spec: podSelector: {} policyTypes: ["Ingress", "Egress"]Unverschlüsselte Secrets und offengelegte Metadaten
Kubernetes Secrets sind Base64-kodiert, nicht verschlüsselt. Ohne etcd-Verschlüsselung im Ruhezustand sind sie für jeden lesbar, der etcd- oder Backup-Zugriff hat. Erschwerend kommt hinzu, dass Pods, die den Cloud-Instanz-Metadatendienst (169.254.169.254) erreichen können, oft die IAM-Rollenanmeldeinformationen des Knotens stehlen können – die Brücke von der Cluster-Kompromittierung zur Cloud-Konto-Kompromittierung.
RBAC: Wer darf was tun
Kubernetes RBAC steuert den Zugriff auf Cluster-Ressourcen über Roles, ClusterRoles, RoleBindings und ClusterRoleBindings. Gute Tests gehen über die Frage hinaus, ob etwas an „cluster-admin“ gebunden ist, und suchen nach Eskalationspfaden – Ketten von einzeln vernünftig erscheinenden Berechtigungen, die sich zu vollständiger Kontrolle verbinden.
Die zu beachtenden Verben sind escalate, bind und impersonate. Ein Subjekt, das Pods create kann, kann oft einen privilegierten Service-Account mounten und dessen Token lesen. Ein Subjekt, das Rollen bind kann, kann sich selbst `cluster-admin` gewähren. Ein Subjekt mit impersonate kann als jeder Benutzer agieren. Weitere klassische Pfade umfassen die Möglichkeit, Secrets clusterweit zu lesen, ValidatingWebhookConfigurations zu erstellen oder zu ändern (wobei jede API-Anfrage abgefangen wird) oder in Pods mit höheren Privilegien zu execen.
Praktische RBAC-Tests beantworten: Trägt ein Standard-Service-Account Berechtigungen, die er nicht benötigt? Kann ein Namespace-bezogenes Subjekt Cluster-bezogene Ressourcen erreichen? Gibt es Wildcard-Regeln (resources: ["*"], verbs: ["*"])? Tools wie rbac-tool und kubectl-who-can helfen, diese aufzulisten, aber die Interpretation, ob eine Kette tatsächlich ausnutzbar ist, ist der Punkt, an dem Adversarial Testing seinen Wert beweist.
Container-Escape-Tests
Die kritischste Klasse von Kubernetes-Schwachstellen ist die container escape vulnerability—das Ausbrechen aus einem Container, um auf den Host-Knoten zuzugreifen und diesen Zugangspunkt dann für die laterale Bewegung zu nutzen. Dies ist der Kern des Problems der container escape vulnerability in Bezug auf die Docker-Sicherheit, und es gilt, unabhängig davon, ob Ihre Laufzeitumgebung containerd, CRI-O oder Docker ist.
Escape-Vektoren lassen sich in zwei Kategorien einteilen. Die erste ist konfigurationsbedingt: Der Container erhielt genügend Zugriffsrechte, um auszubrechen. Eine beschreibbare /var/run/docker.sock ermöglicht es einem Container, einen neuen privilegierten Container auf dem Host zu erstellen. Ein privilegierter Pod kann das Root-Dateisystem des Hosts mounten und einen SSH-Schlüssel oder einen Cron-Job schreiben. hostPID legt Host-Prozesse für die Injektion offen. Dies sind die häufigen, hochwahrscheinlichen Escape-Möglichkeiten, und sie korrespondieren direkt mit den oben genannten Fehlkonfigurationen.
Die zweite Kategorie ist exploit-basiert: Kernel- und Laufzeit-CVEs. Historische Beispiele wie CVE-2019-5736 (runc /proc/self/exe Überschreibung) und verschiedene cgroups- und Kernel-Bugs ermöglichen es einem Angreifer, selbst aus einem vernünftig konfigurierten Container auszubrechen. Tests in diesem Bereich bedeuten, zu wissen, welche Laufzeit- und Kernel-Versionen Sie verwenden, diese mit bekannten Escape-CVEs abzugleichen und zu bestätigen, dass Defense-in-Depth-Kontrollen (seccomp, AppArmor/SELinux, gVisor oder Kata für Hochrisiko-Workloads) tatsächlich durchgesetzt werden, anstatt auf Unconfined gesetzt zu sein.
Eine realistische Kill Chain: ein SSRF-Bug in einer Web-Workload erreicht den Cloud-Metadaten-Endpunkt → stiehlt die Node-IAM-Rolle → die Rolle kann aus einer Container-Registry ziehen und das Service-Konto des Pods kann Secrets auflisten → ein Secret enthält eine Cluster-Admin-kubeconfig → Angreifer plant einen privilegierten Pod auf jedem Knoten ein. Jeder Schritt ist alltäglich. Aneinandergereiht ist es Game Over. Dies ist genau die Art von mehrstufigem Pfad, den automatisierte Single-Issue-Scanner übersehen.
Container Security Scanning vs. Runtime Testing vs. Cluster Pentesting
Teams fragen oft, welches Tool "Kubernetes-Sicherheit" leistet. Die ehrliche Antwort ist, dass es drei verschiedene Disziplinen gibt, die unterschiedliche Fragen beantworten, und ein ausgereiftes Programm alle drei betreibt. Das Verständnis von Container Security Scanning vs. Runtime Testing—und wo Cluster Pentesting einzuordnen ist—ist der Schlüssel, um kein Budget für sich überschneidende Abdeckung zu verschwenden und gleichzeitig echte Lücken zu vermeiden.
| Dimension | Image-Scanning | Laufzeittests | Cluster-Penetration Testing |
|---|---|---|---|
| Beantwortete Frage | Enthält dieses Image bekannte anfällige Pakete? | Verhält sich die laufende Workload gerade sicher? | Kann ein Angreifer den Cluster tatsächlich kompromittieren? |
| Wann es ausgeführt wird | Build / Registry / CI-Gate | Kontinuierlich, im Live-Cluster | Zu einem bestimmten Zeitpunkt, Angreifer-simulierend |
| Was es inspiziert | Image-Layer, OS-Pakete, Bibliotheken, Dockerfile | Systemaufrufe, Prozessverhalten, Netzwerkflüsse, Drift | RBAC, Escape-Pfade, laterale Bewegung, Workload-Exploits |
| Erkennt | CVEs, veraltete Abhängigkeiten, Geheimnisse in Layern | Anomalien, Krypto-Miner, unerwarteter Egress | Verkettete, ausnutzbare Angriffswege Ende-zu-Ende |
| Übersieht | Laufzeitkonfiguration, RBAC, Logikfehler | Latente Fehlkonfigurationen, die noch nicht ausgelöst wurden | Probleme außerhalb des Testzeitraums |
| Beispiel-Tools | Trivy, Grype, Clair | Falco, Tetragon, Sysdig | kube-hunter, manueller Penetration Test, Penetrify |
| Automatisierungsgrad | Vollständig in CI automatisierbar | Immer aktiver Agent | Geplant + kontinuierlich KI-gesteuert |
Image-Scanning ist günstig, schnell und gehört in jede Pipeline—aber ein perfekt gescanntes Image läuft immer noch als Root mit einem hostPath-Mount, wenn man es zulässt. Laufzeittests erkennen, was gerade passiert, sagen aber wenig darüber aus, was passieren könnte. Cluster-Penetration Testing ist das einzige der drei, das die Ausnutzbarkeit beweist, indem es Erkenntnisse so verkettet, wie es ein Angreifer tun würde. Keines ersetzt die anderen.
Tools: kube-bench, kube-hunter und Trivy
Ein solider Workflow für das Container-Sicherheitsscanning für Kubernetes kombiniert normalerweise drei Open-Source-Arbeitspferde, jedes mit einer klaren Rolle. Sie ergänzen sich, anstatt zu konkurrieren.
kube-bench
kube-bench führt den CIS Kubernetes Benchmark für Ihre Nodes und die Control Plane aus. Es ist ein Konfigurationsauditor: Es überprüft API-Server-Flags, kubelet-Einstellungen, Dateiberechtigungen auf Cluster-Komponenten und die etcd-Konfiguration anhand eines bekannten Härtungsstandards. Führen Sie es auf jedem Node und in CI gegen Ihre Cluster-Manifeste aus. Es sagt Ihnen, ob Ihr Cluster gemäß Spezifikation gebaut ist; es sagt Ihnen nicht, ob die Spezifikation angegriffen wird.
kube-hunter
kube-hunter ist ein aktives Aufklärungstool. Auf einen Cluster gerichtet (oder als Pod darin ausgeführt), sondiert es nach exponierten kubelets, zugänglichen API-Endpunkten, dem Metadaten-Dienst und bekannten Schwachstellen und meldet dann, was ein Angreifer entdecken könnte. Es ist eher ein Netzwerk-Scanner für Kubernetes als ein vollständiger Penetration Test—exzellent für die Oberflächenkartierung, begrenzt für den Nachweis einer End-to-End-Ausnutzung.
Trivy
Trivy ist der Schweizer Taschenmesser-Scanner: Container-Image-CVEs, IaC- und Kubernetes-Manifest-Fehlkonfigurations-Scanning, exponierte Geheimnisse und SBOM-Generierung. Es ist die natürliche Wahl für die oben genannte Spalte "Image-Scanning" und lässt sich sauber in Build-Pipelines integrieren. Kombinieren Sie es mit kube-bench für die Konfigurationsabdeckung und kube-hunter für die Live-Aufklärung, und Sie haben eine starke Open-Source-Grundlage.
Was dieses Trio nicht tut, ist, Ihre Anwendungslogik zu verstehen, einen Web-Schicht-Fehler zu einer Cluster-Übernahme zu verketten oder seinen Ansatz so anzupassen, wie es ein menschlicher Angreifer tun würde. Das ist die Lücke, die der nächste Abschnitt behandelt. Für die Integration dieser Scanner in Ihre Delivery Pipeline, siehe unseren Leitfaden zu CI/CD Penetration Testing und Pipeline-Sicherheitsautomatisierung.
Die Workload Web- und API-Schicht
Hier ist der Teil, den die meisten Kubernetes-Sicherheitsprogramme unterschätzen: die Workloads selbst. Ihr Cluster hostet Web-Apps und APIs, und von dort stammt in der Regel der erste Zugangspunkt. Ein Angreifer beginnt selten mit einer gestohlenen kubeconfig—er beginnt mit einem SSRF, einem Auth Bypass oder einem Injection-Bug in einem von Ihnen bereitgestellten Dienst und schwenkt dann mithilfe der oben genannten Fehlkonfigurationen in den Cluster ein.
Genau hier passt autonomes KI Penetration Testing. Konfigurationsscanner und CIS-Benchmarks können keinen Business-Logik Auth Bypass in Ihrem Checkout-Dienst finden; dafür wurden sie nie entwickelt. KI-gesteuertes Testing überprüft die laufenden Web- und API-Endpunkte innerhalb Ihrer Workloads so, wie es ein Angreifer tun würde—es prüft Authentifizierung, Autorisierung, Injection und SSRF—und folgt dann der Kette: von einem Workload-Bug, über das gemountete Service Account Token, zu den Cluster-Berechtigungen, die dieses Token freischaltet, bis hin zur Cloud IAM Role hinter dem Knoten.
Diese kontinuierliche, Exploit-verkettende Abdeckung der Anwendungsschicht ergänzt—anstatt zu ersetzen—Ihre kube-bench- und Trivy-Pipeline. Für die API-spezifische Dimension behandelt unser Deep Dive zum Thema Automatisierung von API Security Testing die OWASP API Top 10 und wie man dieses Testing über verschiedene Deployments hinweg wiederholbar macht.
Wenn Sie noch dabei sind, zu planen, welche Workloads und Cluster priorisiert werden sollen, behandelt der begleitende Beitrag zum Thema Container Security Testing für Docker Images und Runtime Protection die Image- und Runtime-Seiten ausführlicher, und unser Walkthrough zur Behebung gängiger Kubernetes-Cluster-Fehlkonfigurationen bietet konkrete Abhilfemaßnahmen für die oben genannten Probleme.
Kubernetes mit Penetrify testen
Penetrify's Kubernetes Security Testing umfasst RBAC, Pod Security, Netzwerkrichtlinien, Secrets Management, Container Escape Vectors und verwaltete Kubernetes-Konfigurationen (EKS, AKS, GKE). Das Testing bewertet sowohl die Kubernetes-Schicht als auch die Cloud Provider Integrationsschicht—da eine Kubernetes-Kompromittierung oft zu einer Cloud Account Kompromittierung durch verknüpfte Service Accounts und IAM Roles führt.
Der Kostenunterschied ist der Grund, warum Teams dies automatisieren. Ein traditioneller manueller Kubernetes Pentest von einer Beratungsfirma kostet typischerweise 5.000 bis 50.000 US-Dollar pro Auftrag und liefert Ihnen eine Momentaufnahme, die im Augenblick Ihres nächsten Deployments bereits veraltet ist. Penetrify läuft kontinuierlich von 100 bis 5.000 US-Dollar pro Monat und testet bei jeder Änderung Ihres Clusters erneut. Für eine detailliertere Aufschlüsselung dieser Zahlen, siehe unseren Penetration Testing Kostenvergleich.
Das Fazit
Kubernetes fügt Ihrer Cloud-Infrastruktur eine gesamte Orchestrierungsebene als Angriffsfläche hinzu. Dessen Prüfung erfordert drei komplementäre Disziplinen—Image-Scanning, Laufzeitüberwachung und Cluster-Penetration Testing—sowie adversatives Testing der Web- und API-Workloads, die Angreifern ihren ersten Zugangspunkt bieten. Konfigurationsscanner härten den Build; nur Exploit-Chaining-Pentesting beweist, was ein Angreifer tatsächlich erreichen kann.
Penetrify kombiniert autonomes KI-Pentesting Ihrer Workloads mit Cluster- und Cloud-Integrationstests, kontinuierlich und ab 100 $/Monat—damit Ihre Kubernetes-Sicherheit mit jeder Bereitstellung Schritt hält, anstatt nur mit jeder jährlichen Prüfung.