Audit Kubernetes : 7 contrôles pour sécuriser votre cluster

Kubernetes est une plateforme open source qui orchestre les applications conteneurisées : elle les déploie, répartit leur charge sur plusieurs serveurs, les redémarre en cas de panne et les met à jour sans interruption de service.
Conçue à l’origine par Google, elle est aujourd’hui proposée par la plupart des fournisseurs de cloud, y compris français.

Quelques termes reviennent tout au long d’un audit :

• Cluster : l’ensemble des serveurs pilotés par Kubernetes.
• Nœud : l’un de ces serveurs.
• Pod : la plus petite unité déployée, qui contient un ou plusieurs conteneurs.
• Espace de noms : une subdivision du cluster, qui sépare par exemple les environnements de test et de production.
• Compte de service : l’identité qu’utilise une application pour dialoguer avec Kubernetes.
• API Kubernetes : le point d’entrée par lequel passent toutes les commandes adressées au cluster.

Trois caractéristiques expliquent qu’un cluster mérite un examen spécifique, distinct de l’audit des serveurs ou des applications :

• Des réglages par défaut ouverts : sans règle réseau explicite, chaque pod peut communiquer avec tous les autres. Sans contrainte particulière, un conteneur peut s’exécuter avec les droits d’administrateur.
• Une configuration dispersée : droits, réseau, secrets, politiques de sécurité : chaque réglage vit dans un objet différent, souvent écrit par des personnes différentes.
• Une chaîne de déploiement qui pilote tout : avec une approche GitOps, le dépôt de code décrit l’état du cluster : qui contrôle ce dépôt, ou l’outil qui le synchronise, contrôle le cluster.

1. Les droits d’accès (RBAC)

Le contrôle d’accès par rôles détermine qui peut faire quoi dans le cluster.
L’audit recherche le rôle d’administrateur du cluster attribué trop largement, les comptes de service dotés de droits étendus, les jetons d’accès montés automatiquement dans des pods qui n’en ont pas besoin, et les droits de lecture sur les secrets accordés sans nécessité.

2. Le cloisonnement réseau

En l’absence de règles réseau, un attaquant qui compromet un seul pod peut atteindre la base de données, les services internes et parfois l’interface d’administration.
L’audit vérifie la présence de règles qui interdisent par défaut les échanges, puis autorisent uniquement les flux nécessaires, espace de noms par espace de noms.

3. La gestion des secrets

Les secrets Kubernetes sont simplement encodés, et leur chiffrement au repos dépend de la configuration du cluster.
L’audit vérifie ce chiffrement, le recours éventuel à un coffre-fort externe, et surtout l’absence de secrets écrits en clair dans les dépôts de code ou les fichiers de déploiement.

4. La sécurité des pods

Un conteneur exécuté en administrateur, en mode privilégié ou avec un accès au système de fichiers du serveur offre un tremplin vers le nœud entier.
Les Pod Security Standards de Kubernetes définissent trois niveaux d’exigence : l’audit mesure l’écart entre les pods en production et le niveau le plus strict.

5. Les images et leurs dépendances

Chaque image embarque un système et des bibliothèques, avec leurs vulnérabilités connues.
L’audit analyse les images déployées, l’origine des images de base, l’usage de versions figées plutôt que d’étiquettes mouvantes, et la présence d’une analyse automatique dans la chaîne de déploiement.

6. La chaîne GitOps et CI/CD

C’est souvent le maillon le plus exposé.
L’audit examine les droits sur l’outil de synchronisation (Argo CD ou équivalent) et son interface d’administration, la protection des branches qui déclenchent un déploiement, les variables secrètes de l’intégration continue, et les exécuteurs de pipelines, en particulier lorsqu’ils sont partagés entre projets ou lancés en mode privilégié.

7. L’accès à l’API et la journalisation

L’API de Kubernetes est la porte d’entrée du cluster.
L’audit vérifie qu’elle n’est pas exposée sans nécessité sur Internet, que l’authentification passe par le fournisseur d’identité de l’entreprise, avec des sessions et des jetons de durée limitée, et que les journaux d’audit de Kubernetes sont activés, conservés et exploitables.

Kubernetes dispose d’une fonction native de journalisation, les audit logs, qui enregistre les requêtes adressées à l’API : qui a fait quoi, sur quelle ressource et à quel moment.
on périmètre se règle par une politique d’audit, qui fixe le niveau de détail par type de requête.

Trop pauvre, la politique ne permet pas de reconstituer un incident ; trop bavarde, elle produit des volumes que personne n’exploite.
Un bon réglage enregistre en détail les actions sensibles (création de rôles, lecture des secrets, exécution de commandes dans un pod) et se contente des métadonnées pour le reste.

L’audit commence par un accès en lecture au cluster, aux dépôts de déploiement et à l’outil GitOps.
Des outils spécialisés passent ensuite la configuration au crible : vérification par rapport au référentiel CIS Kubernetes Benchmark, analyse de posture, recherche de vulnérabilités dans les images.

Ces outils produisent des centaines d’alertes, dont beaucoup sont sans conséquence dans votre contexte.
La revue experte les relie entre elles pour reconstituer de véritables chemins d’attaque : par exemple, une image vulnérable, exécutée en administrateur, dans un espace sans règle réseau, avec un jeton de compte de service aux droits étendus. Isolément, chaque point paraît mineur ; ensemble, ils mènent à la base de données.

Pour un cluster et son outil GitOps, l’examen demande environ une semaine.
La méthode d’audit en six étapes s’applique ensuite telle quelle : cotation des constats, plan de corrections, contrôles de suivi.

Un éditeur de logiciel de 40 personnes héberge sa plateforme sur un cluster Kubernetes managé chez un fournisseur de cloud français.
Les déploiements passent par GitLab et Argo CD.
Un client du secteur public exige un audit de sécurité avant de signer.

Les constats

31 constats, dont 4 critiques :

• le compte de service d’une application métier dispose du rôle d’administrateur du cluster, hérité d’un test jamais nettoyé,
• aucune règle réseau : la base de données de production est joignable depuis tous les pods, y compris le service exposé sur Internet,
• un exécuteur GitLab partagé, lancé en mode privilégié, permet à n’importe quel projet de prendre la main sur le nœud qui l’héberge,
• les identifiants du registre d’images sont écrits en clair dans un dépôt de déploiement.

Par ailleurs, 70 % des pods s’exécutent en administrateur, et les images en production cumulent 46 vulnérabilités critiques connues.

Les corrections

• Semaine 1 : retrait du rôle d’administrateur, exécuteur GitLab dédié et non privilégié, rotation des identifiants exposés.
• Sous 30 jours : règles réseau interdisant par défaut les échanges dans les espaces de production.
• Sous 60 jours : application du niveau le plus strict des Pod Security Standards en production, analyse des images intégrée au pipeline.

Le bilan au contrôle des trois mois

Les 4 constats critiques sont levés.
Les pods exécutés en administrateur passent de 70 % à moins de 10 %, et les vulnérabilités critiques dans les images de 46 à 3, toutes documentées avec un correctif planifié.
L’éditeur remet à son client le rapport de direction et le rapport de contrôle, et signe le contrat.

Qu’est-ce qu’un audit log Kubernetes ?

C’est le journal natif de Kubernetes qui enregistre les requêtes adressées à l’API du cluster : auteur, action, ressource et horodatage. Son niveau de détail se règle par une politique d’audit. Il ne faut pas le confondre avec l’audit de sécurité du cluster, dont il constitue l’un des points de contrôle.

Un cluster Kubernetes managé est-il sécurisé par défaut ?

Le fournisseur sécurise le plan de contrôle et l’infrastructure sous-jacente. Les droits d’accès, les règles réseau, les secrets, la configuration des pods et la chaîne de déploiement restent sous votre responsabilité : ce sont eux que l’audit examine.

Les outils automatiques suffisent-ils pour auditer un cluster ?

Ils sont indispensables pour couvrir l’ensemble de la configuration, mais ils produisent des centaines d’alertes sans hiérarchie liée à votre contexte. La revue experte relie ces alertes en chemins d’attaque réels et en tire un ordre de priorité.

À quelle fréquence auditer un cluster Kubernetes ?

Un audit complet par an constitue un bon rythme pour un cluster en production, complété par une analyse automatique continue dans la chaîne de déploiement. Une montée de version majeure ou l’arrivée de nouvelles équipes justifient un contrôle ciblé.