OWASP Kubernetes Top 10 (2025), esercitazione pratica

Una caccia alla bandiera (capture-the-flag) basata sul OWASP Kubernetes Top 10 — 2025. Sei stato assunto per fare red-teaming su NimbusMart, un'azienda fittizia di e-commerce il cui cluster è cresciuto più velocemente della sua sicurezza. Dieci sfide, una per rischio OWASP (più un bonus) — sfrutta ogni debolezza, cattura la bandiera, poi applica la correzione e verificala con il checker.

La bibbia del mondo (azienda, servizi, namespace, schema delle bandiere) si trova in labs/NIMBUSMART.md.

Tutto gira localmente su kind. Non eseguire mai i manifest vulnerabili su un cluster reale.

Creato da @hac01.

Cosa copre

Questo non è un set di diapositive — è un cluster Kubernetes funzionante e vulnerabile di progettazione, più gli strumenti per attaccarlo, correggerlo e verificare la correzione. Attraverso le undici sfide acquisisci esperienza pratica con:

• Sicurezza di container e nodi — pod privilegiati, montaggi hostPath e fuga dal nodo (K01).
• RBAC e autorizzazione — ClusterRole con wildcard, ServiceAccounts con ambito eccessivo, e come un singolo token rubato può accedere a tutti i segreti (K02, K09).
• Gestione dei segreti — chiavi API hardcoded in env/ConfigMap e alternative più sicure (K03).
• Controllo degli admission e policy — cosa passa quando nessuna regola è applicata a livello di cluster, e come Pod Security Admission / motori di policy lo bloccano (K04).
• Segmentazione di rete — reti piatte di pod vs. blocco con NetworkPolicy (K05).
• Componenti esposti — dashboard e API interni pubblicati tramite NodePort (K06).
• Igiene dei componenti del cluster — token predefiniti, quote mancanti, versioni obsolete/vulnerabili (K07).
• Movimento laterale dal cluster al cloud — un pod che raggiunge l'endpoint metadata del nodo (IMDS) per rubare credenziali cloud (K08).
• Autenticazione — accesso anonimo all'API e token predefiniti montati in eccesso (K09).
• Logging e monitoraggio — rilevare (o non rilevare) l'esfiltrazione silenziosa di dati, e perché un audit trail è importante (K10).
• Supply chain — immagini :latest non fidate e mutabili spedite in produzione (bonus).

Per ogni sfida ottieni:

• Un briefing di missione — lo scenario NimbusMart, il tuo punto di appoggio e l'obiettivo.
• Una bandiera da catturare — raggiungibile solo eseguendo lo sfruttamento (sul nodo, in un altro namespace, attraverso la rete). Inviala nell'app web; la classifica tiene traccia dei tuoi progressi e punti (localStorage del browser).
• Suggerimenti progressivi più una soluzione dettagliata (spoiler) — prima degli indizi, poi la soluzione completa quando vuoi.
• Una panoramica approfondita — qual è la debolezza, come gli attaccanti ne abusano, impatto, cause principali.
• Una guida alla difesa — patch concrete e una checklist di buone pratiche.
• Un checker automatico — un binario Go che scansiona il tuo cluster e conferma, per ogni rischio, se la correzione è valida.

Prerequisiti

Installa questi prima di iniziare. Lo script di setup controlla i primi quattro e fallisce rapidamente con un messaggio chiaro se mancano.

I comandi brew sono per macOS. Su Linux usa il tuo gestore di pacchetti o le istruzioni upstream collegate.

Avvio rapido (consigliato) — tutto all'interno di un cluster

L'app web, un terminale nel browser e il checker possono essere eseguiti all'interno del cluster kind. Un comando avvia tutto e stampa l'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 (ri)crea il cluster con i giusti mapping di porta, costruisce le due immagini (nimbusmart-ctf-web, nimbusmart-ctf-terminal), le carica in kind e applica deploy/. Al primo avvio scarica le immagini di base e impiega circa 1-2 minuti.

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

Poi apri http://localhost:30090, scegli una sfida e usa il pulsante Terminale nel browser per guidare il cluster.

Il pod terminale viene eseguito come ServiceAccount cluster-admin, quindi il terminale nel browser guida esattamente questo cluster — esegui kubectl apply -f labs/... e owasp-k8s-checker --check kNN direttamente lì.

Avvertenza: il terminale nel browser è di fatto cluster-admin su un WebSocket. È sicuro solo perché è legato al tuo cluster kind locale e usa e getta su localhost. Non esporre mai le porte 30080/30090/30091 a una rete non fidata.

Smantellamento

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

Struttura del repository

.
├── setup.sh         Bootstrap con un comando (cluster + immagini + deploy)
├── Makefile         Target di comodità — esegui `make help` per elencarli
├── web/             App Next.js + React (tema bianco/viola) — l'interfaccia utente
├── labs/            Manifest K8s reali per rischio (vulnerable.yaml + fixed.yaml + README)
│   ├── NIMBUSMART.md        Bibbia del mondo: azienda, namespace, schema delle bandiere
│   └── kind-cluster.yaml    Configurazione cluster locale condivisa (mapping di porta)
├── deploy/          Manifest della piattaforma in-cluster (web + terminal + RBAC) + build.sh
├── terminal-server/ Backend WebSocket per il terminale nel browser
└── checker/         Binario Go che convalida un cluster rispetto alla Top 10

Target make utili (make help mostra tutti):

L'OWASP Kubernetes Top 10 — 2025

Ogni sfida è una vera debolezza nel cluster di NimbusMart — scegli un bersaglio, sfruttalo, cattura la bandiera, poi correggilo e dimostra la correzione con il checker.

Cosa è cambiato rispetto al 2022: l'autorizzazione (era RBAC) è stata ampliata; riordinati segreti, rete, autenticazione e logging; Componenti eccessivamente esposti (K06) e Movimento laterale dal cluster al cloud (K08) aggiunti; componenti malconfigurati e obsoleti unificati in K07; Supply Chain spostata in una sfida bonus. Vedi labs/NIMBUSMART.md per la mappa completa sfida-servizio-debolezza, difficoltà e punti (2000 in 10 sfide, +300 bonus).

Workflow manuale / di sviluppo (senza la piattaforma in-cluster)

Preferisci eseguire l'interfaccia utente localmente e guidare i lab dal tuo terminale? Puoi collegare i pezzi manualmente.

1. Esegui l'app web localmente

cd web
npm install
npm run dev
# open http://localhost:3000       (or: make web)

Il backend del terminale viene eseguito separatamente su :30091 usando il tuo ~/.kube/config:

make terminal-local

2. Crea un cluster lab

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

3. Gioca una sfida

Ogni sfida ha il proprio README, ma lo schema è lo stesso:

# some challenges seed a target first (a node file, an ops secret, ...)
kubectl apply -f labs/k01-insecure-workload/setup.yaml       # only if present

# deploy the vulnerable resource and exploit it to capture the flag
kubectl apply -f labs/k01-insecure-workload/vulnerable.yaml
# ...follow the mission briefing / hints in the web app, grab FLAG{...}, submit it...

# apply the hardened version and confirm the flag path is closed
kubectl delete -f labs/k01-insecure-workload/vulnerable.yaml
kubectl apply  -f labs/k01-insecure-workload/fixed.yaml

Ripristina tutto tra le sfide con make clean-labs.

4. Verifica con il checker

cd checker
go run . --list            # show all checks
go run . --check k01       # run a single check
go run . --all             # scan the whole cluster
go run . --all --json      # machine-readable (for CI)
go run . --all -n apps     # scope to a namespace

Il checker esce con valore diverso da zero se un qualsiasi check fallisce, quindi può essere usato come gate CI.

Costruisci un binario autonomo:

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

Come il checker si mappa ai lab

Ogni checker/checks/kNN.go convalida lo stesso controllo insegnato dal lab corrispondente. Esegui il deploy di fixed.yaml, esegui go run . --check kNN, e dovresti vedere PASS. Esegui il deploy di vulnerable.yaml e lo stesso check riporta i reperti specifici.

Sicurezza: i manifest vulnerabili sono intenzionalmente sfruttabili. Usa solo un cluster kind/minikube locale e usa e getta. Eliminalo quando hai finito: kind delete cluster --name owasp-labs.