Entraînez-vous à sécuriser des hôtes Linux et des workloads Docker en cours d’exécution avec 30 laboratoires de défi DevSecOps. Au fil de six étapes progressives, vous inspecterez l’état réel, identifierez une exposition ou une frontière de privilèges dangereuse, appliquerez une correction ciblée et prouverez que l’application protégée fonctionne toujours.
Ce parcours intermédiaire privilégie le durcissement opérationnel plutôt que la théorie ou des instructions pas à pas. La partie Linux traite des services, contenus web, permissions, identités, secrets et automatisations privilégiées ; la partie Docker va de l’audit runtime au moindre privilège, à l’isolation Compose, à l’hygiène des images et au nettoyage d’incidents.
Ce que vous apprendrez
À l’issue du cours, vous saurez :
- Auditer sockets d’écoute, liaisons hôte, comportement des répertoires web et artefacts exposés afin d’établir une référence Linux fiable.
- Resserrer les permissions des secrets, uploads, fichiers d’environnement et logs sans rompre les accès légitimes des services.
- Faire fonctionner les services hors de root, attribuer des identités dédiées et préserver les limites de propriété requises.
- Retirer les identifiants des scripts et processus, restreindre sudo et sécuriser la résolution des commandes et les chemins cron root.
- Inspecter les images, ports publiés, utilisateurs, montages, variables, volumes et réseaux réels de Docker et Compose.
- Réduire les privilèges avec des montages en lecture seule, des utilisateurs non-root et la suppression du mode privileged, du socket Docker et des secrets trop larges.
- Segmenter les réseaux Compose, éliminer les tokens runtime et build, épingler une image de base et retirer les overrides temporaires d’incident.
- Valider chaque durcissement par des contrôles de processus, permissions, HTTP, conteneurs, historique d’image et connectivité.
À qui s’adresse ce cours
Ce cours s’adresse aux personnes possédant les bases de Linux et Docker qui veulent corriger des dérives de sécurité opérationnelle réalistes. Il convient aux futurs spécialistes DevSecOps, plateforme ou opérations qui doivent préserver le comportement applicatif tout en réduisant exposition et privilèges.
Prérequis : Vous devez savoir naviguer sous Linux, modifier des fichiers de configuration et shell, interpréter permissions et processus, utiliser sudo et exécuter les commandes de base de Docker et Docker Compose. Les défis donnent exigences et indices, mais n’enseignent pas ces fondations depuis zéro.
Environnement d’apprentissage : Les 15 premiers défis utilisent des terminaux Ubuntu 22.04 fournis ; les 15 suivants utilisent des environnements Ubuntu 22.04 compatibles Docker, avec applications, images, scripts et stacks Compose préparés. Toutes les cibles sont locales et aucun cloud, registre ou système de production externe n’est utilisé.
Questions fréquentes
Est-ce un cours de sécurité guidé ou un parcours de défis ?
C’est un parcours de défis. Chaque laboratoire fixe scénario, état cible, exigences, indices et validation, mais vous décidez quelles preuves examiner et quelle correction appliquer. Si Linux et Docker sont nouveaux pour vous, commencez par des cours guidés de fondamentaux.
Le cours couvre-t-il le scan de vulnérabilités et tout le cycle DevSecOps ?
Non. Il se concentre sur les mauvaises configurations opérationnelles Linux et Docker : exposition, permissions, identités, secrets, moindre privilège, isolation Compose, images et dérives post-incident. Il n’enseigne ni SAST, ni scan de dépendances, ni IAM cloud, ni conception complète de pipelines de sécurité.
Ai-je besoin d’un compte cloud, d’un registre ou de mon propre hôte Docker ?
Non. Les services, conteneurs, images et projets Compose sont déjà préparés dans des labs isolés. Vous ne poussez aucune image vers un registre externe et ne modifiez aucun hôte de production.
Dois-je réaliser un défi chaque jour ?
Aucun calendrier n’est imposé. Les 30 défis sont ordonnés comme une progression de 30 jours, mais vous pouvez choisir un autre rythme. Respecter l’ordre est conseillé, car les derniers supposent une aisance en inspection, moindre privilège et validation.
