# Kubernetes : l’automatisation de la réponse menace les preuves forensiques

_Publié le 5 novembre 2026 — https://ip73.fr/2026/11/05/kubernetes-l-automatisation-de-la-reponse-menace-les-preuves/_

Réagir vite à une brèche est le premier réflexe des équipes de sécurité, mais quand on gère des conteneurs Kubernetes, une réaction trop zélée peut faire disparaître la preuve. Si une alerte signale une activité suspecte sur un Pod, une automation qui procède immédiatement au remplacement de ce conteneur, par exemple, ne fait souvent qu'effacer les traces numériques nécessaires à la compréhension de l'attaque, selon AWS.

AWS documente clairement que, si l'on choisit d'isoler un Pod pour une analyse de cause racine, une séquence d'actions précises doit être suivie, allant au-delà du simple arrêt du processus. Les premières étapes consistent à identifier l'entité fautive – qu'il s'agisse d'un Pod spécifique, d'un nom de workload, ou même d'un service account compromis. Les commandes `kubectl` fournissent les moyens techniques de localiser ces éléments sur le nœud hôte.

Il est de plus en plus fréquent que la réponse automatisée se heurte à la réalité de l'infrastructure. En effet, supprimer un Pod géré par un contrôleur Kubernetes entraînera presque systématiquement le lancement d'un nouveau Pod à partir de la même image, réintroduisant potentiellement la vulnérabilité. Comme le signale Cloud Native Now, cette action ne constitue pas une véritable contenance, car les Pods de remplacement héritent de la même configuration vulnérable. De plus, AWS alerte sur ce risque, rappelant que supprimer un Pod géré par un contrôleur peut être contre-productif.

## Les étapes pour une investigation forensique structurée

Si l'on décide d'isoler un Pod pour une investigation, AWS recommande un plan d'action précis. Il faut d'abord identifier le Pod et le nœud hôte concernés. Si le Pod fait partie d'un *Workload Resource* comme un *Deployment*, il est probable que tous les Pods associés soient compromis. Des commandes spécifiques permettent de lister ces Pods et les nœuds sur lesquels ils tournent.

Si le problème vient d'un *service account*, il faut identifier tous les Pods utilisant ce compte et les nœuds correspondants. Enfin, si l'on suspecte une image conteneur malveillante ou contenant une CVE exploitée, on peut cibler tous les Pods utilisant cette image spécifique, en précisant le nom de l'image dans la requête.

Pour stopper une attaque en cours, l'isolation est clé. On peut appliquer une *Network Policy* pour interdire tout trafic entrant et sortant vers le Pod ciblé. Cependant, AWS précise que cette politique peut être inefficace si l'attaquant a accédé au nœud hôte ; dans ce cas, il faut utiliser les *Security Groups* AWS pour isoler le nœud entier.

## Les limites de l'automatisation et le rôle de l'humain

L'automatisation est rapide, mais elle ne voit pas tout. Des études montrent que les tâches de triage de logiciels malveillants, par exemple, peuvent passer de quinze minutes à quasi instantané grâce aux chaînes scriptables. Pourtant, cette compression s'arrête là où commence le jugement humain. Les investigations longues, celles qui demandent une analyse approfondie, ne bougent que peu.

En outre, les systèmes de sécurité doivent se confronter à la réalité des processus de validation. Un processus d'approbation qui prend plus de temps que la fenêtre d'attaque ne permet pas une contenance efficace. Les équipes de plateforme et de sécurité doivent donc décider à l'avance quelles actions peuvent être exécutées automatiquement et lesquelles nécessitent une validation humaine.

Pour les nœuds compromis, il est conseillé de les *cordoner* pour empêcher le planificateur de les utiliser, ce qui permet de les retirer pour une étude forensique sans perturber les autres charges de travail. Il faut aussi activer la protection contre la terminaison pour éviter qu'un attaquant ne supprime ses traces.

## Sources

- [Incident response and forensics](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html), docs.aws.amazon.com
- [SOAR vs AI SOC: Which Actually Reduces Your Response Time (and Risk)? \| Prophet Security](https://www.prophetsecurity.ai/blog/soar-vs-ai-soc), prophetsecurity.ai
- [Security Automation Is a Production Change: What Agentic SOCs Get Right in Kubernetes](https://cloudnativenow.com/sponsored-content/security-automation-is-a-production-change-what-agentic-socs-get-right-in-kubernetes/), Cloud Native Now, 5 novembre 2026

## Crédits photo

- Image en une : [Ethernet NIC 100Mbit PCI](https://commons.wikimedia.org/wiki/File:Ethernet_NIC_100Mbit_PCI.jpg), par afrank99, [CC BY-SA 2.0](https://creativecommons.org/licenses/by-sa/2.0), via Wikimedia Commons (recadrée)