Kubernetes-Cluster systematisch auf Sicherheitslücken prüfen

Angriffsperspektive mit kube-hunter

Das Tool kube-hunter prüft ausschließlich technisch erreichbare Endpunkte. Das Werkzeug bewertet keine abstrakten Richtlinien, sondern untersucht reale Netzwerkpfade. Die Installation erfolgt auf einem Linux-System oder in einer WSL-Umgebung mit Python 3 über den Befehl pip install kube-hunter.

Dieser Befehl lädt das Paket aus dem Python Package Index und installiert alle erforderlichen Abhängigkeiten lokal im Benutzerkontext.

Nach erfolgreicher Installation steht das Binary kube-hunter im PATH zur Verfügung. Der Start ohne Parameter öffnet ein interaktives Menü kube-hunter.

Das Menü bietet verschiedene Scan-Modi an. Ein Interface-Scan untersucht alle Netzwerkschnittstellen des Systems. Ein Remote-Scan richtet sich gezielt gegen eine IP-Adresse oder einen DNS-Namen. Ein CIDR-Scan prüft einen gesamten IP-Adressbereich.

Wird ein Interface-Scan gewählt, analysiert kube-hunter sämtliche erreichbaren Subnetze. Dabei führt das Tool zunächst Port-Scans auf bekannten Kubernetes-Diensten durch. Erkennt es offene Ports wie 2379 für Etcd oder 10250 für die Kubelet-API, dokumentiert es diese mit Angabe der IP-Adresse und Portnummer. Ein gezielter Remote-Scan erfolgt mit kube-hunter --remote 192.168.49.2.

Hier prüft das Tool ausschließlich die angegebene Zieladresse. Diese Methode simuliert die Sicht eines externen Angreifers, der keine internen Metadaten kennt und nur über Netzwerkzugriff verfügt. Ein Scan eines gesamten Netzsegments wird mit kube-hunter --cidr 192.168.49.0/24 ausgeführt. Dieser Befehl veranlasst kube-hunter, alle IP-Adressen innerhalb dieses Bereichs auf typische Kubernetes-Dienste zu prüfen.

Aktive Prüfungen, bei denen das Tool weitergehende Tests ausführt, lassen sich mit dem Parameter --active aktivieren, zum Beispiel so:

kube-hunter --remote 192.168.49.2 --active

In diesem Modus versucht kube-hunter unter kontrollierten Bedingungen, bekannte Fehlkonfigurationen auszunutzen. Dazu zählt der Zugriff auf nicht authentifizierte Kubelet-Endpunkte oder Lesezugriffe auf Etcd. Diese Prüfungen liefern Hinweise auf reale Angriffsmöglichkeiten.

Für containerisierte Umgebungen steht ein Docker-Image bereit. Der Start erfolgt mit dem Befehl docker run -it --rm --network host aquasec/kube-hunter.

Der Parameter --network host sorgt dafür, dass der Container die Netzwerkschnittstellen des Hosts direkt nutzt. Ohne diese Option würde Docker ein isoliertes Netzwerk bereitstellen, wodurch interne Cluster-Komponenten möglicherweise nicht erreichbar wären.

Alternativ kann kube-hunter als Job im Cluster laufen. In diesem Szenario wird das Tool als Pod gestartet, der mit einem Service-Account arbeitet. Die Ausführung erfolgt über kubectl apply -f job.yaml.

Die Ergebnisse werden anschließend mit kubectl logs <pod-name> ausgelesen.

Diese Betriebsart simuliert eine kompromittierte Anwendung innerhalb des Clusters und zeigt, welche Ressourcen mit den zugewiesenen Rechten erreichbar bleiben.

Konfigurationsprüfung mit kube-bench

Während kube-hunter erreichbare Dienste analysiert, prüft kube-bench die lokale Systemkonfiguration gegen die CIS Kubernetes Benchmark. Zunächst wird mit kubectl config get-contexts sichergestellt, dass der richtige Cluster-Kontext aktiv ist.

Die Ausgabe zeigt den aktuellen Kontext minikube, der als CURRENT markiert ist. Nur wenn dieser Kontext aktiv ist, greifen kubectl und nachgelagerte Werkzeuge auf das richtige Cluster zu.

Für eine vollständige Analyse wird eine Verbindung zum Minikube-Node mit minikube ssh aufgebaut.

Dieser Befehl öffnet eine SSH-Sitzung direkt im virtuellen Node. Dazu benötigt kube-bench Zugriff auf lokale Konfigurationsdateien und Prozessinformationen. Daher wird das Tool als Container mit Host-PID und Host-Netzwerk ausgeführt:

sudo docker run --rm -it --pid=host –net host \

-v /etc/kubernetes:/etc/kubernetes:ro \

-v /var/lib:/var/lib:ro \

-v /var/run:/var/run:ro \

aquasec/kube-bench:latest run --version 1.35

Die Option --pid=host erlaubt dem Container Zugriff auf die Prozessliste des Hosts. Der Parameter --net=host stellt sicher, dass Netzwerkparameter korrekt erkannt werden. Die Volume-Mounts binden relevante Verzeichnisse schreibgeschützt ein, damit kube-bench Dateirechte und Konfigurationsparameter prüfen kann. Ein FAIL-Eintrag kann auf fehlerhafte Eigentümerrechte im Etcd-Verzeichnis hinweisen. Die Korrektur erfolgt mit:

sudo chown -R etcd:etcd /var/lib/etcd

Dieser Befehl weist alle Dateien im Verzeichnis dem Benutzer und der Gruppe etcd zu. Werden unzureichende Rechte bei der Kubelet-Konfiguration festgestellt, wird die Datei mit restriktiven Rechten versehen:

sudo chmod 600 /var/lib/kubelet/config.yaml

Der Wert 600 erlaubt ausschließlich dem Eigentümer Lese- und Schreibzugriff. Nach jeder Anpassung wird kube-bench erneut gestartet, um die Wirksamkeit der Änderungen zu prüfen.

Schwachstellen- und RBAC-Analyse mit Trivy

Trivy ergänzt die Konfigurationsprüfung um CVE-basierte Schwachstellenanalysen. Die Installation erfolgt über:

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sudo sh

sudo mv ./bin/trivy /usr/local/bin/trivy

Der erste Befehl lädt ein Installationsskript und führt es aus. Anschließend wird das Binary in ein Verzeichnis verschoben, das im PATH enthalten ist. Der Cluster-Scan startet mit trivy k8s --report summary.

Trivy lädt beim ersten Lauf automatisch die aktuelle Vulnerability-Datenbank und analysiert sämtliche Kubernetes-Ressourcen. Tritt ein Verbindungsfehler auf, wird geprüft, ob die Umgebungsvariable KUBECONFIG korrekt gesetzt ist. Innerhalb des Minikube-Nodes kann sie mit export KUBECONFIG=/etc/kubernetes/admin.conf gesetzt werden. Falls auf dem Host eine falsche Variable aktiv ist, wird sie mit unset KUBECONFIG.

zurückgesetzt. Ein erfolgreicher Scan gliedert die Ergebnisse in Workload Assessment, Infra Assessment und RBAC Assessment. Schwachstellen in Container-Images erscheinen mit Einstufungen wie Critical oder High. RBAC-Einträge zeigen Rollen mit weitreichenden Berechtigungen, etwa ClusterRole-Definitionen mit administrativen Rechten.

Iterativer Prüfprozess

Ein strukturierter Prüfablauf beginnt mit kube-hunter zur Identifikation erreichbarer Dienste. Anschließend prüft kube-bench die Systemkonfiguration gegen die CIS-Vorgaben. Trivy analysiert Container-Images, Infrastrukturkomponenten und Berechtigungsstrukturen auf bekannte Schwachstellen.

Nach jeder Anpassung folgt ein erneuter Scan. Dieser iterative Ansatz reduziert offene Ports, korrigiert Dateirechte, deaktiviert unnötige API-Parameter und beschränkt überprivilegierte Rollen.

Selbst ein lokaler Minikube-Cluster zeigt ohne systematische Analyse zahlreiche Abweichungen. Die kombinierte Nutzung von kube-hunter, kube-bench und Trivy liefert eine nachvollziehbare, technisch fundierte Grundlage für Härtungsmaßnahmen in produktiven Kubernetes-Umgebungen.