OWASP Kubernetes Top 10 2025 : les dix risques d’un cluster

Le Top 10 OWASP des risques Kubernetes a reçu une deuxième édition en 2025, trois ans après la première. Son objet est particulier : il ne décrit pas les défauts d’une application mais ceux d’un orchestrateur, c’est-à-dire d’un système dont le métier est de donner des droits, de router du trafic et de distribuer des secrets à des charges de travail qui changent toutes les heures. Deux entrées sont nouvelles, deux anciennes fusionnent, et une disparaît — dont la disparition est la plus instructive de la liste.

→ Lire l’explication complète de la marmotte

Les dix risques de l’édition 2025

Code	Titre officiel	Traduction
K01	Insecure Workload Configurations	Configurations de charges de travail non sécurisées
K02	Overly Permissive Authorization Configurations	Configurations d’autorisation trop permissives
K03	Secrets Management Failures	Défaillances de gestion des secrets
K04	Lack Of Cluster Level Policy Enforcement	Absence d’application de politiques au niveau du cluster
K05	Missing Network Segmentation Controls	Absence de contrôles de segmentation réseau
K06	Overly Exposed Kubernetes Components	Composants Kubernetes trop exposés
K07	Misconfigured And Vulnerable Cluster Components	Composants du cluster mal configurés et vulnérables
K08	Cluster To Cloud Lateral Movement	Mouvement latéral du cluster vers le cloud
K09	Broken Authentication Mechanisms	Mécanismes d’authentification défaillants
K10	Inadequate Logging And Monitoring	Journalisation et supervision insuffisantes

Comme pour le Mobile Top 10, les codes ne portent pas de millésime : « K03 » désigne la gestion des secrets en 2025 et les autorisations trop permissives en 2022. L’édition s’écrit à côté, ou la référence ne vaut rien.

Deux entrées nouvelles, et elles comblent de vrais trous

K06, les composants Kubernetes trop exposés. L’entrée part d’un constat chiffré qui mérite d’être lu lentement : sur les distributions managées les plus répandues, le réglage par défaut expose l’interface de programmation principale de Kubernetes à Internet, sans restriction d’adresse source — et il y a, écrivent les auteurs, bien plus d’un million de serveurs d’interface Kubernetes directement joignables depuis Internet, auxquels s’ajoutent des Kubelet et des etcd.

Le risque est double. D’abord, un attaquant qui obtient un jeu d’identifiants valides, par un poste d’administrateur compromis ou une fuite dans un dépôt public, peut s’en servir sans contrainte de position réseau. Ensuite, la fuite d’information : par défaut, le point d’entrée /version répond sans authentification, et les certificats TLS présentés par ces services portent des champs d’extension distinctifs qui révèlent souvent des adresses de réseau privé. La contre-mesure est banale et rarement appliquée : restreindre l’accès aux interfaces de programmation du cluster à des réseaux et des hôtes de confiance, ce que tous les fournisseurs managés permettent. Le port du Kubelet, lui, n’a aucune raison d’être joignable depuis Internet.

K08, le mouvement latéral du cluster vers le cloud. C’est l’entrée la plus utile de l’édition, parce qu’elle nomme la frontière que les équipes oublient : celle entre le cluster et le compte cloud qui l’héberge. Trois mécanismes y conduisent, et les trois sont des réglages par défaut.

Le premier est le rôle de nœud trop permissif : dans beaucoup de configurations initiales, les nœuds de travail reçoivent un rôle unique et large, et tout pod qui tourne sur un nœud hérite de ces droits. Qui obtient une exécution dans n’importe quel conteneur du nœud peut en récupérer les identifiants. Le deuxième est le stockage d’identifiants cloud statiques et à longue durée de vie dans des secrets Kubernetes, des ConfigMap ou des images de conteneur. Le troisième est l’accès non restreint au service de métadonnées de l’instance, joignable sur une adresse spéciale depuis les nœuds, et qui délivre les identifiants temporaires associés au rôle du nœud — les pods y accèdent souvent par défaut.

La contre-mesure recommandée est claire : lier l’identité cloud au compte de service Kubernetes plutôt qu’au nœud, mécanisme que les trois grands fournisseurs proposent sous des noms différents, et bloquer l’accès des pods au service de métadonnées. Un pod obtient alors des identifiants courts et limités à son rôle, indépendamment de la machine qui l’exécute. Le site traite le versant identités dans les identifiants de chaîne d’intégration et l’attaque sur un jeton de compte de service Kubernetes.

Ce qui a bougé, et ce qui a disparu

L’autorisation monte de la troisième à la deuxième place, en changeant de nom : « Overly Permissive RBAC Configurations » devient « Overly Permissive Authorization Configurations ». L’élargissement est volontaire — le contrôle d’accès par rôles n’est plus le seul mécanisme en jeu — et le sujet reste le même : un cluster-admin distribué par commodité, des caractères génériques dans les verbes et les ressources, un compte de service autorisé à lire tous les secrets du cluster. Le contrôle d’accès par rôles et l’admission control sont traités à part sur le site.

Les secrets passent de la huitième à la troisième place. La remontée est méritée : dans Kubernetes, un objet Secret est encodé, pas chiffré, et quiconque peut le lire l’a lu. Le sujet déborde du cluster, puisque ce qu’il faut c’est une source externe de secrets, une injection à la demande et une rotation testée — ce que décrit l’architecture de gestion de secrets distribuée.

La segmentation réseau monte de la septième à la cinquième place. Dans un cluster sans politique réseau, tout pod parle à tout pod : c’est le comportement par défaut, et c’est aussi ce qui transforme la compromission d’un conteneur périphérique en accès à la base de données. Déployer une NetworkPolicy et le fonctionnement des interfaces réseau de conteneurs couvrent le mécanisme.

La journalisation tombe de la cinquième à la dixième place, et c’est le mouvement qu’il faut lire avec méfiance. Rien n’indique que le sujet soit mieux traité ; il est simplement moins bien défendu dans un classement où deux entrées nouvelles sont entrées par le haut. Un cluster sans journal d’audit exploitable ne permet ni de constater une compromission ni de la raconter après coup, ce que développe la journalisation d’audit immuable.

Deux entrées de 2022 fusionnent en K07 : « Misconfigured Cluster Components » et « Outdated and Vulnerable Kubernetes Components ». Le regroupement tient debout, puisque les deux se traitent au même endroit — durcissement des composants, qui ne sont pas livrés durcis par défaut, et application des correctifs, en sachant que Kubernetes amont offre environ quatorze mois de support par version. L’audit et le durcissement d’un cluster décrivent la démarche.

Et la chaîne d’approvisionnement disparaît. « Supply Chain Vulnerabilities » occupait la deuxième place en 2022 ; elle n’a plus d’entrée propre en 2025. C’est l’écart le plus frappant avec les autres référentiels de la famille, où ce sujet a au contraire gagné du terrain — le Top 10 web lui a créé sa catégorie A03 la même année. L’interprétation la plus charitable est que le sujet a migré vers les référentiels qui le traitent mieux, le Top 10 open source et le Top 10 CI/CD, et qu’une liste consacrée au cluster n’avait pas à redire ce qu’ils disent. L’interprétation prudente est qu’un cluster qui exécute des images non vérifiées reste exposé, quelle que soit la liste qui le dit, et que la généalogie des images de base reste un sujet à part entière.

Un référentiel utile, à citer avec sa maturité

Trois points de forme, parce qu’ils décident de ce qu’on peut faire de ce document.

Le projet est classé Incubator par l’OWASP, le niveau le plus bas de ses quatre paliers. Ce n’est pas un jugement de qualité — les responsables du projet sont des chercheurs reconnus du domaine, et le contenu technique est de bon niveau — mais une indication sur l’engagement de la fondation quant à son entretien. La page du projet invite d’ailleurs explicitement à ouvrir des tickets pour corriger la liste de 2025, ce qui est le signe d’un document vivant plutôt que figé.

La licence est CC BY-NC-SA 4.0, avec une clause non commerciale, là où le Top 10 web est diffusé en CC BY-SA 4.0 sans cette restriction. Le détail n’a aucune importance pour une équipe qui lit le document, et une grande pour qui veut le redistribuer dans une offre de service.

Enfin, le référentiel se présente lui-même comme une liste priorisée que les auteurs espèrent adosser un jour à des données collectées auprès d’organisations de maturités diverses. Ce n’est pas encore le cas : l’ordre vient du jugement des responsables du projet, pas d’une mesure. Comme toujours, cela n’invalide rien et change la façon de citer — la question est traitée dans la page chapeau des Top 10 de l’OWASP.

Reste le point commun aux dix entrées, et il vaut d’être dit en clair : aucune ne décrit une vulnérabilité de Kubernetes. Ce sont dix façons de configurer de travers un système qui fait exactement ce qu’on lui demande. Les correctifs se trouvent dans des fichiers de configuration, pas dans des versions, et c’est pour cette raison que K04, l’application de politiques au niveau du cluster, est l’entrée qui conditionne toutes les autres : sans mécanisme qui refuse une configuration non conforme à l’admission, les neuf autres risques reviennent au premier déploiement pressé.

🐝 Ce qui arrive si on s’en passe

Sans restriction d’accès aux interfaces du cluster, un jeu d’identifiants fuité dans un dépôt public s’utilise depuis n’importe où : il n’y a pas de position réseau à conquérir, et le point d’entrée de version répond sans authentification à qui cherche une cible. Sans identité cloud attachée au compte de service, tout conteneur d’un nœud hérite du rôle du nœud et le service de métadonnées lui délivre les identifiants correspondants : la compromission d’un pod périphérique devient un accès au compte cloud, et les journaux cloud attribuent l’action au nœud, pas au conteneur fautif. Sans politique réseau, tout pod joint tout pod par défaut, et un conteneur exposé atteint la base de données sans franchir aucun contrôle. Sans secrets tenus hors du cluster, un objet encodé en base 64 passe pour chiffré, et qui obtient le droit de lecture obtient le mot de passe en clair. Sans application de politiques à l’admission, chaque correctif de configuration est défait au déploiement suivant, et le cluster revient à son état par défaut sans que personne ne l’ait décidé.

🦫 Explication de la marmotte 🍫

Kubernetes est un logiciel qui gère un parc de programmes empaquetés dans des conteneurs : il choisit sur quelle machine chacun s’exécute, lui attribue des droits, lui fournit ses mots de passe et organise les échanges entre eux. Une association internationale de spécialistes publie une liste des dix problèmes de sécurité les plus courants dans ce type d’installation. La version actuelle date de 2025, la précédente de 2022.

Le point important est qu’aucun de ces dix problèmes n’est un défaut du logiciel lui-même. Ce sont des réglages. Kubernetes n’est pas livré réglé de façon prudente : il est livré réglé de façon pratique, et c’est à l’équipe qui l’installe de resserrer. Beaucoup ne resserrent pas, ou resserrent une fois puis laissent les déploiements suivants tout défaire.

Deux problèmes sont nouveaux dans cette version. Le premier est que les commandes du système sont souvent accessibles depuis Internet, sans aucune limitation d’origine : plus d’un million de ces points de commande sont joignables publiquement dans le monde. Le second est le passage du parc de conteneurs vers le compte d’hébergement qui l’abrite. Quand un conteneur est compromis, il peut souvent récupérer les droits de la machine qui l’exécute, et ces droits permettent d’atteindre les bases de données et les espaces de stockage du fournisseur d’hébergement.

Les autres problèmes concernent des droits accordés trop largement, des mots de passe mal rangés, l’absence de cloisonnement entre programmes, des composants non durcis ou non mis à jour, et des enregistrements d’activité trop pauvres pour reconstituer ce qui s’est passé après un incident.

Pages voisines

OWASP Kubernetes Top 10 2025 : les dix risques d'un cluster

Elle cite

: les deux pages se citent l’une l’autre.