Pourquoi sécuriser Kubernetes

Pourquoi ce chapitre est le plus utile

Un cluster Kubernetes qui fonctionne n'est pas un cluster sécurisé. C'est la confusion la plus répandue chez les équipes qui migrent vers Kubernetes en venant d'une infrastructure plus simple — machines virtuelles, PaaS classique : elles transposent l'idée qu'un système qui répond correctement aux requêtes est un système sain, alors que Kubernetes sépare radicalement les deux notions. Un cluster peut servir du trafic sans erreur pendant des mois avec un tableau de bord accessible sans authentification, des pods tournant en mode privilégié, et un compte de service disposant de droits d'administration complets sur le cluster. Rien dans le comportement observable ne signale ces failles tant que personne ne les exploite.

Ce chapitre pose le cadre avant d'entrer dans la technique : ce que Kubernetes sécurise nativement, ce qu'il ne sécurise pas du tout, et où passe la frontière de responsabilité quand le cluster est géré par un fournisseur cloud plutôt qu'auto-hébergé. Les neuf chapitres suivants détaillent chacun un mécanisme précis — contrôle d'accès, isolation réseau, gestion des secrets, admission control, chaîne d'approvisionnement des images, audit et détection. Celui-ci répond à la question qui précède toutes les autres : pourquoi consacrer un budget et un temps d'ingénierie dédiés à un sujet que beaucoup d'équipes traitent encore comme secondaire, au motif que « le cluster tourne bien ».

Kubernetes n'est sécurisé par défaut sur presque aucune dimension critique. L'API server accepte, une fois l'authentification passée, des permissions larges tant qu'aucune politique RBAC restrictive n'a été définie explicitement. Les pods d'un même cluster peuvent par défaut communiquer entre eux sans aucune restriction, y compris à travers des namespaces différents. Aucune installation standard n'impose de politique de sécurité contraignante au démarrage. Chaque garde-fou présenté dans cette formation doit être activé explicitement — il ne s'active jamais tout seul, et une installation par défaut reste ouverte sur pratiquement tous les axes qui comptent.

Le modèle de responsabilité partagée

La quasi-totalité des clusters de production tournent aujourd'hui sur une offre managée — Amazon EKS, Google GKE, Azure AKS ou équivalent. Cela déplace une partie réelle du risque vers le fournisseur, mais pas la totalité, et l'erreur la plus coûteuse consiste à croire que « managé » signifie « sécurisé de bout en bout ».

Ce que le fournisseur prend en charge sur une offre managée typique :

• La disponibilité et le patch de sécurité du plan de contrôle — API server, etcd, scheduler, controller-manager
• L'isolation physique et l'infrastructure réseau du datacenter sous-jacent
• Dans la plupart des offres, le durcissement de base de l'image système des nœuds, avec des correctifs appliqués automatiquement ou proposés à l'exploitant

Ce qui reste entièrement de votre responsabilité, quel que soit le fournisseur choisi :

• Les identités et les permissions RBAC à l'intérieur du cluster
• Le contenu des images de conteneurs et leurs vulnérabilités connues
• La configuration des secrets, leur 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 au repos et leur rotation
• L'isolation réseau entre charges applicatives, via les NetworkPolicy
• Le contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire de sécurité de chaque pod — utilisateur non-root, capacités Linux limitées, système de fichiers en lecture seule quand c'est possible
• La supervision et la réponse à incident sur ce qui se passe à l'intérieur du cluster

Cette ligne de partage explique un fait constant dans les rapports d'incident cloud-native publiés ces dernières années : l'écrasante majorité des compromissions documentées n'exploite pas une faille du fournisseur cloud, mais une erreur de configuration côté client — un rôle RBAC trop large accordé « pour aller vite », une image construite depuis une base obsolète, un secret monté en variable d'environnement puis journalisé par erreur par l'application elle-même. Le fournisseur peut patcher son plan de contrôle en quelques heures ; il ne peut rien faire contre une politique d'accès que vous avez vous-même configurée de façon trop large.

<rect x="55" y="186" width="370" height="52" rx="8" fill="currentColor" fill-opacity="0.08" stroke="currentColor" stroke-width="1.5"/>
<text x="240" y="207" text-anchor="middle" font-weight="700">Infrastructure physique</text>
<text x="240" y="225" text-anchor="middle" fill-opacity="0.75">Hyperviseur, datacenter, isolation réseau matérielle</text>

<rect x="55" y="252" width="370" height="52" rx="8" fill="currentColor" fill-opacity="0.08" stroke="currentColor" stroke-width="1.5"/>
<text x="240" y="273" text-anchor="middle" font-weight="700">Runtime des nœuds managés</text>
<text x="240" y="291" text-anchor="middle" fill-opacity="0.75">Image système hôte, correctifs kernel (selon offre)</text>

<rect x="535" y="186" width="370" height="52" rx="8" fill="currentColor" fill-opacity="0.16" stroke="currentColor" stroke-width="1.5"/>
<text x="720" y="207" text-anchor="middle" font-weight="700">Images et charge applicative</text>
<text x="720" y="225" text-anchor="middle" fill-opacity="0.8">CVE des images, secrets, dépendances</text>

<rect x="535" y="252" width="370" height="52" rx="8" fill="currentColor" fill-opacity="0.16" stroke="currentColor" stroke-width="1.5"/>
<text x="720" y="273" text-anchor="middle" font-weight="700">Politiques réseau et isolation</text>
<text x="720" y="291" text-anchor="middle" fill-opacity="0.8">NetworkPolicy, segmentation entre namespaces</text>

<rect x="535" y="318" width="370" height="52" rx="8" fill="currentColor" fill-opacity="0.16" stroke="currentColor" stroke-width="1.5"/>
<text x="720" y="339" text-anchor="middle" font-weight="700">Configuration des workloads</text>
<text x="720" y="357" text-anchor="middle" fill-opacity="0.8">Contexte de sécurité, privilèges, quotas</text>

Sur un cluster auto-hébergé — kubeadm, déploiement on-premise, cluster de développement monté à la main — la ligne de partage se déplace entièrement vers vous : vous héritez aussi de la sécurisation d'etcd, du chiffrement des communications entre composants du plan de contrôle, et de la rotation des certificats internes. C'est un travail d'exploitation à part entière, distinct de la sécurité applicative traitée dans le reste de cette formation, et généralement déconseillé sans une équipe d'exploitation dédiée et expérimentée sur ce périmètre précis.

Anatomie d'un incident Kubernetes typique

Les rapports d'incident publiés par les équipes de réponse convergent vers un nombre restreint de scénarios récurrents, presque toujours combinés entre eux plutôt qu'isolés les uns des autres. Comprendre ces scénarios avant d'apprendre les contre-mesures permet de saisir pourquoi chaque mécanisme technique existe, plutôt que de le traiter comme une case à cocher.

Tableau de bord ou API exposée sans authentification. Le cas le plus documenté publiquement reste la compromission par minage de cryptomonnaie d'un cluster dont le tableau de bord d'administration ou l'API du kubelet étaient accessibles depuis internet sans authentification forte. L'attaquant scanne les 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 ouverts, trouve une API qui répond, et déploie directement ses propres conteneurs via les identifiants par défaut ou l'absence totale de contrôle d'accès.

RBAC trop permissif accordé « temporairement ». Un compte de service créé pour une tâche de déploiement continu reçoit un rôle d'administration complet du cluster parce que c'est plus rapide que de définir un rôle précis, avec l'intention de le restreindre plus tard. Ce « plus tard » n'arrive presque jamais. Si ce compte est compromis via une dépendance vulnérable dans le pipeline, l'attaquant hérite immédiatement d'un accès total au cluster.

Secrets exposés en clair. Des identifiants de base de 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 ou des clés d'API stockés dans une ressource de configuration ordinaire au lieu d'un objet Secret dédié, ou dans un Secret non chiffré au repos, visibles par quiconque dispose d'un accès en lecture au namespace — un périmètre souvent beaucoup plus large que ce que l'équipe qui les a créés avait anticipé au moment du déploiement initial.

Conteneurs privilégiés ou évasion de conteneur. Un pod démarré en mode privilégié, ou avec une capacité Linux élevée accordée sans justification technique réelle, donne à un attaquant qui compromet l'application un chemin direct vers le nœud hôte, puis potentiellement vers l'ensemble du cluster par rebond.

Image compromise ou vulnérable. Une image de base obsolète embarquant une vulnérabilité critique connue, ou pire, une image récupérée depuis un registre public sans vérification de provenance ni scan préalable, introduit une faille directement en production dès le premier déploiement, souvent sans que personne ne s'en aperçoive avant un audit ou un incident.

En 2018, un cluster Kubernetes exploité en interne par une entreprise technologique majeure a été compromis via un tableau de bord d'administration laissé accessible sans mot de passe. Les attaquants n'ont eu besoin d'aucun exploit sophistiqué : l'API répondait, elle acceptait des requêtes de déploiement, et ils ont simplement demandé au cluster de faire tourner leurs propres conteneurs de minage de cryptomonnaie. Cet incident illustre un principe qui revient dans presque tous les cas documentés depuis : la compromission ne nécessite quasiment jamais un exploit zero-day sur Kubernetes lui-même — elle exploite une configuration ouverte par défaut, ou laissée telle quelle par négligence ou par manque de temps.

Les surfaces d'attaque spécifiques à Kubernetes

Kubernetes introduit des composants et des surfaces d'attaque qui n'existent pas, ou pas sous cette forme, dans une infrastructure plus traditionnelle fondée sur des machines virtuelles isolées.

Par défaut, tous les pods d'un cluster Kubernetes peuvent communiquer entre eux sans aucune restriction, quel que soit le namespace qui les héberge. Un pod compromis dans un environnement de test peut, en l'absence de NetworkPolicy, atteindre directement une base de données de production si les deux tournent sur le même cluster. Ce comportement n'est pas un bug : c'est le comportement natif du réseau Kubernetes tant qu'aucune politique explicite ne vient le restreindre. Le chapitre consacré à l'isolation réseau revient en détail sur ce point et sur sa mise en œuvre concrète.

Ce que couvre cette formation

Cette formation de dix chapitres suit une progression volontairement pratique, du contrôle d'accès jusqu'à la détection d'incident :

• Contrôle d'accès et RBAC — rôles, bindings, comptes de service, revue de permissions
• Isolation réseau — NetworkPolicy, segmentation par namespace, maillage de service
• Gestion des secrets — chiffrement au repos, intégration avec un gestionnaire externe
• Contexte de sécurité des pods — utilisateurs non-root, capacités Linux, quotas de ressources
• Admission control — validation et mutation automatique des ressources déployées
• Chaîne d'approvisionnement des images — scan de vulnérabilités, signature, registres de confiance
• Sécurité du plan de contrôle et d'etcd sur les clusters auto-hébergés
• Audit et journalisation — traçabilité des actions et détection d'anomalies
• Atelier de synthèse — durcissement complet d'un cluster de bout en bout, du déploiement initial à la revue finale

Chaque chapitre technique relie systématiquement le mécanisme présenté à un incident réel qu'il permet de prévenir, plutôt que de présenter une liste de bonnes pratiques hors contexte. C'est un choix pédagogique délibéré : retenir qu'il faut « activer les NetworkPolicy » compte moins que comprendre le scénario précis — mouvement latéral entre namespaces après compromission d'un pod exposé — que cette politique bloque concrètement une fois en place.

Si vous devez approfondir un seul chapitre avant tous les autres faute de temps, privilégiez celui consacré au RBAC. Une identité mal restreinte annule presque tous les autres contrôles mis en place ailleurs : un accès administrateur obtenu via une identité compromise permet de désactiver une NetworkPolicy, de lire un secret chiffré via l'API, ou de déployer un pod privilégié malgré les meilleures politiques d'admission. Le RBAC est le contrôle dont dépendent structurellement tous les autres.

Checklist de démarrage

Avant d'entrer dans le détail technique du chapitre suivant, voici les six vérifications à effectuer sur n'importe quel cluster existant pour évaluer rapidement son niveau d'exposition :

1. L'API server et le tableau de bord d'administration sont-ils accessibles uniquement depuis un réseau restreint, jamais directement depuis internet ?
2. Existe-t-il un ou plusieurs comptes de service disposant de droits d'administration complets sur le cluster sans justification documentée ?
3. Des NetworkPolicy sont-elles définies, ou tous les pods peuvent-ils communiquer librement entre eux par défaut ?
4. Les secrets sont-ils stockés dans des objets Secret dédiés et chiffrés au repos, plutôt que dans des ConfigMap ou des variables d'environnement en clair ?
5. Des pods tournent-ils en mode privilégié, ou avec des capacités Linux élevées, sans justification technique explicite et documentée ?
6. Les images déployées proviennent-elles d'un registre de confiance et ont-elles été scannées pour des vulnérabilités connues avant leur déploiement ?

Un « non » ou un « je ne sais pas » sur plusieurs de ces points est fréquent, y compris sur des clusters de production actifs depuis plusieurs années sans incident visible. Ce n'est pas une anomalie isolée : c'est le point de départ normal de cette formation, et la raison pour laquelle elle existe. Les neuf chapitres suivants traitent chacun un de ces axes en détail, avec des exemples de configuration concrets, des pièges récurrents et des critères de vérification directement applicables à votre propre cluster.