OWASP Kubernetes Top 10 (2025), praktisch

Ein Capture-the-Flag, aufbauend auf dem OWASP Kubernetes Top 10 — 2025. Du wurdest angeheuert, um NimbusMart zu red-teamen, ein fiktives E-Commerce-Unternehmen, dessen Cluster schneller wuchs als seine Sicherheit. Zehn Herausforderungen, eine pro OWASP-Risiko (plus ein Bonus) – nutze jede Schwachstelle aus, erobere die Flagge, wende dann die Korrektur an und beweise sie mit dem Checker.

Die Weltbibel (Unternehmen, Dienste, Namespaces, Flag-Schema) befindet sich in labs/NIMBUSMART.md.

Alles läuft lokal auf kind. Führe die verwundbaren Manifeste niemals gegen einen echten Cluster aus.

Erstellt von @hac01.

Was dies abdeckt

Dies ist keine Folienpräsentation – es ist ein funktionierender, von Natur aus verwundbarer Kubernetes-Cluster plus die Werkzeuge, um ihn anzugreifen, zu reparieren und die Reparatur zu überprüfen. In den elf Herausforderungen bekommst du praktische Erfahrung mit:

• Container- und Node-Sicherheit – privilegierte Pods, hostPath-Mounts und Node- Breakout (K01).
• RBAC und Autorisierung – Wildcard-ClusterRoles, übermäßig weitreichende ServiceAccounts, und wie ein gestohlener Token jedes Secret erreicht (K02, K09).
• Secrets-Management – hartcodierte API-Schlüssel in Env/ConfigMaps und sicherere Alternativen (K03).
• Admission Control & Policy – was durchrutscht, wenn nichts clusterweit Regeln durchsetzt, und wie Pod Security Admission / Policy Engines dies stoppen (K04).
• Netzwerksegmentierung – flache Pod-Netzwerke vs. NetworkPolicy-Abschottung (K05).
• Exponierte Komponenten – interne Dashboards und APIs, die über NodePort veröffentlicht werden (K06).
• Cluster-Komponenten-Hygiene – Standard-Tokens, fehlende Quotas, veraltete/verwundbare Versionen (K07).
• Cluster-zu-Cloud-Lateralbewegung – ein Pod, der den Node-Metadaten-Endpoint (IMDS) erreicht, um Cloud-Anmeldeinformationen zu stehlen (K08).
• Authentifizierung – anonymer API-Zugriff und übermäßig gemountete Standard-Tokens (K09).
• Logging & Monitoring – Erkennung (oder Nichterkennung) von stiller Datenexfiltration, und warum ein Audit-Trail wichtig ist (K10).
• Supply Chain – unvertraute, veränderbare :latest-Images, die in Produktion ausgeliefert werden (Bonus).

Für jede Herausforderung erhältst du:

• Ein Missionsbriefing – das NimbusMart-Szenario, dein Zugang und das Ziel.
• Eine zu erobernde Flagge – nur erreichbar, indem du den Exploit ausführst (auf dem Node, in einem anderen Namespace, über das Netzwerk). Reiche sie in der Web-App ein; die Bestenliste verfolgt deinen Fortschritt und die Punkte (browser localStorage).
• Progressive Hinweise plus eine Spoiler-Komplettlösung – zuerst kleine Hinweise, dann die vollständige Lösung, wenn du sie möchtest.
• Eine tiefgehende Übersicht – was die Schwachstelle ist, wie Angreifer sie missbrauchen, Auswirkung, Ursachen.
• Einen Abwehrleitfaden – konkrete Patches und eine Best-Practices-Checkliste.
• Einen automatisierten Checker – ein Go-Binary, das deinen Cluster scannt und für jedes Risiko bestätigt, ob die Korrektur hält.

Voraussetzungen

Installiere diese, bevor du beginnst. Das Setup-Skript prüft die ersten vier und bricht schnell mit einer klaren Meldung ab, falls etwas fehlt.

brew-Befehle sind für macOS. Unter Linux verwende deinen Paketmanager oder die verlinkten Originalanleitungen.

Schnellstart (empfohlen) – alles innerhalb eines Clusters

Die Web-App, ein In-Browser-Terminal und der Checker können alle innerhalb des kind- Clusters laufen. Ein Befehl startet alles und gibt die URL aus:

./setup.sh          # oder: make up
#   - erstellt den kind-Cluster, baut Images und lädt sie, stellt bereit, wartet auf Bereitschaft
#   - Web-App:  http://localhost:30090
#   - Terminal: der 'Terminal'-Button in der Web-App

./setup.sh erstellt den Cluster (neu) mit den richtigen Portzuordnungen, baut die beiden Images (nimbusmart-ctf-web, nimbusmart-ctf-terminal), lädt sie in kind und wendet deploy/ an. Erster Durchlauf zieht Basis-Images und dauert ~1-2 Minuten.

./setup.sh            # frischer Cluster + vollständige Plattform (löscht alten 'owasp-labs'-Cluster)
./setup.sh --keep     # vorhandenen 'owasp-labs'-Cluster wiederverwenden, falls vorhanden

Öffne dann http://localhost:30090, wähle eine Herausforderung und verwende den Terminal- Button im Browser, um den Cluster zu steuern.

Der Terminal-Pod läuft als cluster-admin-ServiceAccount, so dass das Terminal im Browser genau diesen Cluster steuert – führe kubectl apply -f labs/... und owasp-k8s-checker --check kNN direkt dort aus.

Warnung: Das In-Browser-Terminal hat effektiv cluster-admin über ein WebSocket. Es ist nur sicher, weil es an deinen lokalen, wegwerfbaren kind-Cluster auf localhost gebunden ist. Setze die Ports 30080/30090/30091 niemals einem unsicheren Netzwerk aus.

Abbau

kind delete cluster --name owasp-labs      # oder: make cluster-down

Repository-Struktur

.
├── setup.sh         Ein-Befehl-Bootstrap (Cluster + Images + Deploy)
├── Makefile         Komfortziele – führe `make help` aus, um sie anzuzeigen
├── web/             Next.js + React-App (weiß/lila Thema) – die UI
├── labs/            Echte K8s-Manifeste pro Risiko (vulnerable.yaml + fixed.yaml + README)
│   ├── NIMBUSMART.md        Weltbibel: Unternehmen, Namespaces, Flag-Schema
│   └── kind-cluster.yaml    Gemeinsame lokale Cluster-Konfiguration (Portzuordnungen)
├── deploy/          Manifeste für In-Cluster-Plattform (Web + Terminal + RBAC) + build.sh
├── terminal-server/ WebSocket-Backend für das In-Browser-Terminal
└── checker/         Go-Binary, das einen Cluster gegen die Top 10 validiert

Nützliche make-Ziele (make help zeigt alle):

Die OWASP Kubernetes Top 10 – 2025

Jede Herausforderung ist eine echte Schwachstelle in NimbusMart's Cluster – wähle ein Ziel, nutze es aus, erobere die Flagge, patche sie dann und beweise die Korrektur mit dem Checker.

Was sich von 2022 geändert hat: Autorisierung (war RBAC) erweitert; Secrets, Netzwerk, Authn und Logging neu angeordnet; Übermäßig exponierte Komponenten (K06) und Cluster-zu-Cloud Lateralbewegung (K08) hinzugefügt; Fehlkonfigurierte + Veraltete Komponenten in K07 zusammengeführt; Supply Chain als Bonus-Herausforderung verschoben. Siehe labs/NIMBUSMART.md für die vollständige Zuordnung von Herausforderung zu Dienst zu Schwachstelle, Schwierigkeitsgrad und Punkte (2000 über 10 Herausforderungen, +300 Bonus).

Manueller / Entwickler-Workflow (ohne die In-Cluster-Plattform)

Bevorzugst du, die UI lokal auszuführen und Labs von deiner eigenen Shell aus zu steuern? Du kannst die Teile von Hand verbinden.

1. Führe die Web-App lokal aus

cd web
npm install
npm run dev
# öffne http://localhost:3000       (oder: make web)

Das Terminal-Backend läuft separat auf :30091 und verwendet deine ~/.kube/config:

make terminal-local

2. Erstelle einen Lab-Cluster

kind create cluster --config labs/kind-cluster.yaml    # oder: make cluster
kubectl config use-context kind-owasp-labs

3. Spiele eine Herausforderung

Jede Herausforderung hat ihr eigenes README, aber das Muster ist dasselbe:

# einige Herausforderungen seeden zuerst ein Ziel (eine Node-Datei, ein Ops-Secret, ...)
kubectl apply -f labs/k01-insecure-workload/setup.yaml       # nur wenn vorhanden

# setze die verwundbare Ressource ein und nutze sie aus, um die Flagge zu erobern
kubectl apply -f labs/k01-insecure-workload/vulnerable.yaml
# ...folge dem Missionsbriefing / den Hinweisen in der Web-App, schnapp dir FLAG{...}, reiche es ein...

# wende die gehärtete Version an und bestätige, dass der Flaggenweg geschlossen ist
kubectl delete -f labs/k01-insecure-workload/vulnerable.yaml
kubectl apply  -f labs/k01-insecure-workload/fixed.yaml

Setze alles zwischen den Herausforderungen mit make clean-labs zurück.

4. Überprüfe mit dem Checker

cd checker
go run . --list            # alle Checks anzeigen
go run . --check k01       # einen einzelnen Check ausführen
go run . --all             # den gesamten Cluster scannen
go run . --all --json      # maschinenlesbar (für CI)
go run . --all -n apps     # auf einen Namespace beschränken

Der Checker beendet sich mit einem Fehlercode ungleich Null, wenn ein Check fehlschlägt, sodass er CI blockieren kann.

Erstelle ein eigenständiges Binary:

cd checker
go build -o owasp-k8s-checker .    # oder: make checker
./owasp-k8s-checker --all

Wie der Checker zu den Labs passt

Jedes checker/checks/kNN.go validiert dieselbe Kontrolle, die das passende Lab lehrt. Setze das fixed.yaml ein, führe go run . --check kNN aus, und du solltest PASS sehen. Setze das vulnerable.yaml ein, und derselbe Check meldet die spezifischen Funde.

Sicherheit: Die verwundbaren Manifeste sind absichtlich ausnutzbar. Verwende nur einen lokalen, wegwerfbaren kind/minikube-Cluster. Lösche ihn, wenn du fertig bist: kind delete cluster --name owasp-labs.