Un attaquant qui obtient un shell dans un pod Kubernetes ne laisse presque jamais de trace dans les logs applicatifs. Les scanners d’images comme Trivy ou les politiques d’admission comme Kyverno bloquent ce qui est mal configuré avant le déploiement, mais ils sont aveugles à ce qui se passe une fois le conteneur démarré. C’est le créneau que Falco occupe depuis 2016 : observer chaque appel système du noyau Linux en temps réel et déclencher une alerte dès qu’un comportement sort du cadre attendu. Le projet, passé au statut “graduated” à la Cloud Native Computing Foundation, vient de publier la version 0.45.0 le 21 septembre 2026. Ce tutoriel installe Falco sur un cluster Kubernetes, écrit une règle de détection personnalisée, déclenche un événement contrôlé et branche les alertes vers un pipeline de réponse via Falcosidekick. Il s’inscrit dans notre couverture plus large du cloud computing, où durcissement d’infrastructure et détection d’incidents avancent de pair.

Pourquoi la sécurité runtime change la donne face aux conteneurs compromis

La plupart des équipes sécurité françaises et européennes empilent des contrôles en amont du déploiement : signature d’images avec Cosign, scan de vulnérabilités avec Trivy, politiques d’admission avec Kyverno ou OPA Gatekeeper. Ces couches réduisent la surface d’attaque, mais aucune ne répond à la question qui compte le jour d’un incident : que fait réellement ce conteneur là, maintenant, sur ce nœud ? Un pod peut passer tous les contrôles d’admission et se faire compromettre trois heures plus tard via une dépendance vulnérable non détectée au scan, une fuite d’identifiants cloud, ou une exécution de code distante dans l’application elle-même.

Falco répond à ce manque en s’intercalant entre les processus applicatifs et le noyau Linux. Le projet est décrit sur son site officiel comme “a cloud native security tool that provides runtime security across hosts, containers, Kubernetes, and cloud environments”, traduit par : un outil de sécurité cloud native qui assure la sécurité runtime sur les hôtes, les conteneurs, Kubernetes et les environnements cloud. Concrètement, Falco capture les appels système (ouverture de fichier, exécution de binaire, connexion réseau sortante) et les compare à un jeu de règles déclaratives. Dès qu’une condition correspond, une alerte part immédiatement, avec le contexte complet : namespace, pod, conteneur, utilisateur, ligne de commande.

Ce mécanisme repose sur eBPF (extended Berkeley Packet Filter), une technologie qui exécute du code sandboxé directement dans le noyau Linux sans module tiers risqué. Sysdig, l’entreprise à l’origine du projet avant son passage à la CNCF, explique que Falco “efficiently leverages extended Berkeley Packet Filter (eBPF), a secure mechanism, to capture system calls to gain deep visibility”, soit : exploite efficacement eBPF, un mécanisme sécurisé, pour capturer les appels système et obtenir une visibilité profonde. Sur le fond, c’est la même famille technologique que Cilium pour le réseau (voir notre tutoriel sur Cilium et le Zero Trust Kubernetes), mais appliquée à la détection comportementale plutôt qu’au filtrage de paquets.

Comment eBPF permet d’observer le noyau sans casser la stabilité du nœud

eBPF mérite quelques lignes d’explication avant de plonger dans l’installation, car c’est cette technologie qui rend Falco viable en production sans risque pour la stabilité des nœuds. Historiquement, observer les appels système sous Linux passait par un module noyau développé sur mesure, chargé avec les droits les plus élevés de la machine. Un bug dans ce module pouvait faire planter le nœud entier, un risque inacceptable sur un cluster de production. Le site de référence eBPF.io décrit cette technologie comme un moyen d’exécuter des programmes sandboxés dans le noyau du système d’exploitation, sans modifier le code source du noyau ni charger de module tiers. Le programme est vérifié statiquement avant son exécution, ce qui élimine une grande partie des risques associés aux anciens modules noyau.

La documentation officielle de Falco confirme cette architecture à deux vitesses : “Currently, Falco supports the following drivers: (Default) Modern eBPF probe (CO-RE paradigm and more) Kernel module”, soit : Falco prend actuellement en charge les drivers suivants, en mode par défaut la sonde eBPF moderne (paradigme CO-RE et plus), et le module noyau. Le choix par défaut sur les installations récentes est donc explicitement la sonde eBPF moderne, le module noyau restant disponible comme option de repli sur des environnements où eBPF serait indisponible ou restreint par une politique de sécurité renforcée.

Leonardo Di Donato, contributeur au projet Falco, résume le principe technique dans un épisode du Kubernetes Podcast consacré à eBPF : “Falco is a runtime security engine that listens to the Linux kernel using eBPF – the extended Berkeley Packet Filter”, soit : Falco est un moteur de sécurité runtime qui écoute le noyau Linux via eBPF, le Berkeley Packet Filter étendu. Cette écoute passive est ce qui permet à Falco de fonctionner en observation continue sans interférer avec l’exécution normale des processus applicatifs, contrairement à des agents de sécurité plus intrusifs qui interceptent et retardent chaque appel système.

Prérequis et versions pour suivre ce tutoriel

Avant de commencer, vérifiez que votre environnement dispose des éléments suivants. Ce tutoriel a été rédigé avec les versions disponibles au 30 septembre 2026.

ComposantVersion utiliséeRôle dans ce tutoriel
Falco0.45.0 (sortie le 21 septembre 2026)Moteur de détection runtime
Helm3.xDéploiement du chart officiel
kubectlcompatible avec votre clusterInteraction avec l’API Kubernetes
Driver eBPFModern eBPF probe (CO-RE), driver API 11.0.0+Capture des appels système, mode par défaut
falcoctl0.14.2Gestion des règles et plugins Falco
Falco Rulesfalco-rules 5.2.0Jeu de règles par défaut livré avec 0.45.0
Falcosidekickdernière version du chartRoutage des alertes vers Slack, Discord, un SIEM, etc.
Cluster Kubernetesmanagé (GKE, AKS, EKS) ou auto-géréEnvironnement cible du déploiement

Un point technique mérite d’être clarifié avant l’installation : le noyau Linux sous-jacent doit supporter eBPF (kernel 4.14 ou supérieur dans la grande majorité des distributions modernes utilisées par les clouds managés). Sur un cluster géré comme GKE ou AKS, ce prérequis est déjà satisfait par défaut. Falco 0.45.0 embarque les libs 0.26.0 et des drivers compatibles avec l’API 11.0.0, ce qui garantit la compatibilité avec les noyaux récents sans recompilation manuelle grâce au paradigme CO-RE (Compile Once, Run Everywhere).

Étape 1 : ajouter le dépôt Helm officiel de Falco

Falco publie son chart Helm sur un dépôt dédié maintenu par la communauté falcosecurity. C’est la méthode d’installation la plus simple pour un premier déploiement, même si le projet recommande désormais aussi l’Opérateur Falco pour les environnements à grande échelle avec plusieurs clusters.

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm search repo falcosecurity/falco

Sortie attendue de la dernière commande :

NAME                    CHART VERSION   APP VERSION     DESCRIPTION
falcosecurity/falco     4.x.x           0.45.0          Falco is a cloud native runtime security tool

Si la commande helm search repo ne renvoie rien, le dépôt n’a probablement pas été ajouté correctement. Relancez helm repo update et vérifiez votre connectivité réseau sortante depuis la machine qui exécute Helm (proxy d’entreprise, pare-feu sortant bloquant github.io).

Étape 2 : créer le namespace dédié et installer Falco

Isoler Falco dans son propre namespace facilite la gestion des droits RBAC et la lisibilité des logs. La commande d’installation officielle active le mode tty, utile pour visualiser les logs en temps réel pendant les tests.

helm install --replace falco \
  --namespace falco \
  --create-namespace \
  --set tty=true \
  falcosecurity/falco

Par défaut, Falco 0.45.0 s’appuie sur le driver Modern eBPF probe, qui utilise le paradigme CO-RE pour éviter toute compilation spécifique à chaque version de noyau. C’est un changement important par rapport aux anciennes générations de Falco, qui dépendaient d’un module noyau nécessitant parfois une recompilation manuelle sur les distributions Linux les plus strictes. Vérifiez que le déploiement tourne sur chaque nœud, car Falco fonctionne en DaemonSet :

kubectl get pods -n falco -o wide
kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=50

Vous devez voir un pod Falco par nœud du cluster, à l’état Running. Les premières lignes de logs confirment le driver utilisé et le chargement du jeu de règles par défaut.

Étape 3 : comprendre l’anatomie d’une règle Falco

Une règle Falco est une déclaration YAML composée de cinq champs principaux : rule (nom), desc (description), condition (l’expression logique déclenchant l’alerte), output (le message formaté avec les champs contextuels) et priority (le niveau de gravité). Voici un exemple représentatif détectant l’ouverture d’un shell interactif dans un conteneur, un des signaux les plus classiques de compromission :

- rule: Terminal shell in container
  desc: Détecte le lancement d'un shell interactif dans un conteneur
  condition: >
    spawned_process and container and
    proc.name in (bash, sh, zsh, ash)
  output: >
    Shell interactif détecté dans un conteneur
    (user=%user.name container=%container.name
    image=%container.image.repository
    command=%proc.cmdline pid=%proc.pid)
  priority: WARNING
  tags: [container, shell, mitre_execution]

Les niveaux de priorité Falco suivent une échelle classique de sévérité, de la plus critique à la plus anodine : EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFORMATIONAL, DEBUG. Ce classement détermine comment les alertes sont filtrées en aval, par exemple pour n’envoyer sur un canal Slack d’astreinte que les événements CRITICAL et au-dessus, tout en archivant le reste dans un SIEM.

Étape 4 : écrire une règle personnalisée adaptée à votre environnement

Les règles par défaut couvrent des scénarios génériques (accès à des fichiers sensibles, écriture dans un binaire système, ouverture de socket réseau inattendue). Mais la vraie valeur de Falco apparaît quand vous écrivez des règles calquées sur le comportement normal de vos propres applications. Créez un fichier custom_rules.yaml :

- rule: Connexion sortante non autorisée depuis un pod de paiement
  desc: Alerte si un pod du namespace "paiement" initie une connexion
        sortante vers une IP hors de la plage interne attendue
  condition: >
    outbound and container and
    k8s.ns.name = "paiement" and
    not fd.sip in (allowed_payment_ips)
  output: >
    Connexion sortante suspecte depuis paiement
    (namespace=%k8s.ns.name pod=%k8s.pod.name
    dest_ip=%fd.sip dest_port=%fd.sport process=%proc.name)
  priority: CRITICAL
  tags: [network, exfiltration, paiement]

- list: allowed_payment_ips
  items: ["10.0.4.10", "10.0.4.11"]

Déployez ensuite ce fichier via Helm en le montant comme règle additionnelle :

helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --set-file customRules."custom_rules\.yaml"=./custom_rules.yaml

Redémarrez les pods Falco pour recharger la configuration, ou utilisez le nouvel endpoint de suivi du statut des rechargements introduit dans la version 0.45.0, qui permet de vérifier que les règles personnalisées ont bien été prises en compte sans redémarrage complet du DaemonSet.

Étape 5 : déclencher un événement contrôlé pour valider la détection

Avant de faire confiance à une installation Falco, testez-la avec un scénario inoffensif mais représentatif. Ouvrez un shell dans n’importe quel pod du cluster :

kubectl exec -it nginx-deployment-7d9f8c -- /bin/sh

Puis, dans un second terminal, observez les logs Falco en direct :

kubectl logs -n falco -l app.kubernetes.io/name=falco -f

Sortie attendue au moment de l’exécution du shell :

10:42:17.881442000: Warning Shell interactif détecté dans un conteneur
(user=root container=nginx-deployment-7d9f8c
image=nginx command=sh pid=48213)
priority=Warning rule="Terminal shell in container"
tags=container,shell,mitre_execution

Si aucune ligne n’apparaît, passez directement à la section dépannage plus bas : le problème vient presque toujours soit du driver eBPF non chargé, soit d’une règle désactivée dans la configuration.

Étape 6 : router les alertes avec Falcosidekick

Par défaut, Falco écrit ses alertes en stdout et dans les logs du pod, ce qui n’est pas exploitable en production. Falcosidekick est le composant officiel qui relaie chaque événement Falco vers des dizaines de destinations : Slack, Microsoft Teams, PagerDuty, Elasticsearch, Loki, un webhook générique, ou un SIEM. Le projet revendique le support de plus de 50 cibles de sortie différentes. Activez-le directement via le chart Helm principal :

helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true \
  --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/VOTRE/WEBHOOK/ICI" \
  --set tty=true

L’option falcosidekick.webui.enabled=true déploie en plus une interface web légère qui affiche l’historique des alertes sous forme de tableau de bord, pratique pour une astreinte de nuit qui veut un coup d’œil rapide sans se connecter à un SIEM complet. Exposez-la via un port-forward pour un test local :

kubectl port-forward -n falco svc/falco-falcosidekick-ui 2802:2802

L’interface est ensuite accessible sur http://localhost:2802.

Étape 7 : ajouter le contexte Kubernetes complet aux alertes

Une alerte Falco brute mentionne un PID et un nom de conteneur, mais pas forcément le déploiement, le ReplicaSet ou le service concerné. Le plugin d’enrichissement Kubernetes ajoute ces métadonnées automatiquement à chaque événement. Vérifiez qu’il est actif dans la configuration :

kubectl get configmap falco -n falco -o yaml | grep -A5 k8s_metadata

Avec ce contexte, une alerte type ressemble à ceci une fois enrichie côté Falcosidekick :

{
  "rule": "Terminal shell in container",
  "priority": "Warning",
  "output_fields": {
    "k8s.ns.name": "production",
    "k8s.pod.name": "api-checkout-6f9b7",
    "k8s.deployment.name": "api-checkout",
    "container.image.repository": "registry.internal/api-checkout",
    "user.name": "root",
    "proc.cmdline": "sh"
  }
}

Ce niveau de détail est ce qui transforme une alerte technique en ticket d’incident actionnable pour une équipe SRE ou SOC.

Étape 8 : utiliser les plugins pour couvrir l’audit Kubernetes et le cloud

Falco ne se limite pas aux appels système du noyau. Son architecture de plugins permet d’ingérer d’autres sources d’événements, notamment les logs d’audit Kubernetes (plugin k8saudit) pour détecter des actions suspectes au niveau de l’API server (création d’un ClusterRoleBinding permissif, exec dans un pod via l’API, suppression massive de ressources), ou des logs cloud comme CloudTrail côté AWS. La gestion de ces plugins et des règles associées passe par l’outil falcoctl, livré en version 0.14.2 avec Falco 0.45.0 :

falcoctl artifact list
falcoctl artifact install k8saudit
falcoctl artifact install k8saudit-rules

Sur un cluster managé, l’ingestion des logs d’audit Kubernetes nécessite généralement un webhook configuré côté API server, ce qui est plus simple sur un cluster auto-géré que sur une offre managée type GKE ou AKS. Si votre cluster est géré, pensez à combiner Falco avec les journaux d’audit natifs du fournisseur plutôt que de forcer le plugin k8saudit.

Étape 9 : ajuster les règles pour réduire les faux positifs

Le principal reproche adressé à toute solution de détection comportementale, Falco inclus, est le volume de faux positifs générés au démarrage. Les notes de version de Falco 0.45.0 illustrent bien cette maintenance continue : la règle “Read sensitive file untrusted” a été ajustée pour exclure les activités attendues des helpers systemd, qui déclenchaient auparavant des alertes inutiles sur les nœuds standards. C’est un bon exemple du travail d’affinage qu’il faut reproduire pour votre propre environnement.

La méthode recommandée consiste à faire tourner Falco en mode observation pendant une à deux semaines sur un environnement de préproduction, à collecter les alertes générées, puis à créer des exceptions ciblées plutôt que de désactiver des règles entières. Exemple d’exception pour un outil de monitoring légitime qui lit des fichiers sensibles :

- macro: monitoring_agent_legitime
  condition: proc.name = "node-exporter" and container.image.repository contains "prometheus"

- rule: Read sensitive file untrusted
  append: true
  condition: and not monitoring_agent_legitime

L’usage de append: true permet d’étendre une règle existante sans la réécrire entièrement, ce qui facilite la maintenance lors des montées de version futures de Falco.

Étape 10 : combiner Falco avec les contrôles pré-déploiement existants

Falco n’a de sens que comme une couche parmi d’autres dans une stratégie de défense en profondeur. Le tableau suivant situe sa place par rapport aux outils déjà couverts sur shattered.io.

Couche de sécuritéOutilMoment d’actionCe qu’il détecte
Scan d’imageTrivyAvant déploiement (CI/CD)CVE connues dans les dépendances et l’OS de l’image
Inventaire logicielSyft / Grype (SBOM)Avant déploiementComposants logiciels et licences embarqués
Politique d’admissionKyverno / OPA GatekeeperAu moment du déploiementConteneurs privilégiés, images non signées, ressources non conformes
Réseau Zero TrustCiliumEn continu, niveau réseauTrafic non autorisé entre pods
Détection runtimeFalcoEn continu, niveau noyauComportements anormaux d’un processus déjà en exécution

Cette complémentarité explique pourquoi Falco est aujourd’hui un projet CNCF “graduated”, la CNCF le décrivant comme le moteur de référence pour la détection des menaces sur Kubernetes. Aucun de ces outils ne remplace les autres : un scanner d’image ne voit rien une fois le conteneur démarré, et Falco ne bloque rien avant l’exécution, il se contente d’observer et d’alerter.

Étape 11 : surveiller les ressources et la charge sur les nœuds

Falco tourne en DaemonSet, donc un pod par nœud, ce qui signifie que son empreinte ressource doit être suivie de près sur les clusters à forte densité de pods. Mettez en place des limites de ressources explicites dans les valeurs Helm plutôt que de laisser le comportement par défaut :

helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --set resources.requests.cpu=100m \
  --set resources.requests.memory=512Mi \
  --set resources.limits.cpu=500m \
  --set resources.limits.memory=1024Mi

Le volume d’événements traités dépend directement du nombre de processus actifs par nœud et du nombre de règles chargées : un nœud qui héberge des dizaines de pods à forte activité I/O consommera davantage de CPU côté Falco qu’un nœud avec quelques services au repos. Surveillez cette consommation avec Prometheus (voir notre tutoriel Prometheus et Grafana sur Kubernetes si ce n’est pas déjà en place) avant d’élargir le déploiement à l’ensemble du cluster.

Étape 12 : mettre en place une règle de réponse automatisée

Falcosidekick peut déclencher des actions automatiques au-delà d’une simple notification, par exemple appeler un webhook qui isole un pod suspect en lui appliquant une NetworkPolicy restrictive. Voici un exemple de configuration ciblant un webhook générique branché sur un script de remédiation :

helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.webhook.address="http://remediation-service.security.svc:8080/isolate" \
  --set falcosidekick.config.webhook.minimumpriority="critical"

Le paramètre minimumpriority est important : il évite de déclencher une réponse automatique sur chaque alerte WARNING, ce qui provoquerait un isolement en boucle sur des faux positifs mal filtrés. Réservez la réponse automatique aux priorités CRITICAL et ALERT, et gardez les niveaux inférieurs pour une revue humaine asynchrone.

Projet complet : stack Falco fonctionnelle de bout en bout

Pour assembler l’ensemble des étapes précédentes en un déploiement reproductible, voici un fichier values-falco.yaml complet à utiliser tel quel en environnement de test :

tty: true

driver:
  kind: modern_ebpf

resources:
  requests:
    cpu: 100m
    memory: 512Mi
  limits:
    cpu: 500m
    memory: 1024Mi

falcosidekick:
  enabled: true
  webui:
    enabled: true
  config:
    slack:
      webhookurl: "https://hooks.slack.com/services/VOTRE/WEBHOOK/ICI"
      minimumpriority: "warning"
    webhook:
      address: "http://remediation-service.security.svc:8080/isolate"
      minimumpriority: "critical"

customRules:
  custom_rules.yaml: |-
    - rule: Terminal shell in container
      desc: Détecte le lancement d'un shell interactif dans un conteneur
      condition: >
        spawned_process and container and
        proc.name in (bash, sh, zsh, ash)
      output: >
        Shell interactif détecté (user=%user.name
        container=%container.name command=%proc.cmdline)
      priority: WARNING
      tags: [container, shell]

Déploiement en une seule commande :

helm install --replace falco \
  --namespace falco \
  --create-namespace \
  -f values-falco.yaml \
  falcosecurity/falco

Cette configuration donne une base de production minimale : driver eBPF moderne, limites de ressources explicites, Falcosidekick actif avec deux canaux de sortie (Slack pour la visibilité humaine, webhook pour la remédiation automatisée sur les alertes critiques), et une règle personnalisée de démonstration.

5 pièges fréquents à éviter avec Falco

  • Activer toutes les règles par défaut sans tri. Le jeu de règles standard génère un volume d’alertes important sur un cluster hétérogène. Désactivez ou ajustez les règles non pertinentes pour votre stack dès le premier jour, plutôt que de laisser l’équipe se désensibiliser face à un flux ingérable.
  • Oublier les limites de ressources sur le DaemonSet. Sans requests et limits explicites, Falco peut consommer une part disproportionnée du CPU d’un nœud sous forte charge d’appels système, au détriment des workloads applicatifs.
  • Confondre détection et blocage. Falco alerte, il ne bloque rien par défaut. Une équipe qui pense être protégée contre l’exécution d’un shell malveillant simplement parce que Falco est installé se trompe : sans automatisation de réponse (via Falcosidekick et un webhook), l’attaquant a tout le temps d’agir avant qu’un humain ne lise l’alerte.
  • Déployer sans tester le driver eBPF au préalable. Certains environnements très restreints (kernels très anciens, certains runtimes de sécurité renforcés) peuvent bloquer le chargement du driver. Vérifiez toujours les logs du pod juste après l’installation avant de considérer le déploiement terminé.
  • Ignorer le contexte Kubernetes dans les règles personnalisées. Une règle qui ne filtre pas par k8s.ns.name ou k8s.pod.name s’applique à l’ensemble du cluster, y compris aux namespaces système où certains comportements “suspects” sont en réalité normaux (kube-system, monitoring).

Conseils avancés pour une exploitation en production

Une fois la base en place, plusieurs ajustements améliorent nettement la valeur opérationnelle de Falco. Premièrement, séparez les canaux de notification par criticité plutôt que de tout envoyer sur un seul webhook Slack : les alertes INFORMATIONAL et NOTICE vers un canal d’archivage low-noise, les alertes CRITICAL et ALERT vers un canal d’astreinte avec notification push. Deuxièmement, versionnez vos règles personnalisées dans un dépôt Git séparé et déployez-les via votre pipeline GitOps existant (voir notre tutoriel gestion des secrets Kubernetes pour la partie identifiants du pipeline), ce qui permet un historique d’audit complet sur qui a modifié quelle règle et pourquoi.

Troisièmement, croisez systématiquement les alertes Falco avec les logs d’admission Kyverno : une tentative d’exécution de shell dans un pod qui a par ailleurs été déployé avec une image non scannée par Trivy constitue un signal beaucoup plus fort qu’une alerte Falco isolée. Cette corrélation multi-couches est ce qui distingue une vraie détection d’intrusion d’un simple flux d’événements bruts. Enfin, sur un cluster multi-tenant, envisagez des jeux de règles différenciés par namespace ou par équipe, avec des seuils de criticité adaptés au niveau de sensibilité de chaque charge de travail (un environnement de paiement mérite un seuil d’alerte plus bas qu’un environnement de démonstration interne).

Un dernier conseil concerne la gouvernance des règles sur la durée. Une organisation qui déploie Falco sur plusieurs clusters gagne à centraliser la définition des règles critiques (paiement, données personnelles, accès administrateur) dans un dépôt commun versionné, tout en laissant chaque équipe applicative ajouter ses propres macros d’exception locales. Cette séparation évite deux écueils opposés : un socle de sécurité trop rigide qui génère des faux positifs ingérables équipe par équipe, ou à l’inverse une dilution complète des règles critiques si chaque équipe part de zéro. Documentez également, dans le message de commit de chaque modification de règle, la raison métier de l’ajustement (par exemple “exclusion du process de backup nocturne, ticket JIRA SEC-482”), ce qui facilite grandement les audits de conformité a posteriori, en particulier dans le cadre des obligations de traçabilité imposées par NIS2 aux entités essentielles et importantes en France.

Dépannage : 8 problèmes courants et leurs solutions

  • Le pod Falco reste en CrashLoopBackOff. Vérifiez les logs avec kubectl logs -n falco <pod> --previous. La cause la plus fréquente est un driver eBPF incompatible avec le noyau du nœud : forcez temporairement le driver kernel module pour isoler le problème.
  • Aucune alerte n’apparaît malgré un shell ouvert dans un pod. Confirmez que la règle “Terminal shell in container” n’a pas été désactivée dans la configuration, et que le namespace testé n’est pas exclu par une macro par défaut.
  • Volume d’alertes ingérable dès le premier jour. C’est normal sur un cluster jamais audité. Filtrez d’abord par priorité (masquez temporairement NOTICE et INFORMATIONAL) le temps d’identifier les règles à ajuster.
  • Falcosidekick ne relaie rien vers Slack. Testez le webhook Slack indépendamment avec une requête curl manuelle avant de suspecter Falcosidekick. Une URL de webhook expirée ou révoquée est la cause la plus fréquente.
  • Consommation CPU anormalement élevée sur certains nœuds. Un nœud avec une charge I/O très intense (base de données, ingestion de logs) génère mécaniquement plus d’appels système à analyser. Ajustez les limits et envisagez d’exclure certains processus connus et fiables via une macro.
  • Le plugin k8saudit ne reçoit aucun événement. Sur un cluster managé, l’API server ne permet généralement pas de configurer un webhook d’audit personnalisé sans passer par les mécanismes natifs du fournisseur cloud. Vérifiez la documentation spécifique à votre offre managée avant de déboguer côté Falco.
  • Erreur lors du chargement d’une règle personnalisée. Une erreur de syntaxe YAML dans custom_rules.yaml empêche parfois le chargement de l’ensemble du fichier, pas seulement de la règle fautive. Validez le YAML avec un linter avant chaque déploiement.
  • Les alertes manquent de contexte Kubernetes (pas de nom de pod). Le plugin d’enrichissement k8s_metadata doit être explicitement activé dans la configuration ; vérifiez sa présence dans la ConfigMap Falco et redéployez si nécessaire.

Adoption de Falco : statut CNCF, communauté et écosystème

Falco n’est pas un projet expérimental. Il a rejoint la Cloud Native Computing Foundation en 2018 et a franchi depuis les trois étapes de maturité de la fondation jusqu’au statut “graduated”, le plus élevé, réservé à un nombre restreint de projets aux côtés de Kubernetes lui-même, Prometheus ou Envoy. La page officielle du projet sur le site de la CNCF confirme ce statut et présente Falco comme un outil de détection de menaces pour environnements cloud natifs. Le dépôt falcosecurity/falco sur GitHub affiche environ 9,4 milliers d’étoiles et 124 releases publiées au moment de la rédaction de cet article, un rythme de publication qui traduit une maintenance active du projet plutôt qu’un outil laissé à l’abandon après son passage en fondation.

Du côté des entreprises utilisatrices, la CNCF recense plusieurs adoptants publics et auto-déclarés du projet, parmi lesquels Booz Allen Hamilton, GitLab, Shopify, Cisco, Skyscanner ou encore Vinted. Cette liste reste partielle puisqu’elle ne recense que les organisations ayant accepté de communiquer publiquement leur usage de l’outil, mais elle illustre la diversité des secteurs concernés, du conseil à l’e-commerce en passant par les infrastructures cloud elles-mêmes. Pour une équipe française qui évalue Falco, cet historique compte autant que les fonctionnalités techniques : un projet “graduated” bénéficie d’un processus de gouvernance formalisé, d’audits de sécurité réguliers exigés par la CNCF, et d’une feuille de route publique moins dépendante d’une seule entreprise commerciale.

Falco face aux autres outils de sécurité runtime eBPF

Falco n’est pas le seul projet à exploiter eBPF pour la sécurité Kubernetes. Cilium Tetragon, en version 1.7.1 depuis le 25 août 2026, propose une approche voisine avec une compréhension native des identités Kubernetes (namespaces, pods) pour contextualiser les événements de sécurité directement au niveau du plan de données réseau. La différence de positionnement tient surtout à l’origine du projet : Tetragon s’intègre naturellement si vous utilisez déjà Cilium comme CNI, tandis que Falco reste agnostique du CNI et se concentre spécifiquement sur la détection comportementale au niveau du noyau, indépendamment de la couche réseau. Pour une équipe qui a déjà standardisé sur Cilium, les deux outils sont complémentaires plutôt que concurrents.

Sur le plan de la maturité du projet, Falco bénéficie d’une antériorité notable : il a rejoint la CNCF dès 2018 et a atteint le statut “graduated”, le plus élevé de la fondation, aux côtés de Kubernetes lui-même et d’un nombre restreint d’autres projets. Cette maturité se traduit concrètement par un écosystème de règles communautaires plus large et par une intégration native dans la plupart des plateformes de sécurité cloud native commerciales.

Pour une équipe qui hésite entre les deux approches, un critère pratique simplifie souvent la décision : la CNI déjà en place. Si le cluster utilise Calico, Flannel ou le CNI natif du cloud managé, Falco s’installe de façon totalement indépendante sans contrainte d’architecture réseau. Si le cluster tourne déjà sur Cilium, Tetragon mérite une évaluation en parallèle puisqu’il partage la même stack de collecte eBPF que le plan de données réseau, ce qui réduit potentiellement le nombre de composants distincts à superviser. Aucune des deux options n’exclut l’autre : plusieurs organisations font tourner Falco pour la détection comportementale générale et Tetragon pour l’observabilité réseau fine, les deux alimentant le même pipeline d’alertes en aval.

Questions fréquentes

Falco remplace-t-il un antivirus classique sur mes nœuds Kubernetes ?

Non. Falco détecte des comportements anormaux au niveau des appels système, pas des signatures de malwares connus. Il complète un antivirus ou un EDR plutôt qu’il ne le remplace, en particulier sur des menaces inédites qui n’ont pas de signature répertoriée.

Falco fonctionne-t-il sur un cluster managé comme GKE, AKS ou EKS ?

Oui, Falco se déploie sans difficulté particulière sur les trois principaux clouds managés via le chart Helm officiel. Seule l’ingestion des logs d’audit Kubernetes via le plugin k8saudit peut nécessiter des ajustements spécifiques au fournisseur, les clusters managés limitant généralement l’accès direct à la configuration de l’API server.

Quelle est la différence entre le driver kernel module et le driver Modern eBPF de Falco ?

Le kernel module nécessite une compilation spécifique à chaque version de noyau Linux, ce qui complique les mises à jour. Le Modern eBPF probe, recommandé par défaut depuis plusieurs versions et confirmé comme mode par défaut dans la documentation de l’Opérateur Falco, utilise le paradigme CO-RE pour fonctionner sans recompilation sur la majorité des noyaux récents.

Falco peut-il bloquer automatiquement un conteneur compromis ?

Pas nativement. Falco est un outil de détection, pas de prévention. Le blocage ou l’isolement automatique passe par Falcosidekick configuré avec un webhook déclenchant une action externe (suppression du pod, application d’une NetworkPolicy restrictive), qu’il faut construire et tester séparément.

Combien coûte l’utilisation de Falco ?

Falco est un projet open source sous gouvernance CNCF, disponible gratuitement. Le coût réel se situe dans les ressources de calcul consommées par le DaemonSet sur chaque nœud, ainsi que dans le temps d’ingénierie nécessaire pour affiner les règles et réduire les faux positifs sur la durée.

Falco est-il adapté à une petite équipe sans SOC dédié ?

Oui, à condition de commencer avec un périmètre restreint. Déployez d’abord sur les namespaces les plus sensibles, routez les alertes critiques uniquement vers un canal Slack simple, et élargissez progressivement plutôt que d’activer l’ensemble des règles sur tout le cluster dès le premier jour.

Comment tester mes règles Falco avant de les déployer en production ?

La méthode la plus fiable reste de déployer d’abord la règle sur un cluster de préproduction, de générer volontairement le comportement ciblé (comme dans l’étape 5 de ce tutoriel), puis de vérifier la sortie exacte de l’alerte avant de promouvoir la règle en production via votre pipeline GitOps.

Falco peut-il surveiller des environnements hors Kubernetes ?

Oui. Falco fonctionne également sur des hôtes Linux classiques sans orchestrateur, et son système de plugins permet d’étendre la détection à des environnements cloud via des sources d’événements comme les journaux d’audit cloud, au-delà du seul périmètre Kubernetes. Sur un hôte Linux classique, l’installation se fait via un paquet natif (deb, rpm) ou un binaire statique, sans dépendre de l’API Kubernetes, ce qui en fait aussi une option pertinente pour sécuriser des machines virtuelles ou des serveurs bare-metal en dehors de tout cluster.