Sécurité runtime Kubernetes : au-delà du scan d\u2019images

Scanner vos images Docker avant le déploiement est nécessaire mais insuffisant. Les CVE critiques de Kubernetes en 2024-2025 démontrent que les attaques les plus dangereuses se produisent au runtime, quand les conteneurs sont en exécution. Voici comment sécuriser votre cluster au-delà du scan d'images.

CVE récentes : pourquoi le runtime compte

CVE-2024-9042 : exécution de commande sur les nœuds Windows

Score CVSS 9.8. Cette vulnérabilité permet à un attaquant d'exécuter des commandes arbitraires sur les nœuds Windows d'un cluster Kubernetes via l'API de logging. Un simple appel API non authentifié suffit pour obtenir une exécution de code en tant que SYSTEM sur le nœud. Affecte Kubernetes 1.27-1.30 avec des nœuds Windows.

CVE-2025-1767 : évasion via les volumes gitRepo

Les volumes de type gitRepo permettent à un pod de cloner un dépôt Git au démarrage. Cette CVE révèle que le contenu du dépôt peut être manipulé pour accéder aux fichiers du nœud hôte en exploitant des liens symboliques. Un attaquant contrôlant un dépôt Git peut ainsi s'échapper du conteneur et accéder au filesystem du nœud.

Ces deux CVE partagent un point commun : aucun scan d'image ne les détecte. Ce sont des vulnérabilités dans l'orchestrateur lui-même, exploitables uniquement au runtime.

Build-time vs runtime : deux batailles différentes

• Build-time (scan d'images) : détecte les packages vulnérables dans les images Docker. Outils : Trivy, Grype, Snyk Container. Indispensable mais insuffisant

• Runtime : surveille ce qui se passe dans les conteneurs en exécution. Détecte les comportements anormaux : exécution de shell dans un conteneur, accès réseau non attendu, modification de fichiers sensibles, élévation de privilèges

La sécurité build-time vous protège contre les vulnérabilités connues dans vos dépendances. La sécurité runtime vous protège contre les vulnérabilités inconnues (zero-days) et les comportements malveillants qui exploitent des configurations faibles.

eBPF : la révolution de l'observabilité kernel

eBPF (extended Berkeley Packet Filter) permet d'exécuter du code dans le kernel Linux sans modifier le noyau. Pour la sécurité Kubernetes, cela signifie une observabilité sans overhead significatif : traçage des appels système, monitoring réseau, détection de comportements anormaux, le tout avec un impact de performance inférieur à 1%.

Les outils basés sur eBPF (Cilium Tetragon, Falco avec le driver eBPF) peuvent détecter en temps réel des actions comme : exécution de /bin/bash dans un conteneur de production, connexion sortante vers une IP inconnue, lecture de /etc/shadow, montage de volumes hostPath.

Falco : le standard de facto

Falco (CNCF graduated project) est le moteur de détection runtime le plus déployé. Il surveille les appels système et applique des règles de détection :

• Shell interactif dans un conteneur de production

• Processus inattendu (cryptominer, reverse shell)

• Modification de fichiers système

• Connexions réseau suspectes

• Accès aux secrets Kubernetes

Falco génère des alertes mais ne bloque pas. Pour la réponse automatisée, il faut l'intégrer avec un outil de réaction ou un agent comme ThreatClaw.

Network Policies et Pod Security Standards

Network Policies

Par défaut, tous les pods Kubernetes peuvent communiquer entre eux. Les Network Policies permettent de restreindre le trafic réseau entre pods, namespaces et le monde extérieur. C'est l'équivalent d'un firewall microsegmenté. Pourtant, selon une étude de Datadog, moins de 30% des clusters en production utilisent des Network Policies.

Pod Security Standards

Les Pod Security Standards (Privileged, Baseline, Restricted) définissent trois niveaux de sécurité pour les pods. Le niveau Restricted interdit les conteneurs privilégiés, force un filesystem read-only, bloque l'élévation de privilèges et impose un utilisateur non-root.

ThreatClaw : Trivy + Grype + runtime

ThreatClaw combine la sécurité build-time et runtime dans ses skills Kubernetes :

• Trivy : scan des images, des configurations Kubernetes (IaC), des licences et des secrets

• Grype : scan de vulnérabilités avec matching SBOM pour une couverture complémentaire à Trivy

• Audit de configuration : vérification des Network Policies, Pod Security Standards, RBAC, service accounts

• Corrélation runtime : intégration des alertes Falco/Tetragon avec le contexte CTI pour une détection enrichie

FAQ

Trivy ou Grype : lequel choisir ?

Les deux sont excellents et open source. Trivy (Aqua Security) offre une couverture plus large (images, IaC, SBOM, secrets). Grype (Anchore) est plus rapide sur le scan de vulnérabilités pur et a un matching de packages plus granulaire. L'idéal est d'utiliser les deux en complémentarité, ce que fait ThreatClaw nativement.

Mon cluster est petit, ai-je besoin de sécurité runtime ?

Oui. La taille du cluster n'est pas le critère. Un petit cluster exposé sur Internet avec un conteneur compromis peut servir de point d'entrée vers votre réseau interne, miner de la cryptomonnaie, ou participer à un botnet. La sécurité runtime est un investissement minimal avec un ROI élevé.

eBPF est-il supporté sur tous les clusters ?

eBPF nécessite un kernel Linux 4.14+ (idéalement 5.x+). Les distributions Kubernetes managées (EKS, GKE, AKS) supportent toutes eBPF. Pour les clusters on-premise, vérifiez la version du kernel. Les nœuds Windows ne supportent pas eBPF.

Comment ThreatClaw s'intègre avec mon pipeline CI/CD ?

ThreatClaw peut s'intégrer dans votre pipeline CI/CD pour le scan build-time (Trivy/Grype) et surveiller le runtime post-déploiement. L'agent corrèle les deux : une vulnérabilité détectée au build-time qui est exploitée au runtime déclenche une alerte de priorité maximale. Consultez nos offres pour les détails.