~10 minutes
Cet article fait partie de la série OWASP Top 10 Kubernetes 2026. Retrouvez le tableau de bord complet des dix risques et la matrice STRIDE sur la page d’entrée de la série.
K09 couvre le risque de ne rien voir. Pas une vulnérabilité dans le code, pas une configuration manquante : l’absence de visibilité sur ce qui se passe dans le cluster.
Note du PandaRedacteur: on ne peut voir que ce que l’on peut voir. (c) La truite.
Je reviens souvent sur un point que j’ai évoqué dans K01 : lors d’une réponse à incident sur un cluster Kubernetes sans audit log actif, on n’a que des traces réseau, des logs applicatifs et strictement rien sur ce qui s’est passé côté API Server. Reconstruire la chronologie d’un incident sur cette base, c’est du Coca et des pizzas pendant des nuits entières, et souvent on n’arrive de toute façon pas à une conclusion certaine.
L’absence d’observabilité n’est pas neutre : elle protège l’attaquant, pas le défenseur. Un intrus qui sait que ses actions ne sont pas loguées peut prendre son temps, effacer ses traces dans les applications et sortir proprement. Un intrus qui sait que chaque appel API est enregistré et corrélé dans un SIEM doit agir vite et bruyamment.
Vecteurs d’attaque
L’audit log absent
L’audit log de l’API Server est désactivé par défaut.
Note du PandaRedacteur : quand je lis cela dans la doc officielle, j’ai envie de manger le redacteur de la doc….
Sur un cluster où personne n’a explicitement activé --audit-policy-file, toute l’activité sur l’API Kubernetes (création de pods, lecture de secrets, modifications RBAC, execs dans des conteneurs) se passe sans trace.
Le problème se révèle lors des incidents : un attaquant qui a eu un accès RBAC pendant deux semaines, lu des secrets, créé un pod de persistance et supprimé ses artefacts ne laisse aucune trace forensique exploitable si l’audit log n’était pas actif. On sait qu’il s’est passé quelque chose (le secret est compromis, l’application se comporte bizarrement) mais on ne peut pas dire quoi, quand, depuis quel compte.
Note du PandaRedacteur : Et même si on active l’audit log après l’incident, on ne retrouve pas les événements passés.
L’audit log n’est pas rétroactif => Oui je sais l’enfonce une porte ouverte, mais des gens haut placés parfois….
La détection comportementale manquante
Kubernetes génère des logs d’API Server et des événements de pods. Ce qu’il ne génère pas nativement, c’est une détection comportementale à l’exécution : un shell lancé dans un conteneur de production, un conteneur qui lit /etc/shadow, un processus inattendu qui fait de la résolution DNS massive, un pod qui essaie d’écrire dans /proc.
Falco comble cet espace. Il intercepte les syscalls au niveau kernel via eBPF et les compare à des règles. Sans Falco ou un équivalent, ces comportements passent sans alerte, même si l’audit log est actif : l’audit log ne voit que les appels API Kubernetes, pas les syscalls dans les conteneurs.
Note du PandaRedacteur: Et donc sur la même formule que mon ami l’agriculteur Marc Frédéric => On ne réfléchit pas, On active la détection comportementale dans les clusters !
Les logs non centralisés
Des logs dans des conteneurs éphémères ne sont pas des logs. Quand le pod redémarre, les logs précédents disparaissent. Quand le node est retiré du cluster, les logs disparaissent avec lui. Sans centralisation, chaque incident nécessite de récupérer les logs avant qu’ils ne soient perdus, ce qui présuppose de détecter l’incident avant la rotation.
La centralisation dans un SIEM transforme des logs éphémères en traces durables (Note du PandaRedacteur: ou encore en logs réels ;) ).
Mitigations 2026
Activer l’audit log API Server avec une politique adaptée
La politique d’audit se doit d’etre définie avant toute installation de cluster. Le niveau Metadata pour les ressources sensibles (secrets, configmaps, serviceaccounts) est le minimum obligatoire ; il loggue qui fait quoi sans capturer le contenu des objets. Le niveau RequestResponse sur les secrets loggue aussi le contenu : utile pour la forensique, mais ayez des gros disques :) .
Les logs d’audit doivent être envoyés vers un stockage externe, pas conservés uniquement sur les nodes du control plane. Et l’accès à ces logs doit être restreint ; ils contiennent des informations sensibles.
Falco avec des règles de détection Kubernetes
L’article Falco - détection runtime Kubernetes détaille l’installation et la configuration. Les règles de base à activer en priorité pour K09 :
Terminal shell in container: shell lancé dans un conteneur en productionRead sensitive file untrusted: lecture de fichiers sensibles (/etc/shadow, kubeconfig, tokens SA)Launch Privileged Container: pod privilégié démarré en dehors des namespaces autorisésOutbound Connection to C2 Servers: connexion vers des IP/domaines de C2 connus
Note du PandaRedacteur : et puis ensuite, on ne laisse pas une alerte dans son coin, on définit la procédure d’actions et on l’applique
Centralisation et corrélation dans un SIEM
OpenTelemetry est devenu le standard CNCF pour la collecte et le forwarding des métriques, logs et traces. Il s’intègre nativement avec les SIEM et les agrégateurs de logs majeurs.
Ce qui doit être centralisé et corrélé :
- Audit logs API Server
- Événements Falco (oui oui on insiste lourdement)
- Logs des pods applicatifs (niveau erreur et warning au minimum)
- Événements Kubernetes (Pod OOMKilled, ImagePullBackOff, etc.)
La corrélation entre sources transforme des événements bruts en alertes actionnables.
Un accès API Server sur des secrets suivi d’un exec dans un pod depuis le même compte de service, avec une connexion sortante inhabituelle : isolément, chaque signal est ambigu ; ensemble, c’est une alerte prioritaire.
DevSecOps : intégrer K09 dans la chaîne CI/CD
Ce contenu représente de nombreuses heures de travail, d'expérience etc... J'ai remarqué que mon contenu était repris par certaines sociétés/personnes et j'ai donc décidé de donner du contenu minimal sur ce blog. C'est pourquoi je vous invite a me contacter sur LinkedIn en mentionnant cet article pour plus d'informations.
- ✓ Activer l'audit log API Server dès le départ : il n'est pas rétroactif. L'incident sans audit log = investigation à l'aveugle avec Coca et pizza.
- ✓ Falco pour la détection comportementale : l'audit log voit les appels API ; Falco voit les syscalls dans les conteneurs. Les deux sont nécessaires.
- ✓ Centraliser les logs avant l'incident : des logs dans des pods éphémères disparaissent avec les pods. Un SIEM permet la corrélation.
- ✓ La corrélation entre sources transforme les alertes : un événement isolé est ambigu ; trois sources corrélées donnent un incident clair.
- ✓ Falco Talon ferme la boucle : détecter sans répondre, c'est regarder l'attaquant travailler. La réponse automatique sur les incidents critiques est l'étape suivante.