Kubernetes Security Review

Das Problem

Kubernetes ist sicher durch Konfiguration, nicht ab Werk. Ein Cluster, der einen Schwachstellenscan besteht, kann einem Angreifer dennoch die gesamte Umgebung überlassen – denn die interessanten Schwächen sind keine fehlenden Patches. Es sind ein Service Account mit cluster-admin, an dessen Vergabe sich niemand erinnert, ein Namespace ohne Network Policy in einem Cluster, dessen Standard „allow all" lautet, ein Workload, der privilegiert läuft, weil das vor zwei Jahren der schnellste Weg an einem Fehler vorbei war, und ein Admission Controller, der Verstöße protokolliert statt sie zu blockieren.

Die meisten Organisationen entdecken das auf eine von zwei Arten: Entweder verlangt eine Prüfinstanz den Nachweis, dass die Cluster einem anerkannten Härtungsstandard entsprechen, und niemand kann ihn erbringen. Oder jemand fasst in einem Workload Fuß, und es zeigt sich, dass laterale Bewegung nie wirklich eingeschränkt war.

Der Review existiert, um genau das zu finden, solange es noch günstig ist.

Was wir prüfen

• Identität und RBAC. Analyse von Roles und Bindings, Wildwuchs bei cluster-admin, zu weit gefasste Service Accounts, Token-Exposition und die Frage, was jede Identität im Kompromittierungsfall erreichen könnte

• Workload-Härtung. Konformität mit den Pod Security Standards, privilegierte Container, Nutzung von Host-Namespaces und Host-Pfaden, Capabilities sowie die Lücke zwischen dem, was Workloads anfordern, und dem, was sie brauchen

• Netzwerk-Posture. Ob eine Default-Deny-Position existiert, wie Segmentierung zwischen Namespaces und Mandanten durchgesetzt wird, Egress-Kontrolle und was ein Angreifer aus einem Pod heraus erreichen kann

• Supply Chain. Image-Provenienz, Registry-Vertrauen, Signaturprüfung, Admission Control und die Frage, ob Policies durchsetzen oder nur beraten

• Umgang mit Secrets. Verschlüsselung im Ruhezustand, Anbindung externer Secret Stores, Secrets in Manifesten und Umgebungsvariablen sowie Mount-Muster

• Control Plane. Exposition des API-Servers, Authentifizierungspfade, etcd-Verschlüsselung, Konfiguration des Audit-Logs und die Frage, ob der Audit-Trail eine echte Frage beantworten würde

• Mandantengrenzen. Wo die Isolation auf Namespace-Ebene liegt, wo sie stärker ist und ob sie dem entspricht, was die Workloads auf diesen Clustern tatsächlich verlangen

• Runtime-Erkennung. Was überwacht wird, was auffallen würde und wie lange es dauern würde

Wir bewerten gegen den CIS Kubernetes Benchmark und die Kubernetes Hardening Guidance von NSA und CISA, weil das die Standards sind, auf die sich Ihre Prüfer und Ausschreibungen beziehen. Für die Abdeckung setzen wir automatisierte Werkzeuge ein, für die Befunde, die Werkzeuge nicht sehen können, manuelle Analyse – und das sind erfahrungsgemäß die relevanten.

Ablauf

Dies ist ein Review, kein Penetrationstest. Wir arbeiten mit lesendem Zugriff und Konfigurationsanalyse statt mit Exploitation: schneller, schonender für die Produktion und mit einem anderen, meist größeren Fundspektrum. Wo ein Befund einen Nachweis verdient, sagen wir das und beauftragen ihn separat.

Was Sie erhalten

• Priorisierte Befunde, jeweils mit der entstehenden Exposition, dem zugehörigen Nachweis und einer konkreten Maßnahme

• Konformitätsposition gegenüber CIS- und NSA/CISA-Vorgaben, in einer Form, die Sie einer Prüfinstanz vorlegen können

• Angriffspfad-Narrative: was ein kompromittierter Workload erreichen könnte und wo es endet

• Ein Maßnahmenplan, sortiert nach Risikoreduktion je Aufwandseinheit, getrennt nach dem, was diesen Monat zu beheben ist, und dem, was in eine Plattform-Roadmap gehört

• Ein technisches Readout für Ihre Engineers und eine kurze Executive Summary für diejenigen, die die Behebung finanzieren

Für wen es gedacht ist

Für Organisationen mit produktiven Workloads auf Kubernetes – insbesondere dort, wo Cluster mandantenfähig sind, wo eine regulatorische Pflicht greift oder wo die Plattform schneller gewachsen ist als der Zyklus der Sicherheitsprüfungen.

Wie es weitergeht

Die Befunde teilen sich meist in zwei Gruppen: die unmittelbaren Korrekturen, die Ihr Team direkt umsetzen kann, und die strukturellen – Durchsetzung statt beratender Policies, tragfähige Mandantentrennung, Guardrails innerhalb des Golden Path –, die in die Plattformarbeit gehören. Dort ist das Platform Engineering Maturity Assessment der natürliche nächste Schritt, und die Befunde des Reviews fließen unmittelbar ein.