Cyber Security Academy · Lektion

Kubernetes-Bedrohungsmodell

Wo Cluster angegriffen werden

Lektion 1 von 413 Schritte

Kubernetes-Bedrohungsmodell ist eine kostenlose Cyber Security Academy-Lektion auf CoddyKit. Dies ist Lektion 1 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Cyber Security Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Cyber Security Academy-Kurs umfasst insgesamt 4 Lektionen.

Warum Kubernetes ein Ziel ist

Kubernetes orchestriert Container über viele Nodes hinweg. Es zentralisiert Secrets, Netzwerke und Rechenleistung. Wird der Cluster kompromittiert, kann dies die Kompromittierung jeder darin ausgeführten Workload bedeuten.

Ein API-Server steuert den gesamten Cluster.
Nodes führen die Workloads vieler Mandanten nebeneinander aus.
Fehlkonfigurationen treten weitaus häufiger auf als CVEs in den Kernkomponenten.

Zusammenfassung der Clusterarchitektur

Für eine Bedrohungsmodellierung müssen Sie die Komponenten kennen.

Control plane: API-Server, etcd, Scheduler, Controller-Manager.
Nodes: kubelet, Container-Runtime, kube-proxy, Pods.
etcd speichert den gesamten Clusterzustand und alle Secrets.

Der API-Server ist der einzige Einstiegspunkt; etcd ist das Kronjuwel der Daten.

Die Karte der Angriffsfläche

Angriffe zielen auf verschiedene Ebenen.

Extern: offengelegter API-Server, Dashboards, Ingress.
Workload: eine kompromittierte Anwendung innerhalb eines Pods.
Identität: Service-Account-Token und RBAC.
Node: kubelet-API, Container-Escape auf den Host.
Supply Chain: bösartige Images und Abhängigkeiten.

Offengelegte Control Plane

Ein aus dem Internet erreichbarer API-Server oder ein Kubelet mit schwacher Authentifizierung ist ein direkter Weg zur Übernahme des Clusters.

Anonymer Zugriff ist auf dem API-Server aktiviert.
Die Lese-/Schreib-API des Kubelets (Port 10250) ist offengelegt.
Ein offenes Kubernetes-Dashboard mit Admin-Bindung.

# Probe an exposed kubelet for running pods
curl -sk https://NODE_IP:10250/pods

# Test anonymous API access
kubectl --insecure-skip-tls-verify --server https://API:6443 get pods

Der Ausgangspunkt im Pod

Der häufigste Ausgangspunkt ist eine RCE in einer Anwendung, die in einem Pod ausgeführt wird. Im Inneren eines Pods finden Angreifer:

Ein eingebundenes service account token unter /var/run/secrets/....
Erreichbare interne Dienste (keine Netzwerkrichtlinie).
Den API-Server, der häufig als kubernetes.default aufgelöst werden kann.

# From inside a pod: read the mounted SA token
cat /var/run/secrets/kubernetes.io/serviceaccount/token

# Use it against the API
curl -sk -H "Authorization: Bearer $(cat .../token)" https://kubernetes.default/api/v1/namespaces/default/pods

Container-Escape

Das Ausbrechen aus einem Container auf den Node ermöglicht den Zugriff auf alle Workloads dieses Hosts.

Privileged-Container können auf Hostgeräte zugreifen und ausbrechen.
Mounts mit hostPID/hostNetwork/hostPath vergrößern den Schadensradius.
Ein eingebundener Docker-Socket ermöglicht das Starten eines privilegierten Containers.
Gefährliche Capabilities (SYS_ADMIN) ermöglichen den Ausbruch.

# A privileged pod can mount the host filesystem and chroot to it
mount /dev/sda1 /mnt && chroot /mnt sh

etcd: Der Secret-Speicher

etcd enthält den gesamten Clusterzustand einschließlich der Secrets, die standardmäßig lediglich base64-kodiert sind. Direkter Zugriff auf etcd (in fehlkonfigurierten Clustern oft ohne Authentifizierung) legt alle Secrets offen.

# Read all secrets from an exposed etcd
etcdctl --endpoints=https://NODE:2379 get / --prefix --keys-only

Laterale Bewegung in Clustern

Sobald sie sich im Cluster befinden, bewegen sich Angreifer mithilfe der Clusteridentität und der Netzwerke weiter.

Ein zu freizügiger Service Account ermöglicht das Erstellen privilegierter Pods.
Flache Pod-Netzwerke (keine NetworkPolicy) erlauben den Zugriff auf jeden Dienst.
Das Einplanen eines Pods auf einem Ziel-Node ermöglicht die Kompromittierung des Nodes.

Cloud-Metadaten aus Pods

In verwalteten Clustern (EKS/GKE/AKS) können Pods möglicherweise den Cloud-Metadatendienst des Nodes erreichen und die IAM-/Rollen-Anmeldedaten des Nodes stehlen. Dadurch kann eine Clusterkompromittierung auf das Cloud-Konto ausgeweitet werden.

Zu den Schutzmaßnahmen gehören IMDSv2, das Blockieren von Metadaten auf Netzwerkebene und die Verwendung von Workload Identity anstelle von Node-Rollen.

Mit Tools abbilden

Tools automatisieren die Bedrohungsanalyse von Clustern.

kube-hunter sucht nach offengelegten Komponenten.
kube-bench überprüft die Konformität mit dem CIS-Benchmark.
Peirates / kubeletctl testen Angriffspfade innerhalb des Clusters.

# Assess attack surface
kube-hunter --remote API_IP

# CIS benchmark check on a node
kube-bench run --targets node

Defensive Prioritäten

Das Bedrohungsmodell weist auf klare defensive Prioritäten hin: Sichern Sie den API-Server ab, schränken Sie RBAC ein, isolieren Sie Pods, härten Sie Nodes und sichern Sie die Supply Chain. Die nächsten Lektionen gehen auf jeden dieser Punkte näher ein.

Greifen Sie beim Testen nur Cluster an, für die Sie autorisiert sind, und vermeiden Sie die Destabilisierung von Produktions-Workloads.

Schnelltest

Überprüfen Sie Ihre Grundlagen zur Bedrohungsmodellierung von Kubernetes.

Beantworte es in der interaktiven Lektion

Zusammenfassung

Sie haben abgebildet, an welchen Stellen Kubernetes-Cluster angegriffen werden.

Der API-Server und etcd sind die zentralen und wertvollsten Ziele.
Ausgangspunkte in Pods nutzen eingebundene SA-Token und flache Netzwerke.
Privilegierte Pods und hostPath-Pods ermöglichen den Container-Escape auf den Node.
Bei verwalteten Clustern besteht das Risiko eines Cloud-Pivots über Metadaten.

Als Nächstes: RBAC und Service Accounts.

Kostenlos starten

Lerne Cyber Security Academy mit einem KI-Tutor — kostenlos

Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.

Kurse: 76
Lektionen: 303

Kostenlos lernen Den vollständigen Kurs ansehen

Häufig gestellte Fragen

Ist die Lektion „Kubernetes-Bedrohungsmodell“ kostenlos?

Ja — der vollständige Text von „Kubernetes-Bedrohungsmodell“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Cyber Security Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Cyber Security Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Kubernetes-Bedrohungsmodell“?

Wo Cluster angegriffen werden Du übst Cyber Security Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Cyber Security Academy zu starten?

Keine Vorkenntnisse erforderlich. Cyber Security Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 1 von 4.

Wie lange dauert die Lektion „Kubernetes-Bedrohungsmodell“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Cyber Security Academy-Lektion Code schreiben und ausführen?

Ja. Jede Cyber Security Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

← Zurück zu Cyber Security Academy