Surface d'attaque du cluster

Pourquoi cartographier avant de durcir

On ne sécurise correctement que ce que l'on a préalablement cartographié. Un cluster Kubernetes n'est pas un périmètre unique avec une frontière nette : c'est un assemblage de composants distincts — API server, etcd, kubelet, container runtime, CNI, registres d'images — chacun avec son propre modèle de menace, ses propres portsportRéseauxNuméro sur 16 bits qui désigne l'application destinataire sur une machine. Les ports 0 à 1023 sont réservés aux services système, comme 443 pour HTTPS.Voir dans le glossaire, ses propres identités. Traiter « la sécurité de Kubernetes » comme un bloc monolithique conduit presque systématiquement à sur-investir sur un composant déjà correctement protégé (typiquement l'API server, documenté et scruté) et à négliger des composants moins visibles mais tout aussi critiques (kubelet, etcd, la chaîne d'approvisionnement des images).

Ce chapitre suit le chemin qu'emprunterait un attaquant : de l'extérieur du cluster vers le control plane, puis du control plane vers les nodes, puis des nodes vers les workloads et leur provenance. Chaque section identifie le composant, son exposition réelle, les erreurs de configuration récurrentes et un exemple concret d'exploitation.

L'API server : point d'entrée unique

L'API server est le seul composant du control plane censé être directement joignable depuis l'extérieur du cluster. Tout — kubectl, les contrôleurs, le scheduler, kubelet lui-même — transite par lui. Cette centralisation est une force pour l'audit (un seul point de journalisation) mais aussi la cible prioritaire de tout attaquant : compromettre l'API server, c'est potentiellement compromettre l'ensemble du cluster.

Trois couches protègent l'API server, et chacune peut échouer indépendamment :

• Authentification — certificats clients, tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire de service account, ou intégration OIDC avec un fournisseur d'identité externe. Un cluster géré (EKS, GKE, AKS) délègue souvent cette étape au cloud provider, mais un cluster auto-hébergé mal configuré peut laisser des certificats à durée de vie excessive ou des tokens statiques non rotés.
• Autorisation — RBAC détermine ce qu'une identité authentifiée a le droit de faire. C'est ici que se logent la majorité des erreurs de configuration : des ClusterRoleBinding trop larges accordant cluster-admin à des service accounts applicatifs, ou des rôles autorisant create sur pods/exec, ce qui équivaut de facto à une exécution de commande arbitraire sur un node.
• Admission control — dernière étape avant la persistance en etcd. Les admission controllers (validants et mutants) peuvent bloquer des pods privilégiés, forcer des contextes de sécurité, ou vérifier la provenance des images. Un cluster sans Pod Security Admission ni policy engine (Kyverno, OPA Gatekeeper) laisse passer des définitions de pods qui montent /var/run/docker.sock ou s'exécutent en privileged: true sans aucun garde-fou.

Une erreur RBAC ne se voit pas dans les logs applicatifs. Elle se voit en auditant les RoleBinding et ClusterRoleBinding existants. kubectl auth can-i --list --as=system:serviceaccount:<ns>:<sa> est la commande la plus utile et la plus sous-utilisée d'un audit Kubernetes.

etcd : la base de données qui contient tout

etcd stocke l'intégralité de l'état du cluster : définitions de ressources, ConfigMaps, et Secrets. Un point souvent mal compris : par défaut, Kubernetes ne chiffre pas les Secrets au repos dans etcd. Ils y sont stockés encodés en base64, ce qui n'est pas du chiffrementchiffrementCybersécuritéTransformation d'une donnée lisible en une forme inintelligible à l'aide d'une clé. Le destinataire disposant de la clé peut retrouver le message original. C'est le socle de la confidentialité sur Internet.Voir dans le glossaire — c'est un encodage réversible en une ligne de commande.

Accéder directement à etcd (via son API sur le port 2379, ou via un accès disque aux fichiers du datastore) revient à disposer d'un accès cluster-admin sans passer par l'API server, donc sans laisser de trace dans son audit log. C'est l'une des raisons pour lesquelles etcd ne devrait jamais être accessible depuis un réseau autre que celui du control plane, et pourquoi son chiffrement au repos (EncryptionConfiguration avec un provider KMS) devrait être une exigence de base plutôt qu'une option avancée.

Une sauvegarde etcd (snapshot) contient les mêmes donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire que la base vive, y compris les Secrets en clair (ou chiffrés selon la configuration active au moment du backup). Une sauvegarde etcd exportée vers un stockage objet mal restreint est une fuite de secrets potentielle aussi grave qu'un accès direct au cluster.

Scheduler et controller-manager : cibles secondaires mais réelles

Le scheduler et le controller-manager reçoivent moins d'attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire que l'API server ou etcd, en partie parce qu'ils n'exposent pas d'API destinée à un usage externe direct. Cela ne signifie pas qu'ils sont sans intérêt pour un attaquant. Le controller-manager exécute les boucles de réconciliation qui créent, modifient et suppriment des ressources en continu — un accès à son identité (généralement via son propre kubeconfig et ses certificats) permettrait d'influencer directement l'état du cluster sans passer par l'API server côté utilisateur. Le scheduler, de son côté, décide sur quel node chaque pod sera placé ; une compromission de sa logique de décision (via un scheduler personnalisé malveillant substitué au scheduler par défaut, par exemple) pourrait forcer le placement de workloads sensibles sur des nodes déjà compromis. Ces deux composants tournent généralement en local sur les nodes du control plane et ne devraient jamais être exposés sur une interface réseau accessible depuis l'extérieur du cluster.

Les nodes : kubelet et container runtime

Si l'API server est le point d'entrée logique, les nodes sont le point d'exécution réel. Deux composants y méritent une attention particulière.

kubelet expose une API HTTP sur le port 10250 de chaque node. Cette API permet, entre autres, d'exécuter des commandes dans un conteneur (exec), de récupérer des logs, ou de lister les pods locaux. Historiquement, de nombreux clusters — en particulier des déploiements auto-hébergés antérieurs à un durcissement explicite — exposaient cette API sans authentification ni autorisation. Un attaquant disposant d'un accès réseau au port 10250 pouvait alors exécuter des commandes arbitraires dans n'importe quel pod du node, sans jamais passer par l'API server ni RBAC.

Des campagnes de scan automatisé sur les plages d'adresses cloud publiques recherchent spécifiquement des kubelets exposés sur le port 10250 avec l'anonymous-auth activée. Le scénario observé le plus fréquemment : déploiement de conteneurs de minage de cryptomonnaie directement via l'API kubelet, sans qu'aucune trace n'apparaisse dans les logs d'audit de l'API server, puisque celui-ci n'a jamais été sollicité.

Le container runtime (containerd, CRI-O — Docker Engine n'est plus utilisé directement depuis la dépréciation de dockershim) est la frontière technique entre le conteneur et le noyau de l'hôte. Un conteneur n'est pas une machine virtuelle : il partage le noyau du node. Un pod démarré avec privileged: true, ou avec des capacités Linux excessives (CAP_SYS_ADMIN, par exemple), ou montant /proc ou le socketsocketRéseauxAssociation d'une adresse IP et d'un port, qui identifie une extrémité de communication. Le quadruplet formé par les deux sockets d'une connexion la distingue de toutes les autres.Voir dans le glossaire du runtime, dispose d'un chemin direct vers une évasion de conteneur (container breakout). Ce n'est pas une vulnérabilité du runtime lui-même : c'est une conséquence directe d'une configuration de sécurité de pod trop permissive.

kube-proxy complète ce trio en traduisant les objets Service en règles de routage locales (iptables ou IPVS selon le mode configuré). Il n'expose généralement pas d'API destinée à un usage externe, mais une mauvaise configuration de son mode de fonctionnement peut ouvrir des ports de nodePort plus largement que prévu, ou laisser un service interne accessible depuis un réseau qui ne devrait pas l'atteindre. Il constitue rarement un point d'entrée initial, mais fait partie intégrante de la surface réseau du node au même titre que le CNI.

Le réseau : CNI et l'absence de segmentation par défaut

Un point structurel mal connu des équipes qui découvrent Kubernetes : par défaut, tous les pods d'un cluster peuvent communiquer entre eux, sans restriction, quel que soit leur namespace. Il n'existe pas de segmentationChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire réseau implicite entre une application front-end et une base de données critique, sauf si l'on définit explicitement des NetworkPolicy.

Cette absence de segmentation par défaut a une conséquence directe sur le mouvement latéral : un attaquant qui compromet un pod peu sensible (par exemple via une dépendance applicative vulnérable) peut, en l'absence de NetworkPolicy, sonder et atteindre directement n'importe quel autre service du cluster, y compris ceux situés dans des namespaces différents.

Encore faut-il que le plugin CNI déployé (Calico, Cilium, Weave Net, entre autres) supporte effectivement l'application des NetworkPolicy — ce n'est pas garanti par toutes les implémentations, notamment certaines configurations réseau cloud simplifiées à l'extrême.

Une politique de départ raisonnable consiste à définir, pour chaque namespace applicatif, une NetworkPolicy de type default deny en ingress, puis à autoriser explicitement les flux nécessaires. Cela transforme la segmentation d'un état « tout est permis sauf exception » vers « rien n'est permis sauf autorisation », ce qui est la posture attendue en environnement de production.

Identités : service accounts et principe du moindre privilège

Chaque pod se voit attribuer un service account, par défaut le service account default du namespace s'il n'en spécifie pas explicitement. Ce service account est monté automatiquement comme token dans le pod (sauf si automountServiceAccountToken: false est explicitement défini), ce qui signifie que tout processus s'exécutant dans le pod — y compris du code tiers vulnérable — hérite des permissions RBAC associées à ce service account.

La combinaison la plus dangereuse observée en audit : un service account applicatif lié, directement ou via un rôle hérité, à des permissions larges (get/list/watch sur les Secrets de tout le cluster, ou pire, des droits de création de ClusterRoleBinding). Une vulnérabilité applicative classique (désérialisation, injection de commande, SSRF exploitant l'API Kubernetes locale) devient alors un chemin direct vers une élévation de privilèges cluster-wide.

L'accès à l'API Kubernetes depuis l'intérieur d'un pod ne nécessite aucun outil spécifique : le token du service account monté et l'adresse kubernetes.default.svc suffisent à interroger l'API server avec curl. Une SSRF qui atteint cette adresse depuis un pod insuffisamment restreint donne accès à tout ce que le service account du pod est autorisé à faire.

La chaîne d'approvisionnement (supply chain)

La surface d'attaque ne se limite pas à l'exécution : elle commence à la construction. Une image de conteneur assemble des couches provenant potentiellement de sources multiples — image de base publique, dépendances applicatives, artefacts de build. Chacune de ces couches peut introduire une vulnérabilité connue, une dépendance compromise, ou plus rarement une porte dérobée délibérée.

Les points de contrôle disponibles à ce niveau :

Un registre d'images accessible en écriture sans authentification forte, ou une politique de tag mutable (le tag latest pouvant pointer vers un contenu différent à chaque pull), casse la traçabilité entre ce qui a été audité et ce qui s'exécute réellement en production. C'est un vecteur de compromission de la chaîne d'approvisionnement à part entière, indépendant de toute vulnérabilité applicative.

Un imagePullPolicy: Always combiné à un tag mutable signifie que le contenu exécuté peut changer entre deux redémarrages du même pod, sans modification de son manifeste. C'est un comportement pratique en développement, mais incompatible avec une exigence d'auditabilité en production — préférer un digest immuable (image@sha256:...) pour les déploiements critiques. Un registre qui autorise l'écrasement d'un tag déjà publié rend impossible la corrélation entre le rapport de scan produit en CI et l'artefact réellement exécuté en production : deux pulls successifs du même tag peuvent renvoyer deux contenus différents, sans qu'aucune alerte ne soit levée côté cluster.

Checklist de cartographie avant durcissement

Avant d'appliquer des contrôles spécifiques (objet des chapitres suivants), il est utile de répondre factuellement aux questions suivantes pour chaque cluster :

• L'API server est-il accessible depuis un réseau autre que celui des opérateurs autorisés ?
• etcd est-il chiffré au repos, et son accès réseau est-il restreint au control plane uniquement ?
• L'API kubelet (port 10250) exige-t-elle une authentification et une autorisation sur chaque node ?
• Existe-t-il des NetworkPolicy de type default-deny sur les namespaces contenant des données sensibles ?
• Des service accounts applicatifs disposent-ils de permissions RBAC plus larges que leur usage réel ?
• Les images déployées proviennent-elles d'un registre de confiance, avec vérification de signature en amont de l'admission ?
• Un admission controller bloque-t-il les pods privilégiés ou les montages de sockets sensibles ?

Cette liste n'est pas exhaustive, mais chaque réponse négative correspond à un vecteur de compromission documenté et régulièrement exploité en conditions réelles. Les chapitres suivants détaillent les mécanismes de contrôle (RBAC, Pod Security Admission, NetworkPolicy, gestion des secrets) permettant de répondre positivement à chacune de ces questions.

Ce qu'il faut retenir

La surface d'attaque d'un cluster Kubernetes n'est pas un périmètre unique : c'est un ensemble de composants hétérogènes — API server, etcd, kubelet, container runtime, CNI, registres d'images — dont chacun peut être compromis indépendamment des autres. Une posture de sécurité efficace commence par cartographier précisément ces composants et leur exposition réelle, plutôt que d'appliquer des contrôles génériques sans savoir quel vecteur ils couvrent effectivement.