Sécurité runtime eBPF pour Kubernetes

Les conteneurs sont éphémères, mais leurs processus interagissent toujours avec le noyau Linux. La sécurité runtime eBPF observe cette interaction au plus près, reliant exécution, fichiers, privilèges et réseau aux workloads Kubernetes.

Cette visibilité détecte ce que le scan d’image ne voit pas : une image signée et sans CVE peut être détournée au runtime. Il faut cependant éviter le bruit et les politiques qui cassent la production.

Ce qu’apporte eBPF

Les programmes eBPF s’attachent à des événements du noyau et filtrent avant l’espace utilisateur. Les outils conscients de Kubernetes ajoutent namespace, pod, conteneur, labels et identité.

La présentation de Tetragon décrit observabilité et enforcement eBPF pour processus, appels système, fichiers et réseau. Les capacités varient selon noyau, outil et mode.

Cas d’usage :

• shell ou interpréteur inattendu ;
• accès à un fichier sensible ;
• changement de privilèges ;
• connexion d’un processus supposé hors ligne ;
• exécution depuis un chemin inscriptible ;
• signe d’évasion vers l’hôte.

Partir d’un threat model runtime

Listez workloads critiques, processus attendus, destinations autorisées, mounts sensibles et privilèges. Priorisez identité, runners CI, secrets, ingress, bases et services internet.

Évitez une baseline globale. Un worker de build lance légitimement des compilateurs ; un serveur web statique ne devrait pas ouvrir un shell.

Concevoir des politiques à fort signal

Combinez :

• identité du workload ou namespace ;
• chemin et hash du binaire ;
• relation parent-enfant ;
• capacités et utilisateur ;
• cible fichier ou socket ;
• réputation et prévalence de destination ;
• version et digest de l’image.

Exemples :

• shell dans un conteneur web de production ;
• package manager après déploiement ;
• token de service account lu par un binaire inattendu ;
• connexion vers un domaine rare et mal réputé ;
• accès aux namespaces de l’hôte.

Enrichissez le réseau avec réputation domaine et réputation IP. Le runtime explique pourquoi la connexion compte.

Observer avant de bloquer

Déployez chaque politique en observation. Mesurez le volume, identifiez les variantes légitimes et attribuez un propriétaire aux exceptions. Testez sous charge et en cas d’échec.

Passez à l’enforcement lorsque :

• le comportement est clairement interdit ;
• le périmètre est étroit ;
• la précision est démontrée ;
• rollback et break-glass existent ;
• l’équipe comprend l’action.

Tuer un processus n’annule pas toujours l’opération déjà effectuée. La sémantique doit correspondre à la protection visée.

Pipeline et stockage

Filtrez à la source au lieu d’exporter chaque syscall. Normalisez workload, digest, nœud et arbre de processus. Envoyez les événements à forte valeur au SIEM et conservez le détail pour l’investigation.

Versionnez les politiques, imposez revue et tests. Reliez leur évolution aux releases applicatives.

Réponse à incident

Préservez spécification du pod, digest, nœud, arbre des processus, connexions, secrets montés et événements eBPF. Isolez selon le plan d’orchestration ; ne supprimez pas le pod avant d’avoir collecté les preuves.

Vérifiez l’image via l’intelligence de hash, recherchez les IOC réseau et consultez les journaux d’audit Kubernetes.

Métriques

Suivez workloads couverts, politiques critiques, événements par workload, incidents confirmés, actions d’enforcement, opérations empêchées, faux positifs et exceptions sans propriétaire. Mesurez le délai entre hypothèse et politique testée.

Conclusion

eBPF apporte une preuve liée au workload à la frontière du noyau Linux. Partez du threat model, filtrez fortement et n’imposez que des invariants étroits. Avec la sécurité Kubernetes, il ferme l’écart entre image de confiance et action runtime hostile.