OWASP Kubernetes Top 10 (2025), mise en pratique

Un capture-the-flag construit sur l'OWASP Kubernetes Top Ten — 2025. Vous avez été embauché pour réaliser un test d'intrusion chez NimbusMart, une entreprise de e-commerce fictive dont le cluster a grandi plus vite que sa sécurité. Dix défis, un par risque OWASP (plus un bonus) — exploitez chaque faiblesse, capturez le drapeau, puis appliquez le correctif et prouvez-le avec le vérificateur.

La bible complète (entreprise, services, namespaces, schéma des drapeaux) se trouve dans labs/NIMBUSMART.md.

Tout s'exécute localement sur kind. N'exécutez jamais les manifests vulnérables sur un vrai cluster.

Construit par @hac01.

Ce que cela couvre

Ce n'est pas un diaporama — c'est un cluster Kubernetes vulnérable par conception, fonctionnel, accompagné des outils pour l'attaquer, le corriger et vérifier le correctif. À travers les onze défis, vous mettez la main à la pâte sur :

• Sécurité des conteneurs et des nœuds — pods privilégiés, montages hostPath et évasion de nœud (K01).
• RBAC et autorisation — ClusterRoles avec wildcard, ServiceAccounts sur-scopés, et comment un token volé atteint tous les secrets (K02, K09).
• Gestion des secrets — clés API en dur dans les env/ConfigMaps et alternatives plus sûres (K03).
• Contrôle d'admission et politique — ce qui passe quand rien n'applique de règles à l'échelle du cluster, et comment Pod Security Admission / les moteurs de politique l'arrêtent (K04).
• Segmentation réseau — réseaux de pods plats vs. verrouillage NetworkPolicy (K05).
• Composants exposés — tableaux de bord et API internes publiés via NodePort (K06).
• Hygiène des composants du cluster — tokens par défaut, quotas manquants, versions obsolètes/vulnérables (K07).
• Mouvement latéral cluster-vers-cloud — un pod accédant au point de terminaison des métadonnées du nœud (IMDS) pour voler des identifiants cloud (K08).
• Authentification — accès API anonyme et tokens par défaut sur-montés (K09).
• Journalisation et surveillance — détection (ou non) d'exfiltration silencieuse de données, et pourquoi une piste d'audit est importante (K10).
• Chaîne d'approvisionnement — images :latest non fiables et mutables envoyées en production (bonus).

Pour chaque défi, vous obtenez :

• Un briefing de mission — le scénario NimbusMart, votre point d'accès et l'objectif.
• Un drapeau à capturer — accessible uniquement en réalisant l'exploit (sur le nœud, dans un autre namespace, sur le réseau). Soumettez-le dans l'application web ; le tableau de bord suit votre progression et vos points (localStorage du navigateur).
• Des indices progressifs plus une solution complète — d'abord des indices, puis la solution intégrale quand vous le souhaitez.
• Une vue d'ensemble détaillée — quelle est la faiblesse, comment les attaquants l'exploitent, impact, causes profondes.
• Un guide de défense — correctifs concrets et une liste de vérification des bonnes pratiques.
• Un vérificateur automatisé — un binaire Go qui scanne votre cluster et confirme, pour chaque risque, si le correctif tient.

Prérequis

Installez ces éléments avant de commencer. Le script d'installation vérifie les quatre premiers et échoue rapidement avec un message clair si l'un d'eux manque.

Les commandes brew sont pour macOS. Sous Linux, utilisez votre gestionnaire de paquets ou les instructions amont liées.

Démarrage rapide (recommandé) — tout dans un seul cluster

L'application web, un terminal dans le navigateur et le vérificateur peuvent tous s'exécuter dans le cluster kind. Une seule commande lance tout et affiche l'URL :

./setup.sh          # ou : make up
#   - crée le cluster kind, construit et charge les images, déploie, attend que tout soit prêt
#   - Application web : http://localhost:30090
#   - Terminal : le bouton 'Terminal' dans l'application web

./setup.sh (re)crée le cluster avec les bons mappages de ports, construit les deux images (nimbusmart-ctf-web, nimbusmart-ctf-terminal), les charge dans kind, et applique deploy/. La première exécution télécharge les images de base et prend environ 1 à 2 minutes.

./setup.sh            # nouveau cluster + plateforme complète (supprime tout ancien cluster 'owasp-labs')
./setup.sh --keep     # réutilise un cluster 'owasp-labs' existant s'il est présent

Ensuite, ouvrez http://localhost:30090, choisissez un défi, et utilisez le bouton Terminal dans le navigateur pour piloter le cluster.

Le pod du terminal s'exécute avec un ServiceAccount cluster-admin, donc le terminal dans le navigateur pilote ce même cluster — exécutez kubectl apply -f labs/... et owasp-k8s-checker --check kNN directement dedans.

Attention : le terminal dans le navigateur est effectivement cluster-admin via un WebSocket. Il est sûr uniquement parce qu'il est lié à votre cluster kind local et jetable sur localhost. N'exposez jamais les ports 30080/30090/30091 sur un réseau non fiable.

Démonter

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

Structure du dépôt

.
├── setup.sh         Bootstrap en une commande (cluster + images + déploiement)
├── Makefile         Cibles pratiques — exécutez `make help` pour les lister
├── web/             Application Next.js + React (thème blanc/violet) — l'interface utilisateur
├── labs/            Manifests K8s réels par risque (vulnerable.yaml + fixed.yaml + README)
│   ├── NIMBUSMART.md        Bible complète : entreprise, namespaces, schéma des drapeaux
│   └── kind-cluster.yaml    Configuration partagée du cluster local (mappages de ports)
├── deploy/          Manifests de la plateforme dans le cluster (web + terminal + RBAC) + build.sh
├── terminal-server/ Backend WebSocket pour le terminal dans le navigateur
└── checker/         Binaire Go qui valide un cluster par rapport au Top 10

Cibles make utiles (make help affiche tout) :

L'OWASP Kubernetes Top 10 — 2025

Chaque défi est une faiblesse réelle dans le cluster de NimbusMart — choisissez une cible, exploitez-la, capturez le drapeau, puis corrigez-la et prouvez le correctif avec le vérificateur.

Ce qui a changé par rapport à 2022 : l'autorisation (était RBAC) élargie ; secrets, réseau, authentification et journalisation réorganisés ; Composants trop exposés (K06) et Mouvement latéral cluster-vers-cloud (K08) ajoutés ; composants mal configurés + obsolètes fusionnés dans K07 ; Chaîne d'approvisionnement déplacée en défi bonus. Voir labs/NIMBUSMART.md pour la carte complète défi-vers-service-vers- faiblesse, difficulté et points (2000 sur 10 défis, +300 bonus).

Workflow manuel / développement (sans la plateforme dans le cluster)

Vous préférez exécuter l'interface utilisateur localement et piloter les labs depuis votre propre shell ? Vous pouvez assembler les pièces à la main.

1. Exécutez l'application web localement

cd web
npm install
npm run dev
# ouvrez http://localhost:3000       (ou : make web)

Le backend du terminal s'exécute séparément sur :30091 en utilisant votre ~/.kube/config :

make terminal-local

2. Créez un cluster de lab

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

3. Jouez un défi

Chaque défi a son propre README, mais le schéma est le même :

# certains défis préparent d'abord une cible (un fichier sur le nœud, un secret ops, ...)
kubectl apply -f labs/k01-insecure-workload/setup.yaml       # seulement si présent

# déployez la ressource vulnérable et exploitez-la pour capturer le drapeau
kubectl apply -f labs/k01-insecure-workload/vulnerable.yaml
# ...suivez le briefing de mission / les indices dans l'application web, récupérez FLAG{...}, soumettez-le...

# appliquez la version durcie et confirmez que le chemin du drapeau est fermé
kubectl delete -f labs/k01-insecure-workload/vulnerable.yaml
kubectl apply  -f labs/k01-insecure-workload/fixed.yaml

Réinitialisez tout entre les défis avec make clean-labs.

4. Vérifiez avec le vérificateur

cd checker
go run . --list            # affiche tous les vérificateurs
go run . --check k01       # exécute un seul vérificateur
go run . --all             # scanne tout le cluster
go run . --all --json      # lisible par machine (pour CI)
go run . --all -n apps     # limite à un namespace

Le vérificateur se termine avec un code non nul si une vérification échoue, il peut donc servir de passerelle pour CI.

Construisez un binaire autonome :

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

Comment le vérificateur correspond aux labs

Chaque checker/checks/kNN.go valide le même contrôle que le lab correspondant enseigne. Déployez le fixed.yaml, exécutez go run . --check kNN, et vous devriez voir PASS. Déployez le vulnerable.yaml et la même vérification rapporte les constatations spécifiques.

Sécurité : les manifests vulnérables sont délibérément exploitables. Utilisez uniquement un cluster kind/minikube local et jetable. Supprimez-le quand vous avez terminé : kind delete cluster --name owasp-labs.