OWASP Kubernetes Top 10 (2025), hands-on

A capture-the-flag built on the OWASP Kubernetes Top 10 — 2025. You've been hired to red-team NimbusMart, a fictional e-commerce company whose cluster grew faster than its security. Ten challenges, one per OWASP risk (plus a bonus) — exploit each weakness, capture the flag, then apply the fix and prove it with the checker.

The world bible (company, services, namespaces, flag scheme) lives in labs/NIMBUSMART.md.

Everything runs locally on kind. Never run the vulnerable manifests against a real cluster.

Built by @hac01.

---

What this covers

This isn't a slide deck — it's a working, vulnerable-by-design Kubernetes cluster plus the tooling to attack it, fix it, and verify the fix. Across the eleven challenges you get hands-on with:

• Container & node security — privileged pods, hostPath mounts, and node breakout (K01).
• RBAC and authorization — wildcard ClusterRoles, over-scoped ServiceAccounts, and how one stolen token reaches every secret (K02, K09).
• Secrets management — hardcoded API keys in env/ConfigMaps and safer alternatives (K03).
• Admission control & policy — what slips through when nothing enforces rules cluster-wide, and how Pod Security Admission / policy engines stop it (K04).
• Network segmentation — flat pod networks vs. NetworkPolicy lockdown (K05).
• Exposed components — internal dashboards and APIs published via NodePort (K06).
• Cluster component hygiene — default tokens, missing quotas, stale/vulnerable versions (K07).
• Cluster-to-cloud lateral movement — a pod reaching the node metadata (IMDS) endpoint to steal cloud credentials (K08).
• Authentication — anonymous API access and over-mounted default tokens (K09).
• Logging & monitoring — detecting (or failing to detect) silent data exfil, and why an audit trail matters (K10).
• Supply chain — untrusted, mutable :latest images shipped to prod (bonus).

For every challenge you get:

• A mission briefing — the NimbusMart scenario, your foothold, and the objective.
• A flag to capture — reachable only by performing the exploit (on the node, in another namespace, over the network). Submit it in the web app; the scoreboard tracks your progress and points (browser localStorage).
• Progressive hints plus a spoiler walkthrough — nudges first, full solution when you want it.
• A deep-dive overview — what the weakness is, how attackers abuse it, impact, root causes.
• A defense guide — concrete patches and a best-practices checklist.
• An automated checker — a Go binary that scans your cluster and confirms, per risk, whether the fix holds.

---

Prerequisites

Install these before you start. The setup script checks for the first four and fails fast with a clear message if any are missing.

Tool	Why	Install
Docker	Runs the kind cluster and builds images. Must be running.	Docker Desktop / Engine
kind	Local Kubernetes cluster in Docker.	brew install kind
kubectl	Talk to the cluster.	brew install kubectl
Go 1.21+	Builds and runs the checker binary.	brew install go
Node.js 18+	Only for running the web app locally (make web). Not needed for the one-command in-cluster setup.	brew install node

brew commands are for macOS. On Linux use your package manager or the linked upstream instructions.

---

Quick start (recommended) — everything inside one cluster

The web app, an in-browser terminal, and the checker can all run inside the kind cluster. One command spins up everything and prints the URL:

./setup.sh          # or: make up
#   - creates the kind cluster, builds and loads images, deploys, waits for ready
#   - Web app:  http://localhost:30090
#   - Terminal: the 'Terminal' button in the web app

./setup.sh (re)creates the cluster with the right port mappings, builds the two images (nimbusmart-ctf-web, nimbusmart-ctf-terminal), loads them into kind, and applies deploy/. First run pulls base images and takes ~1-2 minutes.

./setup.sh            # fresh cluster + full platform (deletes any old 'owasp-labs' cluster)
./setup.sh --keep     # reuse an existing 'owasp-labs' cluster if present

Then open http://localhost:30090, pick a challenge, and use the Terminal button in the browser to drive the cluster.

The terminal pod runs as a cluster-admin ServiceAccount, so the terminal in the browser drives this very cluster — run kubectl apply -f labs/... and owasp-k8s-checker --check kNN right there.

Warning: the in-browser terminal is effectively cluster-admin over a WebSocket. It is safe only because it is bound to your local, disposable kind cluster on localhost. Never expose ports 30080/30090/30091 to an untrusted network.

Tear down

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

---

Repository layout

.
├── setup.sh         One-command bootstrap (cluster + images + deploy)
├── Makefile         Convenience targets — run `make help` to list them
├── web/             Next.js + React app (white/purple theme) — the UI
├── labs/            Real K8s manifests per risk (vulnerable.yaml + fixed.yaml + README)
│   ├── NIMBUSMART.md        World bible: company, namespaces, flag scheme
│   └── kind-cluster.yaml    Shared local cluster config (port mappings)
├── deploy/          In-cluster platform manifests (web + terminal + RBAC) + build.sh
├── terminal-server/ WebSocket backend for the in-browser terminal
└── checker/         Go binary that validates a cluster against the Top 10

Useful make targets (make help shows all):

Target	What it does
make up	One shot: cluster + images + deploy (runs setup.sh)
make web	Run the web app in dev mode on :3000
make cluster / make cluster-down	Create / delete the local kind cluster
make scan	Run every checker against the current cluster
make check ID=k01	Run a single check
make clean-labs	Delete all lab resources (reset between challenges)

---

The OWASP Kubernetes Top 10 — 2025

Each challenge is a real weakness in NimbusMart's cluster — pick a target, exploit it, capture the flag, then patch it and prove the fix with the checker.