3 min de lecture<\/p>\n
Les conteneurs et Kubernetes dominent l’infrastructure informatique moderne – mais leur s\u00e9curisation accuse un retard de plusieurs ann\u00e9es par rapport \u00e0 leur adoption. 78 % des entreprises utilisant des clusters Kubernetes signalent des incidents de s\u00e9curit\u00e9 directement li\u00e9s \u00e0 des erreurs de configuration.<\/strong><\/p>\n Un cluster Kubernetes est un syst\u00e8me complexe avec de nombreux points d’attaque : images de conteneurs<\/strong> (vuln\u00e9rabilit\u00e9s dans les images de base et les d\u00e9pendances), configuration du cluster<\/strong> (RBAC, politiques de r\u00e9seau, normes de s\u00e9curit\u00e9 des pods), ex\u00e9cution<\/strong> (\u00e9chappements de conteneurs, \u00e9l\u00e9vation des privil\u00e8ges), cha\u00eene d’approvisionnement<\/strong> (images compromises provenant de registres publics) et gestion des secrets<\/strong> (informations d’identification dans les variables d’environnement ou les ConfigMaps).<\/p>\n Red Hat rapporte que 78 %<\/strong> des utilisateurs de Kubernetes ont subi des incidents de s\u00e9curit\u00e9 – la plupart dus \u00e0 des erreurs de configuration, et non \u00e0 des attaques sophistiqu\u00e9es. C’est la bonne nouvelle : la plupart des risques peuvent \u00eatre \u00e9limin\u00e9s par un durcissement syst\u00e9matique.<\/p>\n 1. Minimiser les images de base.<\/strong> Alpine ou Distroless au lieu d’Ubuntu\/Debian. Moins il y a de logiciels dans l’image, moins il y a de surface d’attaque. Les images Google Distroless contiennent uniquement l’application – pas de shell, pas de gestionnaire de paquets.<\/p>\n 2. Automatiser le scannage des images.<\/strong> Trivy, Grype ou Snyk scannent les images pour d\u00e9tecter les CVE connues. Int\u00e9grer dans la pipeline CI\/CD : aucune image avec des CVE critiques n’est d\u00e9ploy\u00e9e.<\/p>\n 3. Signature des images.<\/strong> Cosign ou Notary v2 garantissent que seules les images sign\u00e9es et v\u00e9rifi\u00e9es s’ex\u00e9cutent dans le cluster. Les contr\u00f4leurs d’admission comme Kyverno ou OPA Gatekeeper imposent la v\u00e9rification des signatures.<\/p>\n 1. Normes de s\u00e9curit\u00e9 des pods.<\/strong> D\u00e9finir Kubernetes Pod Security Admission (PSA) sur Restricted : pas de root, pas de conteneurs privil\u00e9gi\u00e9s, pas de r\u00e9seau h\u00f4te.<\/p>\n 2. Minimiser RBAC.<\/strong> Principe du moindre privil\u00e8ge : chaque compte de service obtient uniquement les droits dont il a r\u00e9ellement besoin. Auditer r\u00e9guli\u00e8rement avec des outils comme kubectl-who-can ou Kubiscan.<\/p>\n 3. Politiques de r\u00e9seau.<\/strong> Refuser par d\u00e9faut pour tous les pods, puis ouvrir de mani\u00e8re cibl\u00e9e. Sans politiques de r\u00e9seau, tout pod peut communiquer avec un autre – un paradis pour le mouvement lat\u00e9ral.<\/p>\n 4. Gestion des secrets.<\/strong> Pas de secrets dans les ConfigMaps ou les variables d’environnement. Utiliser External Secrets Operator avec HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault.<\/p>\n 5. Journalisation des audits.<\/strong> Activer les journaux d’audit Kubernetes et les transmettre \u00e0 un SIEM centralis\u00e9. Sans journaux, pas de forensique apr\u00e8s un incident.<\/p>\n Les mesures pr\u00e9ventives ne suffisent pas – la d\u00e9tection en temps r\u00e9el<\/strong> capture ce qui passe \u00e0 travers les mailles du filet.<\/p>\n Falco<\/strong> (Open Source, CNCF) surveille les appels syst\u00e8me en temps r\u00e9el et d\u00e9tecte les comportements anormaux : processus inattendus, modifications du syst\u00e8me de fichiers, connexions r\u00e9seau vers des cibles inconnues.<\/p>\n Tetragon<\/strong> (bas\u00e9 sur eBPF) offre une observabilit\u00e9 de niveau noyau sans surcharge de performance. Id\u00e9al pour les environnements n\u00e9cessitant une haute exigence de d\u00e9tection et de forensique.<\/p>\n Les plateformes commerciales comme Sysdig Secure, Aqua Security ou Prisma Cloud<\/strong> combinent le scannage d’images, les v\u00e9rifications de conformit\u00e9 et la protection en temps r\u00e9el dans une solution int\u00e9gr\u00e9e.<\/p>\n Utilisateurs de Kubernetes ayant subi des incidents de s\u00e9curit\u00e9 :<\/strong> 78 % (Red Hat State of Kubernetes Security 2024)<\/p>\n Images de conteneurs avec des CVE critiques :<\/strong> 87 % dans les registres publics (Sysdig)<\/p>\n Erreur de configuration la plus fr\u00e9quente :<\/strong> Pods avec des droits root (53 % de tous les clusters)<\/p>\n Taille du march\u00e9 de la s\u00e9curit\u00e9 des conteneurs :<\/strong> 3,2 milliards d\u2019euros d\u2019ici 2027 (MarketsandMarkets)<\/p>\n Source :<\/strong> Red Hat, Sysdig, CNCF, MarketsandMarkets, 2024<\/p>\n Chaque question est verrouill\u00e9e. Un clic d\u00e9verrouille la r\u00e9ponse.<\/p>\n Oui. EKS, AKS et GKE durcissent le plan de contr\u00f4le, mais la responsabilit\u00e9 de la s\u00e9curit\u00e9 des charges de travail (images, RBAC, politiques de r\u00e9seau, ex\u00e9cution) incombe au client. La responsabilit\u00e9 partag\u00e9e s\u2019applique \u00e9galement \u00e0 Kubernetes.<\/p>\n<\/details>\n Le scannage des images dans la pipeline CI\/CD. C\u2019est la mesure offrant le meilleur rapport co\u00fbt\/b\u00e9n\u00e9fice en termes de r\u00e9duction des risques. Trivy est open source et s\u2019int\u00e8gre en quelques minutes.<\/p>\n<\/details>\n Stack open source (Trivy + Falco + OPA) : gratuit, mais n\u00e9cessite du personnel pour l\u2019exploitation. Plateformes commerciales : 50 \u00e0 150 euros par n\u0153ud et par mois. Pour un cluster de 20 n\u0153uds : 12 000 \u00e0 36 000 euros par an.<\/p>\n<\/details>\n Diff\u00e9rent, mais pas n\u00e9cessairement plus s\u00fbr. Kubernetes offre une isolation plus granulaire (espaces de noms, politiques de r\u00e9seau, s\u00e9curit\u00e9 des pods) mais aussi une plus grande surface d\u2019attaque en raison de la complexit\u00e9 de la plateforme. La s\u00e9curit\u00e9 d\u00e9pend de la configuration.<\/p>\n<\/details>\n Une attaque o\u00f9 un code malveillant s\u2019\u00e9chappe d\u2019un conteneur et obtient l\u2019acc\u00e8s \u00e0 l\u2019h\u00f4te ou \u00e0 d\u2019autres conteneurs. Causes : vuln\u00e9rabilit\u00e9s du noyau, conteneurs privil\u00e9gi\u00e9s ou r\u00e9pertoires mont\u00e9s de l\u2019h\u00f4te. Les normes de s\u00e9curit\u00e9 des pods emp\u00eachent la plupart des vecteurs d\u2019\u00e9chappement.<\/p>\n<\/details>\n S\u00e9curit\u00e9 des Conteneurs et du Cloud : www.securitytoday.de<\/a><\/p>\n Kubernetes et Infrastructure Cloud-Native : www.cloudmagazin.com<\/a><\/p>\n D\u00e9cisions d’Architecture IT : www.digital-chiefs.de<\/a><\/p>\n Plus du r\u00e9seau MBF Media<\/p>\nL’essentiel<\/h2>\n
\n
Comprendre la surface d’attaque<\/h2>\n
S\u00e9curit\u00e9 des images : Les fondamentaux<\/h2>\n
Durcissement du cluster : Les cinq mesures les plus importantes<\/h2>\n
S\u00e9curit\u00e9 en temps r\u00e9el<\/h2>\n
Points cl\u00e9s en un coup d\u2019\u0153il<\/h2>\n
Questions fr\u00e9quentes<\/h2>\n
Ai-je besoin de s\u00e9curit\u00e9 des conteneurs si j\u2019utilise Kubernetes g\u00e9r\u00e9 ?<\/strong><\/summary>\n
Quel est le premier pas le plus important ?<\/strong><\/summary>\n
Quel est le co\u00fbt de la s\u00e9curit\u00e9 des conteneurs ?<\/strong><\/summary>\n
Kubernetes est-il plus s\u00fbr que les machines virtuelles ?<\/strong><\/summary>\n
Qu\u2019est-ce qu\u2019un \u00e9chappement de conteneur ?<\/strong><\/summary>\n
Lectures compl\u00e9mentaires dans le r\u00e9seau<\/h2>\n