Falco : détection des menaces runtime sur Kubernetes

Un pare-feu, un antivirus et un scanner de vulnérabilités ne disent rien de ce qui se passe pendant l’exécution d’une charge de travail. Un shell ouvert dans un conteneur de production, un binaire téléchargé puis lancé depuis /tmp, la lecture de /etc/shadow par un processus inattendu : ces signaux faibles sont souvent les premiers indices d’une compromission, et ils se produisent au niveau du noyau. C’est précisément le terrain de Falco, l’outil open source de sécurité runtime devenu une référence dans les environnements Linux, conteneurisés et Kubernetes.

Dans ce guide, nous détaillons son fonctionnement, son installation sur un serveur Linux et sur un cluster, l’écriture de règles personnalisées et la manière de l’intégrer à votre chaîne de détection.

Qu’est-ce que Falco ?

Falco est un outil de détection des menaces à l’exécution (runtime security) pour Linux. Créé par Sysdig en 2016, il a été confié à la Cloud Native Computing Foundation (CNCF), dont il est aujourd’hui un projet gradué, le plus haut niveau de maturité de la fondation. Il est distribué sous licence Apache 2.0.

Son principe est simple : Falco observe en continu les événements du noyau, en particulier les appels système (syscalls), les enrichit avec le contexte du conteneur et de Kubernetes (nom du pod, namespace, image…), puis les compare à un ensemble de règles. Lorsqu’un comportement correspond à une règle, Falco émet une alerte en temps réel. Il ne bloque rien par lui-même : c’est un outil de détection, à combiner avec vos mécanismes de réponse.

Quelques exemples de comportements détectés par les règles fournies par défaut :

ouverture d’un shell interactif dans un conteneur ;
lecture d’un fichier sensible (/etc/shadow, clés SSH) par un programme non approuvé ;
écriture sous des répertoires système comme /etc ou /usr/bin ;
exécution d’un binaire absent de l’image d’origine du conteneur ;
connexions réseau sortantes inattendues ou tentatives d’élévation de privilèges.

Architecture et fonctionnement

Falco s’articule autour de plusieurs briques maintenues par l’organisation falcosecurity :

Les drivers : ils collectent les événements du noyau. Le probe eBPF moderne (modern_ebpf) est l’option recommandée sur les noyaux récents, car il ne nécessite ni compilation ni module noyau ; le module noyau (kmod) reste disponible pour les systèmes plus anciens. L’ancien probe eBPF, le moteur gVisor et la sortie gRPC ont été retirés avec la version 0.44.0 (mai 2026).
Les bibliothèques libs (libscap et libsinsp) : capture, analyse et enrichissement des événements.
Le moteur de règles : il évalue chaque événement avec des conditions écrites en YAML, à l’aide de macros et de listes réutilisables.
Les plugins : ils étendent Falco au-delà des syscalls, par exemple aux journaux d’audit Kubernetes, à AWS CloudTrail ou à d’autres sources d’événements. Les métadonnées des conteneurs sont elles-mêmes fournies par le plugin container.
falcoctl : l’outil en ligne de commande qui installe les drivers et met à jour automatiquement les règles et plugins.
Falcosidekick : un composant optionnel qui redirige les alertes vers des dizaines de destinations (Slack, Teams, Elasticsearch, Loki, webhooks, outils de SIEM…), avec une interface web de visualisation.

La branche actuelle est la 0.45 : la version 0.45.0 est sortie le 21 septembre 2026 et la 0.45.2 le 30 octobre 2026. Elle apporte notamment le rechargement contrôlé de la configuration, un meilleur échappement des sorties texte et JSON et des drivers en version 11.0.0. Attention : Falco 0.45 refuse les drivers plus anciens, pensez donc à mettre à jour le driver en même temps que le binaire.

Installation sur un serveur Debian ou Ubuntu

Falco est distribué sous forme de paquets DEB et RPM, d’image de conteneur et de chart Helm. Sur un serveur Debian ou Ubuntu, la méthode officielle consiste à ajouter le dépôt officiel du projet et à choisir le driver eBPF moderne lors de l’installation :

# Import de la clé GPG du dépôt Falco
curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | \
  sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg

# Ajout du dépôt APT
echo "deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] https://download.falco.org/packages/deb stable main" | \
  sudo tee -a /etc/apt/sources.list.d/falcosecurity.list
sudo apt-get update -y

# Installation avec le driver eBPF moderne (sans module noyau à compiler)
sudo FALCO_DRIVER_CHOICE=modern_ebpf apt-get install -y falco

# Activation du service et vérification
sudo systemctl enable --now falco-modern-bpf.service
sudo systemctl list-unit-files "falco*"
falco --version

# Suivi des alertes en temps réel
sudo journalctl -u falco-modern-bpf.service -f

Les services systemd fournis par le paquet correspondent aux différents drivers : falco-modern-bpf.service pour l’eBPF moderne, falco-kmod.service pour le module noyau, et falcoctl-artifact-follow.service pour la mise à jour automatique des règles. L’activation du service eBPF crée également l’alias falco.service. Si votre noyau ne prend pas en charge l’eBPF moderne, installez les en-têtes du noyau (dkms, make, linux-headers) et utilisez le module noyau.

Pour valider la détection, ouvrez simplement un shell dans un conteneur ou lisez /etc/shadow avec un utilitaire comme cat : une alerte de type Sensitive file opened for reading by non-trusted program doit apparaître dans le journal.

Écrire ses propres règles

Les règles par défaut sont livrées dans /etc/falco/falco_rules.yaml et sont mises à jour par falcoctl : ne les modifiez pas directement. Placez vos ajouts et vos exceptions dans /etc/falco/falco_rules.local.yaml. Une règle comporte un nom, une description, une condition exprimée dans le langage de filtrage de Falco, un message de sortie qui peut contenir des champs dynamiques, une priorité et des étiquettes.

L’exemple ci-dessous alerte lorsqu’un outil de transfert réseau (curl, wget) est lancé dans un conteneur, un comportement fréquent lors du téléchargement d’une charge malveillante après une intrusion, ou lors d’une tentative d’escalade de privilèges sur Linux. Il s’appuie sur les macros spawned_process et container fournies par les règles officielles. Le second bloc montre ensuite le déploiement de Falco sur un cluster Kubernetes avec Helm, accompagné de Falcosidekick et de son interface web.

# 1) Règle personnalisée : /etc/falco/falco_rules.local.yaml
- rule: Outil de téléchargement lancé dans un conteneur
  desc: Détecte l'exécution de curl ou wget dans un conteneur
  condition: spawned_process and container and proc.name in (curl, wget)
  output: >
    Outil de téléchargement dans un conteneur
    (user=%user.name cmd=%proc.cmdline container=%container.name
    image=%container.image.repository)
  priority: WARNING
  tags: [container, mitre_command_and_control]

# Validation de la règle puis redémarrage du service
sudo falco -V /etc/falco/falco_rules.local.yaml
sudo systemctl restart falco-modern-bpf.service

# 2) Déploiement sur Kubernetes avec Helm
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install --replace falco --namespace falco --create-namespace \
  --set tty=true falcosecurity/falco
kubectl wait pods --for=condition=Ready --all -n falco

# Activation de Falcosidekick et de son interface web
helm upgrade --namespace falco falco falcosecurity/falco \
  --set falcosidekick.enabled=true --set falcosidekick.webui.enabled=true
kubectl -n falco port-forward svc/falco-falcosidekick-ui 2802

# Test : lecture d'un fichier sensible dans un pod nginx
kubectl create deployment nginx --image=nginx
kubectl exec -it $(kubectl get pods --selector=app=nginx -o name) -- cat /etc/shadow
kubectl logs -l app.kubernetes.io/name=falco -n falco -c falco | grep Warning

Exploiter les alertes au quotidien

Une alerte Falco contient l’horodatage, la priorité, le nom de la règle et un message enrichi : utilisateur, ligne de commande, conteneur, image, pod et namespace. Par défaut, les alertes sont écrites sur la sortie standard et dans syslog ; Falco peut aussi produire du JSON, écrire dans un fichier ou envoyer les événements vers un endpoint HTTP. En pratique, la plupart des équipes passent par Falcosidekick pour router les alertes selon leur priorité : les alertes critiques vers la messagerie de l’astreinte, l’ensemble des événements vers un SIEM ou une pile de journalisation pour la corrélation et l’investigation.

Falco s’intègre ainsi naturellement dans un centre opérationnel de sécurité : il fournit la télémétrie runtime que l’analyste corrèle avec les journaux réseau, d’authentification ou d’annuaire. Si vous montez en compétence sur ce métier, notre cours sur les fondamentaux des opérations de sécurité (SOC) présente la chaîne de détection et de traitement des incidents dans laquelle Falco prend place.

Falco face aux alternatives

Wazuh : plateforme XDR/SIEM complète (agents, détection d’intrusion hôte, conformité, contrôle d’intégrité). Wazuh couvre un périmètre plus large, y compris Windows, alors que Falco est spécialisé dans l’observation fine des syscalls Linux et du contexte Kubernetes. Les deux sont complémentaires : les alertes JSON de Falco peuvent être collectées et corrélées dans Wazuh.
Tetragon (projet Cilium) : également basé sur eBPF, il sait non seulement détecter mais aussi appliquer des politiques et bloquer certaines actions directement dans le noyau. Il est particulièrement pertinent si vous utilisez déjà Cilium.
Tracee (Aqua Security) : outil open source de détection runtime basé sur eBPF, avec une approche orientée signatures et forensique.
Solutions commerciales (CNAPP, EDR) : elles ajoutent console centralisée, réponse automatisée et support, souvent pour un coût significatif. L’offre commerciale de Sysdig, créateur du projet, repose d’ailleurs sur Falco.

Falco ne remplace pas l’analyse en amont : un scanner comme Trivy identifie les vulnérabilités et les mauvaises configurations avant le déploiement, tandis que Falco surveille ce que font réellement les conteneurs une fois en production. C’est ce duo « shift left » et « runtime » qui offre une couverture cohérente.

Bonnes pratiques de déploiement

Privilégiez le driver eBPF moderne sur les noyaux récents, et maintenez drivers, binaire et règles à des versions compatibles lors de chaque mise à jour.
Commencez par les règles par défaut, observez le bruit pendant quelques jours, puis ajoutez des exceptions ciblées dans falco_rules.local.yaml plutôt que de désactiver des règles entières.
Versionnez vos règles dans Git et validez-les avec falco -V dans votre pipeline CI/CD avant déploiement.
Définissez une politique de priorités : seules les alertes WARNING et au-delà doivent réveiller l’astreinte ; le reste alimente le SIEM.
Surveillez Falco lui-même : les métriques et compteurs de pertes d’événements exposés par Falco permettent de détecter une saturation des buffers ou un agent arrêté.
Préparez la réponse : une alerte sans procédure ne sert à rien. Documentez les actions associées à chaque règle critique (isolation du pod, capture, analyse forensique).
Protégez la chaîne d’alerte : restreignez l’accès à l’interface Falcosidekick et chiffrez les flux vers vos destinations.

Conclusion

Falco comble un angle mort majeur de nombreuses architectures : la visibilité sur ce qui se passe réellement dans les serveurs et les conteneurs pendant leur exécution. Open source, soutenu par la CNCF et doté d’un écosystème riche (règles officielles, plugins, Falcosidekick), il se déploie en quelques minutes sur un serveur Linux comme sur un cluster Kubernetes. Bien paramétré et intégré à votre SIEM, il devient un capteur de détection précieux pour vos équipes de sécurité, sans coût de licence.

Vous souhaitez déployer Falco ou renforcer la détection sur vos environnements conteneurisés ? Les équipes d’Azur Secure peuvent vous accompagner dans le cadrage, le déploiement et l’ajustement des règles.

Partagez cet article !