1 min de lecture<\/p>\n
Kubernetes est devenu le standard de facto pour l’orchestration de conteneurs. Cependant, la complexit\u00e9 du syst\u00e8me cr\u00e9e une surface d’attaque \u00e9norme : des politiques RBAC mal configur\u00e9es, des serveurs API expos\u00e9s et des conteneurs privil\u00e9gi\u00e9s sont plus la r\u00e8gle que l’exception dans les environnements de production. Voici sept erreurs qui peuvent \u00eatre corrig\u00e9es imm\u00e9diatement.<\/strong><\/p>\n Erreur 1 : Serveur API accessible publiquement.<\/strong> Le serveur API Kubernetes est le cerveau du cluster. Celui qui y a acc\u00e8s contr\u00f4le 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.<\/p>\n Erreur 2 : R\u00f4les RBAC surprivilegi\u00e9s.<\/strong> cluster-admin pour chaque d\u00e9veloppeur, parce que c’est \u00ab plus simple \u00bb. Le principe du moindre privil\u00e8ge est souvent ignor\u00e9 dans Kubernetes. Solution : r\u00f4les sp\u00e9cifiques aux namespaces au lieu de ClusterRoles, audits RBAC r\u00e9guliers avec des outils comme rbac-police ou kubectl-who-can.<\/p>\n Erreur 3 : Conteneurs privil\u00e9gi\u00e9s.<\/strong> Les conteneurs qui s’ex\u00e9cutent en tant que root ou avec le drapeau privileged peuvent s’\u00e9chapper du syst\u00e8me h\u00f4te. Un escape de conteneur donne \u00e0 l’attaquant acc\u00e8s \u00e0 l’ensemble du n\u0153ud. Solution : SecurityContext avec runAsNonRoot, readOnlyRootFilesystem et suppression de toutes les capacit\u00e9s Linux.<\/p>\n Erreur 4 : Absence de politiques r\u00e9seau.<\/strong> Sans politiques r\u00e9seau, chaque pod peut communiquer avec chaque autre pod. Le mouvement lat\u00e9ral au sein du cluster est trivial. Solution : politique Default-Deny pour tous les namespaces, puis r\u00e8gles Allow explicites pour la communication n\u00e9cessaire.<\/p>\n Erreur 5 : Secrets en Base64 dans etcd.<\/strong> Les secrets Kubernetes sont seulement cod\u00e9s en Base64, et non chiffr\u00e9s. Celui qui a acc\u00e8s \u00e0 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).<\/p>\n Erreur 6 : Images de conteneurs obsol\u00e8tes.<\/strong> 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\u00f4leur d’admission (OPA Gatekeeper, Kyverno) qui bloque les images non s\u00e9curis\u00e9es.<\/p>\n Erreur 7 : Absence de normes de s\u00e9curit\u00e9 des pods\/admission.<\/strong> Depuis Kubernetes 1.25, les normes de s\u00e9curit\u00e9 des pods (PSS) sont le successeur officiel de PodSecurityPolicy. Trois niveaux : Privileged (tout est autoris\u00e9), Baseline (les vecteurs d’escalade connus sont bloqu\u00e9s), Restricted (meilleures pratiques). De nombreux clusters fonctionnent encore sans aucune restriction.<\/p>\n Solution : activer les PSS en mode \u00ab Avertissement \u00bb, identifier et corriger les violations, puis passer en mode \u00ab Enforcement \u00bb. Pour des politiques plus complexes : OPA Gatekeeper ou Kyverno en tant que contr\u00f4leurs d’admission.<\/p>\n Expos\u00e9s API-Server :<\/strong> 380 000+ accessibles publiquement (Shadowserver Foundation)<\/p>\n Incidents de s\u00e9curit\u00e9 :<\/strong> 67 % des utilisateurs de K8s ont eu un incident (Red Hat 2024)<\/p>\n Failles d\u2019images :<\/strong> En moyenne, 72 CVEs connus par image de conteneur (Sysdig 2024)<\/p>\n Chaque question est verrouill\u00e9e. Un clic d\u00e9verrouille la r\u00e9ponse.<\/p>\n Outils : kube-bench (v\u00e9rification 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\u00eats \u00e0 l’emploi en quelques minutes.<\/p>\n<\/details>\n Kubernetes g\u00e9r\u00e9 r\u00e9duit la surface d’attaque du plan de contr\u00f4le, mais la configuration des charges de travail (RBAC, politiques r\u00e9seau, s\u00e9curit\u00e9 des pods) reste de la responsabilit\u00e9 de l’utilisateur. La plupart des erreurs mentionn\u00e9es concernent pr\u00e9cis\u00e9ment ce domaine.<\/p>\n<\/details>\n Les politiques r\u00e9seau avec Default-Deny. Dans la plupart des clusters, la communication pod-\u00e0-pod est compl\u00e8tement non restreinte. Une seule politique Default-Deny par namespace bloque imm\u00e9diatement le mouvement lat\u00e9ral – avec un effort minimal.<\/p>\n<\/details>\n Plus du r\u00e9seau MBF Media<\/p>\nL’essentiel<\/h2>\n
\n
1-2 : Exposition du serveur API et absence de RBAC<\/h2>\n
3-4 : Conteneurs privil\u00e9gi\u00e9s et absence de politiques r\u00e9seau<\/h2>\n
5-6 : Secrets en clair et images obsol\u00e8tes<\/h2>\n
7 : Absence de normes de s\u00e9curit\u00e9 des pods<\/h2>\n
Faits cl\u00e9s<\/h2>\n
Questions fr\u00e9quentes<\/h2>\n
Comment v\u00e9rifier mon cluster pour des erreurs de configuration ?<\/strong><\/summary>\n
Un Kubernetes g\u00e9r\u00e9 (EKS, AKS, GKE) suffit-il ?<\/strong><\/summary>\n
Quel est le gain rapide le plus rapide ?<\/strong><\/summary>\n
Articles connexes<\/h2>\n
\n