Sécurité des conteneurs
Mise à jour :
Les conteneurs accélèrent les déploiements, mais introduisent de nouvelles surfaces d’attaque. Images vulnérables, configurations permissives, secrets exposés : sans contrôles adaptés, un cluster Kubernetes devient une cible de choix.
Pourquoi sécuriser les conteneurs ?
Les conteneurs partagent le noyau de l’hôte. Une vulnérabilité exploitée peut compromettre tout le nœud, voire le cluster entier. Les risques principaux :
- Images vulnérables : dépendances obsolètes, CVE non corrigées
- Configurations permissives : conteneurs root, capabilities excessives
- Secrets mal gérés : variables d’environnement en clair, ConfigMaps exposés
- Réseau ouvert : absence de Network Policies, trafic est-ouest non filtré
- Supply chain : images tierces non vérifiées, registres non sécurisés
Qui est concerné ?
| Profil | Besoin principal |
|---|---|
| Développeur | Construire des images sécurisées, scanner avant push |
| Ops / SRE | Configurer les politiques, durcir les clusters |
| DevSecOps | Intégrer les scans dans la CI/CD |
| RSSI | Conformité (CIS Benchmarks, NSA guidelines), audit |
Comment sécuriser les conteneurs ?
Build : sécuriser les images
- Utiliser des images de base minimales (distroless, Alpine)
- Scanner les images pour détecter les CVE (Trivy, Grype)
- Signer les images (Cosign, Notary)
- Ne jamais exécuter en root par défaut
Deploy : durcir les configurations
- Appliquer les CIS Kubernetes Benchmarks
- Utiliser des Pod Security Standards (Restricted)
- Définir des ResourceQuota et LimitRange
- Activer les Network Policies
Runtime : détecter et bloquer
- Surveiller les comportements anormaux (syscalls, accès fichiers)
- Bloquer les connexions réseau suspectes
- Alerter sur les modifications de configuration
Scénario : pipeline CI/CD sécurisé
Une équipe déploie une application sur Kubernetes. Comment intégrer la sécurité ?
- Build : Trivy scanne l’image dans la CI, bloque si CVE critique
- Registry : l’image est signée avec Cosign avant push
- Admission : Kubescape valide les manifests au deploy
- Runtime : NeuVector surveille les conteneurs en production
Résultat : une vulnérabilité critique est détectée avant la mise en production.
Pièges courants
- Scanner uniquement au build — les CVE apparaissent après le déploiement
- Désactiver les Pod Security Standards “pour que ça marche” — dette de sécurité
- Faire confiance aux images
latest— aucune garantie de contenu - Ignorer les Network Policies — tout le trafic est autorisé par défaut
- Oublier les secrets — ils finissent dans les logs ou les variables d’environnement
Outils disponibles
Kubescape Audit de sécurité Kubernetes selon les CIS Benchmarks et NSA guidelines.
NeuVector Protection runtime, pare-feu réseau et conformité pour Kubernetes.
Outils à explorer
- Trivy — scanner de vulnérabilités pour images, fichiers, repos
- Grype — scanner de CVE rapide (Anchore)
- Falco — détection d’intrusion runtime basée sur les syscalls
- Kyverno — policy engine natif Kubernetes (alternative à OPA)
- Cosign — signature et vérification d’images conteneur
À retenir
- Shift-left — scannez les images dès le build, pas seulement en prod
- Moindre privilège — jamais de conteneurs root, capabilities minimales
- Defense in depth — build + deploy + runtime, pas un seul point de contrôle
- Network Policies — filtrez le trafic est-ouest par défaut
- Conformité continue — les CIS Benchmarks évoluent, auditez régulièrement