Kubernetes-Security: Les 7 erreurs de configuration les plus fréquentes dans les systèmes de production
1 min de lecture
Kubernetes est devenu le standard de facto pour l’orchestration de conteneurs. Cependant, la complexité du système crée une surface d’attaque énorme : des politiques RBAC mal configurées, des serveurs API exposés et des conteneurs privilégiés sont plus la règle que l’exception dans les environnements de production. Voici sept erreurs qui peuvent être corrigées immédiatement.
L’essentiel
- NSA/CISA : « La mauvaise configuration est la faille la plus fréquente dans Kubernetes »
- Plus de 380 000 serveurs API Kubernetes accessibles publiquement (Shadowserver 2024)
- Rapport Red Hat : 67 % des entreprises ont eu un incident de sécurité dans K8s
- La plupart des failles sont des erreurs de configuration – et non des bogues logiciels
1-2 : Exposition du serveur API et absence de RBAC
Erreur 1 : Serveur API accessible publiquement. Le serveur API Kubernetes est le cerveau du cluster. Celui qui y a accès contrôle tout. Pourtant, des scanners comme Shodan trouvent des centaines de milliers de serveurs API accessibles publiquement. Solution : rendre le serveur API accessible uniquement via VPN ou Private Endpoint.
Erreur 2 : Rôles RBAC surprivilegiés. cluster-admin pour chaque développeur, parce que c’est « plus simple ». Le principe du moindre privilège est souvent ignoré dans Kubernetes. Solution : rôles spécifiques aux namespaces au lieu de ClusterRoles, audits RBAC réguliers avec des outils comme rbac-police ou kubectl-who-can.
3-4 : Conteneurs privilégiés et absence de politiques réseau
Erreur 3 : Conteneurs privilégiés. Les conteneurs qui s’exécutent en tant que root ou avec le drapeau privileged peuvent s’échapper du système hôte. Un escape de conteneur donne à l’attaquant accès à l’ensemble du nœud. Solution : SecurityContext avec runAsNonRoot, readOnlyRootFilesystem et suppression de toutes les capacités Linux.
Erreur 4 : Absence de politiques réseau. Sans politiques réseau, chaque pod peut communiquer avec chaque autre pod. Le mouvement latéral au sein du cluster est trivial. Solution : politique Default-Deny pour tous les namespaces, puis règles Allow explicites pour la communication nécessaire.
5-6 : Secrets en clair et images obsolètes
Erreur 5 : Secrets en Base64 dans etcd. Les secrets Kubernetes sont seulement codés en Base64, et non chiffrés. Celui qui a accès à etcd lit tous les secrets en clair. Solution : activer le chiffrement au repos pour etcd ou utiliser des solutions de gestion de secrets externes (Vault, AWS Secrets Manager, Azure Key Vault).
Erreur 6 : Images de conteneurs obsolètes. Des images avec des CVEs connus tournent pendant des mois en production, car personne ne les scanne. Solution : scanner les images dans la pipeline CI/CD (Trivy, Snyk Container) et utiliser un contrôleur d’admission (OPA Gatekeeper, Kyverno) qui bloque les images non sécurisées.
7 : Absence de normes de sécurité des pods
Erreur 7 : Absence de normes de sécurité des pods/admission. Depuis Kubernetes 1.25, les normes de sécurité des pods (PSS) sont le successeur officiel de PodSecurityPolicy. Trois niveaux : Privileged (tout est autorisé), Baseline (les vecteurs d’escalade connus sont bloqués), Restricted (meilleures pratiques). De nombreux clusters fonctionnent encore sans aucune restriction.
Solution : activer les PSS en mode « Avertissement », identifier et corriger les violations, puis passer en mode « Enforcement ». Pour des politiques plus complexes : OPA Gatekeeper ou Kyverno en tant que contrôleurs d’admission.
Faits clés
Exposés API-Server : 380 000+ accessibles publiquement (Shadowserver Foundation)
Incidents de sécurité : 67 % des utilisateurs de K8s ont eu un incident (Red Hat 2024)
Failles d’images : En moyenne, 72 CVEs connus par image de conteneur (Sysdig 2024)
Questions fréquentes
Comment vérifier mon cluster pour des erreurs de configuration ?
Outils : kube-bench (vérification du benchmark CIS), kubescape (guide de durcissement NSA/CISA), Trivy (scanning des images et des configurations), rbac-police (audit RBAC). Tous open source et prêts à l’emploi en quelques minutes.
Un Kubernetes géré (EKS, AKS, GKE) suffit-il ?
Kubernetes géré réduit la surface d’attaque du plan de contrôle, mais la configuration des charges de travail (RBAC, politiques réseau, sécurité des pods) reste de la responsabilité de l’utilisateur. La plupart des erreurs mentionnées concernent précisément ce domaine.
Quel est le gain rapide le plus rapide ?
Les politiques réseau avec Default-Deny. Dans la plupart des clusters, la communication pod-à-pod est complètement non restreinte. Une seule politique Default-Deny par namespace bloque immédiatement le mouvement latéral – avec un effort minimal.
Articles connexes
- Sécurité multi-cloud 2026 : Les 5 plus grands risques et comment les résoudre
- CNAPP et CSPM 2025 : Construire correctement la sécurité native du cloud
- Étude de cas : Migration cloud d’un prestataire de services financiers – Sécurité dès le départ
Plus du réseau MBF Media
- Cloud Magazin – Cloud, SaaS & Infrastructure IT
- myBusinessFuture – Numérisation, IA & Business
- Digital Chiefs – Leadership de pensée C-Level
Source de l’image : Pexels / Negative Space
