AW-9
La clé de l'administrateur ouvre le compte entier
L'authentification forte existe, mais elle n'est exigée que sur la console. Aucune politique ne l'impose sur l'API.
2
clusters, deux architectures opposées
37
défauts ouverts, sur 48 constats. Les 11 autres sont
des points forts, des notes de méthode ou des corrections déjà faites
19
exécutions de scénarios d'attaque, 10 scénarios
38
actions de remédiation priorisées
Le verdict
Les deux clusters bloquent une partie des attaques, aucun ne les reconnaît comme des attaques, et seul le cluster managé en garde la trace.
Chaque scénario a été jugé sur ces trois questions, et sur elles seules : est-il bloqué ? est-il détecté ? en reste-t-il une trace ?
| Managé (EKS) | Auto-hébergé (kubeadm) | |
|---|---|---|
| Bloqué ? | 5 scénarios sur 9 | 2 sur 9 |
| Détecté ? | aucune détection d'attaque | aucune détection d'attaque |
| Tracé ? | 9 sur 9, et la trace survit à la destruction du cluster | aucune, 0 sur 9 |
La ligne Tracé est l'écart le plus net de toute la campagne, et le seul endroit où les deux architectures ne se valent pas du tout.
« Aucune détection » ne veut pas dire « aucun signal ». Trois scénarios ont produit quelque chose : un avertissement d'admission des deux côtés, et sur le managé un appel d'API journalisé sans son exécution. Aucun n'est une alerte, aucun ne nomme une attaque, aucun n'aurait réveillé qui que ce soit.
Deux architectures qui n'ont presque rien en commun, et le même trou : la détection à l'exécution. Quand un défaut se répète sur deux infrastructures d'origines différentes, ce n'est plus un accident de configuration, c'est une habitude de conception.
Ce que l'audit m'a appris
Je pensais découvrir où mes clusters étaient faibles. Les constats qui m'ont le plus servi ne sont pas ceux qui pointaient une absence, mais ceux qui pointaient une protection présente, qui ne protégeait pas.
- Un contrôleur GitOps que je prenais pour une sentinelle, et qui ne signale jamais ce qu'il n'a pas déployé lui-même. Testé sur les deux clusters, aux réglages opposés, même résultat.
- Un masquage de données sensibles qui cache ce que mes dépôts publics affichent déjà.
- Un bot de mise à jour qui suit mes images et mes dépendances, mais pas la version de mon cluster.
Chaque fois, j'avais un garde-fou. Chaque fois, je n'avais jamais vérifié qu'il mordait. Un garde-fou écrit n'est pas un contrôle. Un contrôle, c'est quelque chose qu'on a vu refuser.
Les trois risques critiques
AW-2
Une clé d'intégration continue donne le cluster, puis le compte
Un chemin d'escalade complet, du pipeline jusqu'à l'administration du compte cloud, sans qu'aucun service ne le détecte.
C-U
Le contrôleur GitOps est administrateur du cluster
Compromettre le dépôt qu'il synchronise ferme la chaîne jusqu'à root sur les nœuds. Chaque maillon a été mesuré séparément.
Trois autres risques élevés complètent ce tableau, et deux ont été délibérément écartés du classement avec leur argument. Le détail est en section 0 du rapport.
La méthode
Périmètre gelé à une date écrite. Une preuve rejouable derrière chaque constat. Quatre référentiels, appliqués en cinq passes : CIS l'est à deux niveaux, le cluster et le compte cloud. Trois sont outillés, le quatrième sert de relecture finale sur les constats déjà écrits.
| Référentiel | Question posée | Outil |
|---|---|---|
| CIS Kubernetes Benchmark | ma configuration s'écarte-t-elle de la recommandation ? | kube-bench |
| CIS AWS Foundations | idem, au niveau du compte cloud | prowler |
| MITRE ATT&CK for Containers | quels chemins d'attaque mon installation laisse-t-elle ouverts ? | kubescape + jeu manuel |
| NSA/CISA Hardening Guide | mes conteneurs et mon réseau sont-ils durcis ? | kubescape |
| OWASP Kubernetes Top 10 (2025) | ai-je un angle mort ? | relecture manuelle |
Un rapport qui garde tout ce que ses outils produisent n'est pas un audit, c'est un export. Six familles de résultats ont été rejetées après vérification. Sans ce tri, ce rapport aurait annoncé vingt-trois conteneurs tournant en root, et 157 problèmes sur le compte cloud là où les mêmes lignes ne recouvrent que 41 contrôles distincts.
La première affirmation est fausse. La seconde est un chiffre exact lu de travers, ce qui est plus insidieux : il se vérifie, il se cite, et il ne veut pas dire ce qu'il paraît dire.
Lire le rapport
Environ cent pages : périmètre et méthode, architecture des deux clusters, les 48 constats par domaine, les scénarios purple team, un comparatif managé contre auto-hébergé sur six axes, et le plan de remédiation.
Version assainie : les identifiants de compte et les noms de ressources et de dépôts sont remplacés par des marqueurs stables. Ce qui est conservé l'est délibérément, et le rapport dit pourquoi.