Sécurité des conteneurs : hardening Docker et Kubernetes

Vos conteneurs tournent en production avec des droits root, des images basées sur Ubuntu avec 400 paquets inutiles, et un cluster Kubernetes où chaque pod communique librement avec tous les autres ? Vous n'êtes pas seul dans cette situation. D'après les analyses de Sysdig sur leur base de clients, 76% des conteneurs en production tournent en root, et 90% des clusters n'appliquent aucune network policy. Le passage aux conteneurs apporte de l'agilité, mais sans durcissement, vous déplacez juste vos vulnérabilités dans un environnement plus dynamique et plus difficile à surveiller. Ce guide couvre les deux dimensions du problème : le hardening des images Docker en amont, et la sécurisation du cluster Kubernetes en production. De la construction d'images minimales avec Chainguard au déploiement de Falco pour la détection runtime, vous trouverez des configurations concrètes et testées pour chaque recommandation pratique.

Sécurisation des images Docker : bonnes pratiques et outils de scan

La sécurisation des images Docker commence dès leur construction, bien avant leur déploiement en production. L'utilisation d'images de base minimales (distroless, alpine ou scratch) réduit significativement la surface d'attaque en éliminant les binaires et bibliothèques inutiles qui pourraient être exploités par un attaquant ayant compromis le conteneur. Chaque couche supplémentaire d'une image Docker représente une surface potentielle de vulnérabilités : limiter le nombre de layers et utiliser des builds multi-étapes (multi-stage builds) qui ne conservent dans l'image finale que les artefacts strictement nécessaires à l'exécution de l'application constitue une pratique fondamentale de durcissement des images que tout pipeline DevSecOps mature doit appliquer systématiquement dans ses processus de build.

Les outils de scan d'images (Image Vulnerability Scanning) analysent le contenu des images Docker et identifient les packages et bibliothèques embarqués qui contiennent des vulnérabilités connues référencées dans les bases CVE. Des outils comme Trivy, Grype, Snyk Container ou Clair s'intègrent dans les pipelines CI/CD pour bloquer automatiquement la progression des images contenant des vulnérabilités critiques ou hautes vers les registres de production. Les politiques d'admission (Admission Controllers) dans Kubernetes peuvent vérifier dynamiquement à l'exécution que les images déployées ont été scannées récemment et qu'elles respectent les politiques de sécurité définies par l'équipe de sécurité, empêchant le déploiement d'images non conformes même si elles parviennent à passer les étapes de scan du pipeline CI/CD de l'organisation.

La gestion de la chaîne de confiance des images constitue un aspect souvent négligé de la sécurité des conteneurs. Les images provenant de registres publics comme Docker Hub peuvent avoir été altérées ou remplacées par des images malveillantes, un phénomène connu sous le nom de typosquatting d'images. La signature cryptographique des images via Cosign (projet Sigstore) et la vérification de ces signatures avant tout déploiement garantissent que seules les images produites et signées par des pipelines CI/CD de confiance peuvent être déployées dans les clusters de production. Cette chaîne de confiance cryptographique, associée à l'utilisation de registres privés pour les images internes, constitue le fondement d'une posture de sécurité supply chain robuste dans les architectures conteneurisées modernes déployées à grande échelle.

La sécurisation des registres de conteneurs constitue une dimension complémentaire de la gouvernance des environnements Kubernetes souvent sous-estimée dans les premiers stades de maturité. Un registre privé mal configuré peut exposer les images d'entreprise à des acteurs malveillants ou permettre à des images non autorisées d'être déployées dans les clusters de production. Les solutions comme Harbor, quay.io Enterprise ou les registres managés des fournisseurs cloud (ECR, ACR, Artifact Registry) proposent des fonctionnalités de contrôle d'accès granulaires, de scan automatique des images lors de leur push et de politiques de rétention qui garantissent que seules les images récentes et conformes restent disponibles pour le déploiement dans les environnements de production. L'intégration du registre avec le système IAM de l'organisation permet de contrôler précisément quelles équipes et quels pipelines CI/CD peuvent pousser des images vers quels dépôts dans le registre centralisé.

Sécurisation des clusters Kubernetes : RBAC, Network Policies et Pod Security

La sécurisation d'un cluster Kubernetes repose sur plusieurs couches de contrôle complémentaires qui s'appliquent à différents niveaux de l'architecture. Le Role-Based Access Control (RBAC) Kubernetes gère les permissions des utilisateurs et des applications sur les ressources du cluster (pods, services, secrets, configmaps). Le principe de moindre privilège doit être appliqué rigoureusement aux ServiceAccounts utilisés par les pods, en leur accordant uniquement les permissions Kubernetes strictement nécessaires à leur fonctionnement. Les outils d'audit RBAC comme kubectl-who-can, rbac-audit ou Pluto permettent d'identifier les permissions excessives accordées dans un cluster existant et de réduire progressivement la surface d'attaque sans interrompre les applications en cours d'exécution en production.

Les Network Policies Kubernetes définissent les règles de communication réseau autorisées entre les pods du cluster, implémentant ainsi la microsegmentation au niveau applicatif. Par défaut, Kubernetes autorise tout trafic entre tous les pods du même namespace, ce qui représente un risque majeur en cas de compromission d'un pod : l'attaquant peut librement communiquer avec tous les autres services du cluster. La définition de Network Policies restrictives, qui n'autorisent que les flux de communication explicitement nécessaires entre les composants applicatifs, limite considérablement la capacité d'un attaquant à se déplacer latéralement dans le cluster après une compromission initiale. Des outils comme Cilium ou Calico implémentent ces politiques réseau à haute performance via eBPF et offrent des fonctionnalités avancées d'observabilité des flux réseau inter-pods.

Les Pod Security Admission (PSA), successeur des Pod Security Policies dépréciées depuis Kubernetes 1.25, définissent des niveaux de sécurité qui s'appliquent au niveau des namespaces. Le niveau "restricted" impose les contraintes les plus strictes : interdiction de lancer des conteneurs en mode privileged, interdiction de monter des volumes hostPath sensibles, obligation de définir des utilisateurs non-root, activation des profils seccomp et AppArmor/SELinux. La mise en place de ces politiques de sécurité au niveau des pods constitue une protection fondamentale contre les techniques d'évasion de conteneurs (container escape) qui permettent à un attaquant de passer du contexte isolé du conteneur au système hôte sous-jacent en exploitant des mauvaises configurations ou des vulnérabilités du kernel Linux sous-jacent.

Gestion des secrets dans les environnements Kubernetes

La gestion sécurisée des secrets (mots de passe, clés API, certificats, tokens) dans les environnements Kubernetes représente l'un des défis de sécurité les plus complexes des architectures conteneurisées. Les Secrets Kubernetes natifs sont par défaut stockés en clair dans etcd, la base de données distribuée du cluster, et encodés uniquement en base64 lors de leur utilisation dans les manifestes YAML. Cette protection insuffisante nécessite la mise en place de chiffrement au repos d'etcd (Encryption at Rest) en production, une fonctionnalité disponible mais non activée par défaut dans la plupart des distributions Kubernetes, qui doit être configurée explicitement par les équipes en charge de l'administration du cluster.

Les solutions de gestion externe des secrets représentent l'approche recommandée pour les environnements de production sensibles. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault ou GCP Secret Manager stockent les secrets de manière chiffrée hors du cluster Kubernetes et les injectent dans les pods au moment du démarrage, soit via des sidecars (External Secrets Operator), soit via des volumes CSI. Cette approche externe offre une rotation automatique des secrets, un audit complet de tous les accès et une révocation instantanée possible en cas de compromission suspectée, sans nécessiter de redéploiement des pods concernés. Ces fonctionnalités sont impossibles à réaliser avec les Secrets Kubernetes natifs, dont la modification nécessite un redémarrage des pods pour que la nouvelle valeur soit prise en compte par les applications en cours d'exécution.

L'accès aux secrets par les applications Kubernetes doit être contrôlé via des mécanismes d'authentification basés sur l'identité du pod plutôt que sur des credentials statiques partagés entre plusieurs composants. Les solutions de gestion des secrets modernes supportent l'authentification via les ServiceAccount Tokens Kubernetes (OIDC), permettant à un pod de prouver son identité auprès du gestionnaire de secrets de manière cryptographique sans avoir besoin d'un token statique préconfiguré susceptible d'être compromis. Cette approche, combinée avec des politiques d'accès granulaires qui limitent chaque pod aux seuls secrets dont il a réellement besoin, implémente le principe de moindre privilège au niveau des secrets et réduit significativement le rayon d'explosion en cas de compromission d'un pod applicatif dans le cluster Kubernetes de production.

Observabilité et détection des menaces dans les environnements conteneurisés

La détection des menaces dans les environnements Kubernetes nécessite des outils spécialisés capables de comprendre la sémantique des conteneurs et les comportements normaux des workloads déployés. Falco, le projet open source CNCF de référence pour la sécurité runtime des conteneurs, analyse les appels système effectués par les conteneurs en temps réel via eBPF et détecte les comportements anormaux selon des règles prédéfinies ou personnalisables : exécution d'un shell dans un conteneur de production, modification des binaires du système de fichiers, connexions réseau vers des destinations inattendues ou tentatives d'escalade de privilèges. Ces règles, basées sur les syscalls Linux observés, sont très difficiles à contourner pour un attaquant car elles opèrent au niveau du noyau Linux, en dessous de l'application et du runtime de conteneur utilisé.

L'audit des API Kubernetes est une source précieuse de données de sécurité qui enregistre chaque requête adressée à l'API server du cluster : création ou suppression de ressources, modifications de configurations, accès aux secrets et exécution de commandes dans les pods (kubectl exec). Ces logs d'audit, configurables en termes de granularité et de profondeur, doivent être centralisés dans un SIEM et soumis à des règles de détection qui signalent les comportements anormaux : accès massifs aux secrets, créations de ClusterRoleBindings non autorisées, déploiements dans des namespaces sensibles. L'intégration de ces logs avec les alertes Falco dans une console SIEM unifiée permet aux équipes SOC de corréler les événements et de reconstituer la chaîne d'attaque dans un environnement Kubernetes compromis par des acteurs malveillants.

Les solutions de protection runtime des charges de travail conteneurisées (CWPP) comme Sysdig Secure, Aqua Security ou Prisma Cloud offrent une vision intégrée de la sécurité des conteneurs, depuis la construction des images jusqu'à leur exécution en production. Ces plateformes combinent le scan de vulnérabilités, la vérification de conformité des configurations Kubernetes par rapport aux benchmarks CIS, la surveillance comportementale en temps réel et la réponse aux incidents automatisée. Leur déploiement dans les environnements Kubernetes de production permet aux équipes sécurité d'obtenir une visibilité unifiée sur l'ensemble de la surface d'attaque des architectures conteneurisées et de répondre rapidement aux incidents détectés avant qu'ils ne s'aggravent et ne causent des dommages plus importants pour l'organisation et ses clients.

Conformité et gouvernance des environnements Kubernetes en production

La conformité des clusters Kubernetes aux standards de sécurité reconnus constitue une exigence croissante pour les organisations soumises à des audits réglementaires ou à des certifications sectorielles. Le benchmark CIS Kubernetes, maintenu par le Center for Internet Security, définit plus de 200 contrôles de sécurité couvrant la configuration de l'API server, du controller manager, du scheduler, d'etcd, des nodes et des policies réseau et pod. Des outils d'audit de conformité automatisés comme kube-bench analysent un cluster existant et génèrent un rapport de conformité avec les résultats pour chaque contrôle CIS, identifiant les écarts par rapport aux recommandations et suggérant les configurations correctives à appliquer pour atteindre le niveau de conformité requis par l'organisation dans ses engagements réglementaires.

La gouvernance des environnements multi-clusters, caractéristiques des organisations ayant adopté Kubernetes à grande échelle avec des clusters de développement, staging et production dans plusieurs régions cloud, nécessite des outils de politique centralisés capables d'appliquer des règles de sécurité cohérentes sur l'ensemble du parc. Des solutions comme Open Policy Agent (OPA) avec Gatekeeper ou Kyverno permettent de définir des politiques déclaratives en langage Rego ou YAML qui s'appliquent automatiquement à tous les clusters managés, garantissant que les règles de sécurité (interdiction des images non signées, obligation des limites de ressources, interdiction du mode privileged) sont respectées uniformément sans configuration manuelle répétée pour chaque nouveau cluster. Cette centralisation de la gouvernance sécurité est indispensable dans les organisations DevOps avancées qui déploient des dizaines de clusters Kubernetes dans des environnements cloud multiples et hétérogènes à l'échelle mondiale.

Construire des images Docker minimales

La première règle du hardening Docker : moins il y a de composants dans l'image, moins il y a de surface d'attaque. Une image basée sur ubuntu:24.04 contient environ 100 paquets et 120+ CVE connues à un instant T. Une image distroless de Google ou chainguard/static en contient zéro. La technique du multi-stage build est votre alliée :

FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o /app/server

FROM cgr.dev/chainguard/static:latest
COPY --from=builder /app/server /server
USER nonroot
ENTRYPOINT ["/server"]

L'image finale ne contient que votre binaire. Pas de shell, pas de package manager, pas de curl — un attaquant qui obtient une RCE ne peut quasiment rien exploiter. Scannez systématiquement vos images avec Trivy ou Grype avant le push sur le registry. Intégrez ce scan dans votre pipeline CI/CD sécurisé comme gate bloquante.

SecurityContext Kubernetes : la configuration ignorée par 80% des clusters

Le SecurityContext est le mécanisme natif de Kubernetes pour restreindre les privilèges d'un pod. Voici la configuration minimale pour la production :

securityContext:
 runAsNonRoot: true
 runAsUser: 65534
 readOnlyRootFilesystem: true
 allowPrivilegeEscalation: false
 capabilities:
 drop: ["ALL"]
 seccompProfile:
 type: RuntimeDefault

runAsNonRoot empêche le conteneur de tourner en root. readOnlyRootFilesystem bloque l'écriture sur le filesystem sauf les volumes montés explicitement. drop ALL supprime toutes les capabilities Linux. Pour appliquer ces contraintes à l'échelle du cluster, utilisez les Pod Security Standards ou mieux, des politiques Policy as Code avec Kyverno qui offrent plus de flexibilité.

Network policies : la micro-segmentation des conteneurs

Par défaut, Kubernetes autorise toute communication entre pods. Un pod compromis dans le namespace frontend peut interroger directement votre base de données dans le namespace backend. Les NetworkPolicies corrigent cette faille architecturale :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: backend-db-only
 namespace: backend
spec:
 podSelector:
 matchLabels:
 app: postgres
 policyTypes: ["Ingress"]
 ingress:
 - from:
 - podSelector:
 matchLabels:
 app: api-server
 ports:
 - port: 5432

Commencez par une politique default-deny dans chaque namespace, puis ouvrez uniquement les flux nécessaires. C'est le principe du moindre privilège appliqué au réseau. Pour les clusters cloud, notre guide sur la posture de sécurité cloud complète cette approche.

Détection runtime avec Falco et Tetragon

Falco (CNCF) surveille les appels système de vos conteneurs en temps réel grâce à eBPF. Il détecte les comportements anormaux : exécution d'un shell dans un conteneur, lecture de fichiers sensibles, connexion réseau inattendue, modification de binaires système. Tetragon (Cilium) va plus loin en permettant non seulement la détection mais aussi le blocage en temps réel.

Les deux outils s'intègrent avec votre stack d'observabilité : alertes vers Prometheus/Alertmanager, logs vers votre SIEM. En cas d'incident, les données Falco ou Tetragon alimentent directement votre playbook de réponse aux incidents.

Registre privé et admission control

Ne déployez jamais d'images provenant de registres publics non vérifiés. Mettez en place un registre privé — Harbor est l'option open-source la plus complète. Il scanne automatiquement chaque image avec Trivy et peut bloquer le pull des images avec des CVE critiques. Côté Kubernetes, un admission controller valide chaque demande de création de pod.

Selon les recommandations du guide ANSSI sur la sécurité des conteneurs Docker, l'utilisation d'un registre privé et la signature des images constituent des mesures de base indispensables. Le CIS Kubernetes Benchmark fournit des centaines de contrôles automatisables avec kube-bench d'Aqua Security.