Détection Runtime Falco

Contexte et Objectifs

Réalisé dans le cadre d'une SAE de BUT3 Cybersécurité à l'IUT de Nice — Sophia Antipolis, ce projet académique noté avait pour but de déployer et d'instrumenter un cluster Kubernetes avec Falco, un projet CNCF graduated dédié à la détection de menaces au runtime.

L'enjeu : comprendre la place d'un outil de détection runtime dans une chaîne de sécurité Kubernetes, capturer de véritables alertes de sécurité, puis étudier le bruit généré par les règles par défaut afin de mesurer le besoin de tuning avant une mise en production.

Détection vs Prévention : la défense en profondeur

Falco ne se substitue pas aux contrôles existants : il complète la chaîne de sécurité K8s en agissant au moment de l'exécution, là où les outils en amont n'ont plus de visibilité. Il s'inscrit ainsi dans une logique de défense en profondeur :

• En amont — Scan d'images (ex. Trivy) : détection des vulnérabilités avant le déploiement, sur les images de conteneurs.
• À l'admission — Admission control (ex. Kyverno) : application de politiques (prévention) au moment où un pod est admis dans le cluster.
• Au runtime — Falco : observation en continu des syscalls via eBPF pour détecter ce qui se passe réellement dans les conteneurs une fois en exécution.

Stack technique & Déploiement

L'ensemble de l'environnement a été monté sur un GitHub Codespace (Ubuntu, kernel 6.8.0-1052-azure), garantissant un lab reproductible et jetable :

• Cluster : Kind v0.23.0 (1 control-plane), Docker 29.3.0, kubectl v1.36.2, Helm v3.21.1.
• Falco : déployé en DaemonSet via le chart officiel falcosecurity/falco — un agent par nœud pour une couverture complète.
• Driver : modern_ebpf, qui exige un kernel hôte ≥ 5.8 (vérifié via uname -r avant le helm install).
• Observabilité : Falcosidekick + Falcosidekick-UI (port-forward 2802) pour le fan-out des alertes vers Slack, webhook ou SIEM.

Réalisations concrètes

Le cluster a été rendu opérationnel avec Falco en état 2/2 Running, 0 restart. Trois alertes représentatives ont été déclenchées et analysées sur un pod busybox de test :

• Warning — Sensitive file opened for reading by non-trusted program : lecture d'un fichier sensible (cat /etc/shadow).
• Critical — Executing binary not part of base image : exécution d'un binaire (mount) absent de l'image de base au démarrage.
• Notice — A shell was spawned in a container with an attached terminal : ouverture d'un shell avec terminal attaché (TTY 34816).

Falcosidekick-UI a été déployé pour centraliser et rediffuser ces alertes, et l'ensemble a été synthétisé dans une présentation de soutenance de 14 slides.

Défis techniques résolus

Au-delà du déploiement, ce projet a mis en lumière plusieurs subtilités propres à l'exploitation d'un outil de sécurité runtime :

• Compatibilité du driver eBPF : modern_ebpf impose un kernel hôte ≥ 5.8. Vérification systématique via uname -r en amont du helm install pour éviter un échec silencieux du DaemonSet.
• Le paradoxe des privilèges : Falco requiert privileged: true et hostPID — un outil de sécurité avec une forte surface d'attaque. À mitiger en production par des NetworkPolicies, un RBAC strict et le scan de l'image de Falco elle-même.
• La règle « Terminal shell » silencieuse : la règle exige proc.tty != 0. Un kubectl exec -it lancé depuis un shell non interactif (CI) laisse tty=0 et ne déclenche rien. Solution : encapsulation via script -q -c "kubectl exec -it ..." pour forcer un vrai pseudo-TTY.

Résultat marquant : le tuning, un prérequis

L'observation a fourni un argument chiffré en faveur du tuning des règles avant tout déploiement réel :