Évasion de conteneur Kubernetes vers pivot cloud : détecter au runtime

Le rapport Threat Horizons H1 2026 de Google Cloud, treizième du nom, apporte un chiffre qui recadre la question du temps de réaction : un nouveau cluster Kubernetes reçoit sa première tentative d'attaque dans les dix-huit minutes suivant son déploiement. Le rapport, publié le 11 mars 2026 et couvrant le second semestre 2025, documente aussi un basculement de fond : les vulnérabilités logicielles exploitées représentent désormais 44,5 pour cent des intrusions cloud, dépassant pour la première fois le vol d'identifiants comme vecteur d'accès initial.

Au delà de la vitesse, c'est le schéma d'attaque qui doit retenir l'attention des équipes qui exploitent des conteneurs. Google décrit une intrusion où l'attaquant, après avoir abusé du plan de contrôle et détourné un compte de contrôleur applicatif à privilèges élevés, s'est appuyé sur la configuration privilégiée d'un pod pour s'échapper de l'environnement conteneurisé. L'analyse forensique suggère que cette évasion a été obtenue en abusant des privilèges d'administrateur de cluster pour sonder les services au niveau du noeud, plutôt qu'en exécutant un exploit du noyau. De là, l'acteur a mené sa reconnaissance avant de pivoter vers une charge de travail gérant des informations clients, où il a trouvé et extrait des identifiants de base de données stockés en clair dans les variables d'environnement du pod.

Le schéma à détecter : de l'évasion au pivot cloud

La chaîne comporte plusieurs étapes qui correspondent chacune à une technique observable. Le déploiement ou le détournement d'un conteneur privilégié relève de T1610 (Deploy Container). L'évasion du conteneur vers l'hôte est T1611 (Escape to Host). Une fois sur l'hôte ou dans un pod à privilèges, l'attaquant interroge le service de métadonnées de l'instance cloud, T1552.005, et vole les jetons d'accès applicatifs, T1528, qui lui ouvrent le reste de l'environnement cloud.

Les vecteurs d'entrée sont connus et récurrents : une API Docker ou Kubernetes exposée sans authentification, un socket docker.sock monté dans un conteneur, des capacités Linux excessives accordées au pod, ou une image tirée d'un registre public empoisonnée. Le point commun est qu'aucun de ces vecteurs ne se détecte au moment de l'installation ou du scan d'image seul : ils se manifestent au runtime, par un comportement anormal du conteneur.

La détection au runtime avec Falco

Falco et Tetragon observent les appels système et les événements du noyau en temps réel, ce qui en fait l'outil adapté pour repérer une évasion en cours. Trois comportements méritent une règle : l'accès à docker.sock depuis un conteneur, le lancement d'un processus dans un conteneur privilégié, et l'écriture ou la lecture sur des chemins de l'hôte montés en hostPath.

Voici une règle Falco ciblant l'accès au socket Docker depuis un conteneur, un signal fort d'une tentative de contrôle de l'hôte :

- rule: Acces socket Docker depuis un conteneur
  desc: >
    Un processus dans un conteneur ouvre le socket Docker, ce qui permet
    de creer des conteneurs privilegies et de s echapper vers l hote.
  condition: >
    evt.type in (open, openat) and
    container.id != host and
    fd.name endswith "docker.sock" and
    not proc.name in (dockerd, containerd)
  output: >
    Acces au socket Docker depuis un conteneur
    (commande=%proc.cmdline conteneur=%container.name image=%container.image.repository)
  priority: CRITICAL
  tags: [container, escape, T1611]

Une deuxième règle utile surveille le lancement d'un shell ou d'un outil de reconnaissance dans un conteneur marqué privilégié, souvent le prélude immédiat à l'évasion. Sur les hôtes cloud, ajoutez enfin une règle sur les connexions sortantes vers l'adresse du service de métadonnées de l'instance depuis un conteneur applicatif, qui n'a normalement aucune raison d'interroger cette adresse.

Le garde-fou à l'admission avec OPA

La détection au runtime attrape ce qui se passe. La politique à l'admission empêche que cela puisse arriver. OPA, via Gatekeeper, permet de refuser à l'admission tout pod demandant une configuration à risque : mode privilégié, montage de docker.sock, capacités dangereuses, ou hostPath vers des répertoires sensibles. Voici l'esprit d'une politique Rego rejetant les pods privilégiés :

package kubernetes.admission
 
deny[msg] {
    input.request.kind.kind == "Pod"
    c := input.request.object.spec.containers[_]
    c.securityContext.privileged == true
    msg := sprintf("Conteneur privilegie interdit: %v", [c.name])
}
 
deny[msg] {
    input.request.kind.kind == "Pod"
    v := input.request.object.spec.volumes[_]
    endswith(v.hostPath.path, "docker.sock")
    msg := "Montage de docker.sock interdit"
}

Cette combinaison, prévention à l'admission plus détection au runtime, est la posture recommandée. La politique OPA réduit la surface en amont, en refusant les configurations qui rendent l'évasion possible. Falco couvre le reste, en signalant les comportements anormaux sur ce qui a tout de même été déployé.

Ce que la fenêtre de dix-huit minutes impose

Le chiffre de Google a une conséquence directe : une détection qui remonte une alerte plusieurs heures après l'événement arrive trop tard. La surveillance au runtime doit être active dès le premier déploiement, pas ajoutée après coup. De même, les identifiants de base de données dans les variables d'environnement d'un pod, cause directe du pivot décrit par Google, doivent être remplacés par des secrets gérés et à durée de vie courte. Un conteneur compromis ne doit jamais trouver de clé cloud durable à portée de main.

Sécuriser un environnement Kubernetes contre l'évasion et le pivot demande cette double couche, admission et runtime, alimentée par des règles à jour. C'est ce que fournit le feed cloud-native ThreatClaw : des règles Falco et des politiques OPA prêtes à déployer, construites sur les techniques d'évasion et de pivot réellement observées, pour tenir le rythme imposé par des attaquants qui frappent en minutes.