Enseigner la sécurité Docker et Kubernetes : lab pratique et progression par niveau
Pourquoi la sécurité des conteneurs est devenue incontournable dans les cursus
Les conteneurs sont devenus le standard de déploiement des applications modernes. Docker et Kubernetes équipent aujourd'hui la quasi-totalité des environnements de production dans le secteur technologique, les banques, la santé et les services publics. Pour un étudiant en cybersécurité ou en DevSecOps qui entre sur le marché en 2026, ne pas savoir auditer, sécuriser et surveiller un environnement conteneurisé est un angle mort professionnel majeur.
Pourtant, la sécurité des conteneurs reste absente de nombreux cursus cyber. Les raisons sont compréhensibles : le sujet est à cheval entre sécurité, infrastructure et développement ; il évolue vite ; et monter un lab fonctionnel demande un minimum de préparation. Ce guide propose une structure pédagogique éprouvée pour intégrer la sécurité Docker et Kubernetes dans un module de 15 à 21 heures, avec des labs accessibles et une progression claire par niveau.
Cartographie des risques : ce que les étudiants doivent comprendre d'abord
Avant d'ouvrir un terminal, les étudiants ont besoin d'une cartographie claire des surfaces d'attaque spécifiques aux environnements conteneurisés. Le OWASP Docker Top 10 et le OWASP Kubernetes Top 10 sont les référentiels pédagogiques de base — accessibles, structurés, et directement applicables aux labs.
Les 5 menaces prioritaires à couvrir en cours
| Menace | Niveau | Technique illustrative |
|---|---|---|
| Image non vérifiée / vulnérable | L3+ | Analyse avec Trivy, scan CVE |
| Conteneur privilégié | L3+ | --privileged, escape vers l'hôte |
| Mauvaise gestion des secrets | L3+ | ENV variables en clair dans Dockerfile |
| Network policies absentes (K8s) | M1+ | Lateral movement entre pods |
| RBAC permissif (K8s) | M1+ | Privilege escalation via service account |
Ces cinq menaces couvrent les vulnérabilités les plus fréquemment documentées dans les audits réels. Elles forment le socle de tout module sécurité conteneurs, quel que soit le niveau.
La notion d'isolation : namespaces, cgroups, capabilities
La sécurité des conteneurs repose sur des primitives Linux souvent mal comprises : namespaces (isolation des processus, réseau, fichiers système), cgroups (limitation des ressources), et Linux capabilities (granularité des droits root). Expliquer ces mécanismes — et leurs limites — est indispensable pour que les étudiants comprennent pourquoi un conteneur mal configuré peut compromettre l'hôte.
Un exercice efficace : montrer qu'un conteneur lancé avec --privileged peut lire les fichiers de l'hôte et lancer des processus avec les droits root système. Cela rend tangible une vulnérabilité souvent abstraite.
Structure du module : 3 niveaux, 3 blocs
Bloc 1 — Sécurité Docker (6h, niveau L3/M1)
Prérequis : Linux de base, commandes Docker fondamentales.
Objectifs pédagogiques :
- Écrire un Dockerfile sécurisé (image minimale, utilisateur non-root, secrets exclus)
- Analyser une image avec Trivy et interpréter les résultats CVE
- Configurer un réseau Docker isolé et un volume avec droits appropriés
- Identifier les anti-patterns courants dans des Dockerfiles réels
Déroulé type — Séance 1 (3h) :
- 45 min : cours — surfaces d'attaque Docker, OWASP Docker Top 10
- 90 min : lab — audit de trois Dockerfiles volontairement vulnérables (image
latest, secrets en ENV, utilisateur root) - 45 min : débrief collectif + correction des Dockerfiles
Déroulé type — Séance 2 (3h) :
- 30 min : présentation de Trivy et interprétation d'un rapport CVE
- 90 min : lab — scan de 4 images Docker publiques (dont une image de base obsolète et une image applicative récente), rédaction d'un rapport de risque par binôme
- 60 min : conteneurs en production sans secrets en clair — Docker Secrets, variables d'environnement vs fichiers de configuration montés
Bloc 2 — Sécurité Kubernetes (9h, niveau M1)
Prérequis : avoir complété le Bloc 1, notions de YAML, comprendre kubectl de base.
Objectifs pédagogiques :
- Configurer des Network Policies pour isoler les namespaces
- Déployer des Pods avec des Security Contexts restrictifs
- Auditer un cluster avec kube-bench (CIS Benchmarks)
- Configurer un RBAC minimal selon le principe de moindre privilège
Lab fil rouge : le cluster Kubernetes mal configuré
Le lab s'articule autour d'un cluster Kubernetes pré-configuré avec 8 failles intentionnelles, réparties sur trois namespaces. Les étudiants doivent, en 3 séances :
- Découvrir et documenter toutes les failles (audit kube-bench + analyse manuelle)
- Corriger les failles par priorité (critique → haut → moyen)
- Valider les corrections et rédiger un rapport de remédiation
Ce format "attaque → audit → remédiation" reproduit le cycle réel d'un audit de sécurité cloud.
Outillage recommandé pour le lab Kubernetes :
| Outil | Rôle | Installation |
|---|---|---|
| Kind | Cluster Kubernetes local | go install sigs.k8s.io/kind@latest |
| kube-bench | Audit CIS Benchmarks | Binary GitHub releases |
| Trivy | Scan images + config K8s | Binary ou Docker image |
| Falco | Détection comportementale runtime | Helm chart |
| Polaris | Audit bonnes pratiques workloads | Binary ou admission webhook |
Bloc 3 — Supply chain et DevSecOps CI/CD (6h, niveau M2)
Prérequis : avoir complété les Blocs 1 et 2, notions de CI/CD (GitLab CI ou GitHub Actions).
Objectifs pédagogiques :
- Intégrer Trivy dans un pipeline CI pour bloquer les images vulnérables
- Comprendre Sigstore/Cosign pour la signature d'images
- Configurer un Admission Webhook (OPA Gatekeeper ou Kyverno) pour enforcer les politiques de sécurité
- Analyser une attaque de supply chain sur des images Docker malveillantes
Ce bloc connecte la sécurité des conteneurs à l'architecture sécurisée globale et aux enjeux de la chaîne d'approvisionnement logicielle — un sujet directement lié aux réglementations comme le Cyber Resilience Act.
Infrastructure lab : options on-prem et cloud pédagogique
L'une des questions les plus pratiques pour l'enseignant : comment monter le lab ?
Option 1 — Lab local sur poste étudiant (recommandé pour Bloc 1)
Pour la sécurité Docker, chaque étudiant peut travailler sur son propre poste :
- Linux ou macOS avec Docker Desktop
- Windows avec WSL2 + Docker Desktop
- VM Ubuntu 22.04 (4 vCPU, 8 Go RAM) si hétérogénéité des postes
Avantage : isolation totale, pas de dépendance réseau, reset facile.
Inconvénient : les étudiants sur Windows rencontrent parfois des problèmes de performance WSL2.
Option 2 — Cluster Kind partagé ou k3s par étudiant (Bloc 2)
Kind (Kubernetes in Docker) permet de déployer un cluster mono-nœud ou multi-nœuds dans des conteneurs Docker. C'est la solution la plus légère pour les TP Kubernetes :
kind create cluster --name lab-secu --config kind-config.yaml
kubectl cluster-info --context kind-lab-secu
Un cluster k3s sur une VM de 8 Go RAM est suffisant pour les exercices de RBAC, Network Policies et Security Contexts.
Option 3 — Cloud lab pédagogique (Bloc 2-3)
Pour les labs Kubernetes avancés (multi-nœuds, Falco, supply chain), un cluster cloud dédié offre plus de réalisme :
- Google Cloud Education et Azure for Students proposent des crédits gratuits pour les établissements.
- Un cluster GKE Autopilot ou AKS à 3 nœuds coûte moins de 15€/jour en lab (les nœuds peuvent être éteints entre les séances).
- L'avantage pédagogique : les étudiants s'exercent sur des environnements identiques à ceux de leurs futurs employeurs.
Méthodes d'évaluation adaptées
Projet d'audit (évaluation principale)
Le livrable le plus formateur est un rapport d'audit de sécurité d'un environnement Docker ou Kubernetes fourni par le formateur. Le rapport doit inclure :
- Méthodologie : outils utilisés, périmètre couvert
- Inventaire des vulnérabilités : criticité (CVSS ou OWASP), description, preuve (capture d'écran ou log)
- Plan de remédiation : correction priorisée, effort estimé
- Annexes : configurations corrigées (Dockerfile amélioré, Security Context YAML, Network Policy)
Ce format reproduit exactement le livrable d'un ingénieur sécurité en mission d'audit. Il s'évalue avec une rubric sur la complétude, la justesse technique, la qualité des recommandations et la clarté de la communication.
Challenge de détection (évaluation complémentaire)
Sur un cluster Kubernetes avec Falco activé, le formateur exécute une séquence de 5 actions suspectes (container escape tenté, accès à un secret, requête vers l'API server sans authentification). Les étudiants doivent :
- Identifier les alertes Falco déclenchées
- Mapper chaque alerte sur une technique MITRE ATT&CK
- Expliquer comment la vulnérabilité a été exploitée et comment la corriger
Ce qu'il faut retenir
- La sécurité des conteneurs couvre deux couches distinctes : la sécurité de l'image (Dockerfile, dépendances, secrets) et la sécurité de l'orchestration (RBAC, Network Policies, Security Contexts). Les enseigner séparément avant de les combiner évite la confusion.
- Trivy, kube-bench et Falco sont les trois outils de référence pour un lab pédagogique : gratuits, bien documentés, directement transférables en production.
- Kind suffit pour 80 % des labs Kubernetes pédagogiques. Il évite les frais cloud et la complexité d'un vrai cluster pour les exercices de niveau M1.
- Le rapport d'audit est l'évaluation la plus proche de la réalité professionnelle : elle développe simultanément les compétences techniques, la rigueur documentaire et la communication.
- La supply chain (Bloc 3) doit être abordée en M2 : c'est un sujet d'actualité réglementaire (Cyber Resilience Act, SBOM) qui différencie les profils techniques avancés sur le marché.
Vous souhaitez intégrer un module sécurité des conteneurs dans votre programme ?
Découvrez des formateurs DevSecOps et sécurité cloud sélectionnés sur Cyber Teachers pour leur expérience terrain et leur maîtrise pédagogique des environnements conteneurisés.