Qu'est-ce que la Sécurité des Conteneurs ?

Qu'est-ce que la sécurité des conteneurs ?

La sécurité des conteneurs est la discipline de protection des applications conteneurisées et de l'infrastructure sur laquelle elles tournent, à travers tout le cycle de vie : build d'image, stockage en registre, déploiement, exécution runtime et orchestration. Comme les conteneurs (Docker, OCI, containerd) et Kubernetes sont devenus le substrat de déploiement dominant pour les applications cloud-native, la sécurité des conteneurs est devenue une sous-spécialité distincte au sein de la sécurité cloud — distincte parce que les conteneurs introduisent des surfaces d'attaque que les VMs et le bare-metal n'ont pas (kernel partagé, supply chain d'image, workloads éphémères, taux de changement rapides).

Compromettre des conteneurs est de plus en plus attractif pour les attaquants. Mineurs de crypto injectés via des images de conteneur vulnérables, attaques de supply chain via images de base empoisonnées sur Docker Hub, exploits d'évasion contre le kernel depuis l'intérieur d'un conteneur, mouvement latéral à travers un cluster Kubernetes — toutes sont des menaces réelles et documentées en 2026. Le modèle de défense en profondeur pour les conteneurs couvre le scanning d'images, les politiques de registre, la détection runtime, la segmentation réseau et le durcissement de l'hôte.

Les cinq couches de sécurité des conteneurs

1. Sécurité d'image (build-time)

La fondation. Les vulnérabilités dans les images de conteneur sont héritées par chaque workload qui les utilise.

• Utilisez des images de base minimales (distroless, Alpine, scratch) — moins de packages = moins de CVEs.
• Épinglez des versions spécifiques, pas latest. Épinglez par digest (sha256), pas par tag.
• Scannez pendant le build avec Trivy, Grype, Snyk, Anchore, Docker Scout. Faites échouer les builds sur CVEs critiques.
• Ne tournez pas en root. Ajoutez USER nonroot dans le Dockerfile.
• N'incluez pas de secrets dans les images. Utilisez l'injection au moment du mount.
• Signez les images avec cosign ou Notary. Vérifiez les signatures au déploiement.

2. Sécurité de registre

Où vivent les images construites. Compromis ici = attaque de supply chain.

• Utilisez un registre privé (ECR, GCR, ACR, Harbor) avec accès contrôlé par IAM.
• Scanning continu des images stockées (les CVEs sont découverts après le push).
• Restreignez les pulls par IP / VPC / compte de service.
• Logs d'audit de qui a poussé et tiré quoi.

3. Sécurité runtime

Ce que le conteneur fait une fois en cours d'exécution. Le domaine de recherche le plus actif en 2026.

• Supprimez les capabilities Linux ; le défaut est excessif. Utilisez capabilities: { drop: ["ALL"] } et ajoutez seulement ce qui est nécessaire.
• Système de fichiers racine en lecture seule (readOnlyRootFilesystem: true) — la plupart des apps peuvent tourner avec ça.
• Profils seccomp + AppArmor / SELinux pour limiter les syscalls.
• Détection runtime : Falco, Sysdig, Aqua, Sysdig Secure détectent les comportements anormaux (exécution de shell dans les conteneurs production, connexions réseau inhabituelles).
• Pas de conteneurs privilégiés en production. privileged: true est essentiellement équivalent à root sur l'hôte.

4. Sécurité d'orchestration / Kubernetes

Kubernetes est l'orchestrateur dominant et une surface d'attaque profonde en lui-même.

• RBAC : comptes de service à moindre privilège. La plupart des pods n'ont pas besoin de cluster-admin.
• NetworkPolicies : ingress et egress default-deny, puis autorisez seulement ce qui est nécessaire.
• Pod Security Standards (remplaçant PodSecurityPolicies) : profil Restricted par défaut.
• Admission controllers (OPA, Kyverno) pour faire respecter les politiques au moment du déploiement.
• Audit logging sur le serveur API.
• Désactiver l'accès anonyme, durcissement de l'API kubelet.

5. Sécurité d'hôte

L'OS sous les conteneurs.

• Gardez le kernel patché (les CVEs de kernel permettent les évasions de conteneur).
• Utilisez des OS durcis (Bottlerocket, Talos, CoreOS) — minimaux, immuables.
• SSH désactivé en production (utilisez l'accès just-in-time via des outils comme Teleport ou AWS SSM).
• Détection d'intrusion au niveau hôte (auditd, monitoring basé sur eBPF).

Le modèle de menace des conteneurs : ce que les attaquants font réellement

• Exploitation d'image vulnérable. L'attaquant scanne votre registre, trouve un CVE dans votre version nginx, l'exploite.
• Supply chain. Une image de base populaire sur Docker Hub est compromise ; chaque image downstream hérite de la backdoor.
• Évasion de conteneur. Exploit de kernel (Dirty Pipe, Dirty COW historiquement) donne root sur l'hôte depuis l'intérieur du conteneur.
• Kubernetes mal configuré. API kubelet exposée, compte de service par défaut avec trop de permissions, ou cluster admin anonyme activé.
• Injection de minage de crypto. Image / runtime compromise transforme votre cluster en ferme de minage. Courant car économiquement aligné.
• Mouvement latéral. Compromis initial d'un pod → accès aux comptes de service partagés → accès à d'autres pods → accès au control plane du cluster.
• Fuite de secrets. Secrets stockés comme variables d'environnement visibles dans kubectl describe pod pour quiconque avec accès en lecture.

Erreurs courantes de sécurité de conteneurs

• Tourner en root par défaut. La plupart des images de conteneur tournent en root sauf indication contraire explicite. Utilisez des utilisateurs non-root dans les Dockerfiles.
• Tirer :latest en production. Un nouveau "latest" peut être poussé à tout moment. Utilisez des tags ou digests spécifiques.
• Conteneurs privilégiés "parce que c'est plus facile". privileged: true annule la plupart de l'isolation de conteneur. Utilisez plutôt des capabilities spécifiques.
• Pas de scanning d'image en CI. Les vulnérabilités sont livrées en prod sans être détectées. Ajoutez Trivy / Grype à votre pipeline.
• Egress ouvert. Le networking Kubernetes par défaut permet aux pods compromis d'appeler à la maison, exfiltrer des données, scanner les services internes. Utilisez NetworkPolicies.
• Partager des comptes de service entre pods. Un pod compromis obtient l'accès à tout ce que ce compte peut faire. Comptes de service par workload.
• Stocker des secrets dans des env vars sans rotation. Visibles dans la sortie de describe, dans l'env du conteneur, dans les logs. Utilisez les Secrets Kubernetes avec chiffrement au repos, ou des gestionnaires de secrets externes (Vault, AWS Secrets Manager).
• Faire confiance au registre sans vérification. Signez les images et vérifiez les signatures. Sinon un attaquant qui compromet votre registre peut injecter n'importe quoi.

FAQ : Sécurité des Conteneurs

Quelle est la vulnérabilité de conteneur la plus courante en 2026 ?

Images de base obsolètes portant des CVEs connus. La plupart des images de conteneur dérivent d'images de base qui ont eu des vulnérabilités découvertes depuis la publication originale. Le re-scanning continu l'attrape ; les rebuilds périodiques le patchent.

Les conteneurs sont-ils plus ou moins sécurisés que les VMs ?

Les conteneurs partagent le kernel hôte, donc les exploits de kernel affectent tous les conteneurs ; les VMs ont une isolation assistée par matériel. Mais les conteneurs ont des surfaces d'attaque plus petites (pas d'OS complet par workload), des cycles de patch plus rapides et un meilleur outillage pour le scanning au niveau image. Évaluation nette : sécurité comparable avec différents trade-offs, quand les deux sont bien configurés.

Ai-je besoin d'un outil de sécurité runtime comme Falco ?

Pour la production à grande échelle, oui. Falco / Sysdig / Aqua détectent les comportements anormaux (conteneur exécutant un shell, conteneur faisant des connexions réseau inattendues) que le scanning au build-time ne peut pas. Pour le staging et les petits clusters, sauter est raisonnable.

Et la sécurité Kubernetes spécifiquement ?

Traitez votre cluster comme une frontière de sécurité multi-tenant même si vous n'avez pas encore de multi-tenancy. RBAC, NetworkPolicies, Pod Security Standards, admission controllers, audit logs. CIS Benchmarks pour Kubernetes est la checklist de durcissement canonique.

Comment sécuriser la supply chain ?

Signez les images au build (cosign), vérifiez les signatures à l'admission (contrôleurs de politique Sigstore), utilisez les SBOMs (CycloneDX, SPDX) pour tracer ce qui est dans chaque image, scannez les registres continuellement. Le framework SLSA définit les niveaux de maturité pour la sécurité de supply chain.

Ai-je besoin d'un outil CSPM ?

Pour les déploiements Kubernetes multi-cloud, les outils Cloud Security Posture Management (Wiz, Orca, Prisma Cloud) aident à tracer les mauvaises configurations à travers les clusters. Pour single-cloud single-cluster, les outils natifs (AWS Inspector, GCP Security Command Center) suffisent.

Et les conteneurs serverless ?

AWS Fargate, Google Cloud Run, Azure Container Apps réduisent la sécurité d'hôte à la responsabilité de la plateforme, mais la sécurité d'image et la sécurité runtime s'appliquent toujours. L'histoire de supply chain est inchangée.

Comment LoadFocus se rapporte à la sécurité des conteneurs

Les applications conteneurisées doivent gérer la validation de sécurité sous charge réaliste — le middleware de sécurité lent (proxies d'auth, terminateurs mTLS, WAFs) devient souvent le goulot d'étranglement sous trafic. Les tests de charge LoadFocus valident que les stacks de sécurité durcies (avec tous vos agents de sécurité runtime activés) atteignent toujours les objectifs de latence à l'échelle de production. Le monitoring d'API trace la latence par endpoint continuellement, attrapant quand une dégradation de mise à jour de sécurité frappe la production.