Falco : runtime security eBPF pour Kubernetes en production

La sécurité périmétrique ne suffit plus. Une fois qu'un attaquant a un shell dans un pod, le firewall, l'IDS de bordure, le WAF et l'antivirus n'ont plus rien à dire. Ce qui se passe au niveau syscall sur un noeud reste invisible aux couches L3-L7 classiques.

Falco couvre ce trou. Outil CNCF gradué depuis 2024, créé par Sysdig et donné à la fondation, il observe en temps réel les syscalls Linux via eBPF, les enrichit avec le contexte container et Kubernetes, et alerte sur les comportements suspects. Son périmètre est précis : runtime security, pas vulnerability scanning ni audit de conf.

En prod, c'est l'outil qu'on déploie pour répondre à la question "qu'est-ce qui se passe vraiment dans mes pods, là, maintenant".

• Pourquoi runtime security et pas vuln scan
• Architecture : sources de données et moteur de règles
• eBPF moderne vs kernel module legacy
• Déploiement DaemonSet et configuration cluster
• Règles standards et règles custom
• Falcosidekick : router les alertes
• Intégration SIEM, SOAR, observabilité
• Pièges et signaux à surveiller

Trois familles d'outils sécurité conteneur à ne pas confondre.

Vulnerability scanning (Trivy, Grype, Snyk) : analyse statique des images. Détecte les CVE dans les binaires et libs. S'exécute en CI/CD ou sur le registre.

Admission control (OPA Gatekeeper, Kyverno) : applique des politiques au moment du kubectl apply. Empêche un pod privilégié de démarrer, force une labelisation, voir k8s OPA Gatekeeper.

Runtime security (Falco, Tetragon, Tracee) : observe ce qui se passe pendant l'exécution. Détecte un shell ouvert dans un pod, une écriture dans /etc/passwd, une connexion sortante anormale, un processus qui mine du crypto.

Les trois sont complémentaires. Falco couvre le runtime, là où les autres ne voient rien. Sans runtime, on découvre une compromission par un audit DSI 6 mois après. Avec runtime, on détecte dans les minutes qui suivent.

Falco fonctionne en trois couches.

Sources d'événements. Par défaut deux : syscalls (capturés par driver eBPF ou kernel module) et événements Kubernetes audit log. Via plugins, on peut ajouter des sources : AWS CloudTrail, GitHub audit, Okta logs, Kubernetes audit, GCP audit. Chaque source produit des événements typés.

Enrichissement contextuel. Chaque événement syscall est enrichi avec le pod, le namespace, l'image, le service account, les labels Kubernetes. C'est ce qui rend les alertes actionnables. Au lieu de "spawn de /bin/sh sur PID 4287", on a "spawn de /bin/sh dans pod billing-api-7d4c, namespace prod, image registry.ex.fr/billing:1.42, service account billing-sa".

Moteur de règles. Falco évalue les événements contre des règles YAML déclaratives. Le ruleset par défaut couvre 70+ patterns connus : shell dans container, écriture sensible (/etc, /var/log), processus privilégié, modifications de binaires, connexions réseau anormales, etc.

Une règle ressemble à ça :

- rule: Terminal shell in container
  desc: A shell was used as the entrypoint or attached to a container
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
    and container_entrypoint
    and not user_expected_terminal_shell_in_container_conditions
  output: >
    A shell was spawned in a container with an attached terminal
    (user=%user.name user_loginuid=%user.loginuid %container.info
    shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
  priority: NOTICE
  tags: [container, shell, mitre_execution]

Le moteur évalue chaque événement contre toutes les règles applicables, génère une alerte si match, l'envoie aux outputs configurés (stdout, syslog, gRPC, HTTP, file).

Trois drivers d'instrumentation possibles.

eBPF moderne (CO-RE) : recommandé en 2026. Compatibility "compile once, run everywhere", chargé dynamiquement, nécessite kernel 5.8+. Pas de compilation au runtime, pas de kernel-headers requis. C'est le défaut.

eBPF legacy : ancien driver eBPF, déprécié dans v0.43.0, supprimé prochainement. Ne pas démarrer un déploiement neuf dessus.

Kernel module : driver historique, compilé au démarrage. Nécessite les headers kernel sur les noeuds. Pénible à opérer sur un parc hétérogène. À éviter sauf cas spécifique (kernel trop ancien).

Pour un cluster RKE2, K3s ou une distro K8s récente, on prend eBPF CO-RE par défaut. C'est dans la lignée de la révolution eBPF qu'on a documentée, et c'est aussi la base du networking Cilium.

Helm chart officiel, install nominale :

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco \
  --namespace falco \
  --create-namespace \
  --set driver.kind=modern_ebpf \
  --set tty=true \
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true

Le chart déploie :

• un DaemonSet Falco (un pod par noeud)
• les CRD FalcoRule si on active le sous-projet rules CRD
• Falcosidekick (le routeur d'alertes) si activé
• Falcosidekick UI (interface web pour visualiser les events)

Sur un cluster bare metal qu'on a documenté dans le pattern edge K3s + Ceph, Falco s'intègre proprement comme DaemonSet et observe les workloads sans surcoût significatif (typiquement 1-3% CPU, 50-100 Mo RAM par noeud).

Points de configuration importants :

• Privilégié : le DaemonSet Falco doit avoir des capabilities (SYS_PTRACE, SYS_ADMIN pour eBPF). Ce n'est pas évitable, c'est la nature de l'outil. À documenter dans la matrice RBAC de prod.
• Outputs : configurer au minimum stdout (visible via kubectl logs) et un output structuré (gRPC vers Falcosidekick).
• Rules custom : monter via ConfigMap.
• Buffer size : par défaut 8 Mo. Sur un noeud très chargé en syscalls, augmenter à 16 ou 32 Mo pour éviter les drops.

Le ruleset par défaut Falco couvre les patterns d'attaque MITRE ATT&CK les plus fréquents en environnement conteneur. À enrichir avec des règles métier.

Exemple de règle custom : alerter quand un pod accède à un endpoint metadata cloud (AWS IMDS, GCP, Azure metadata) hors d'une liste blanche.

- rule: Pod accessing metadata service
  desc: Detect pods accessing cloud metadata service unexpectedly
  condition: >
    outbound and fd.sip = "169.254.169.254"
    and not k8s.ns.name in (allowed_metadata_namespaces)
  output: >
    Pod %k8s.pod.name in namespace %k8s.ns.name accessed metadata service
    (image=%container.image.repository)
  priority: WARNING
  tags: [cloud, metadata, exfiltration]

Pour la gestion des règles à grande échelle :

• Versionner toutes les règles en Git, déployées par GitOps (Argo CD ou Flux). Aligner sur argo-cd-gitops ou flux gitops.
• Tester chaque règle dans un cluster lab avant push prod. Une règle mal écrite peut générer 100k alertes par minute et saturer le SIEM.
• Tagger les règles avec des références MITRE ATT&CK pour la corrélation côté SOC.

Falco produit des événements. Falcosidekick les distribue aux outils en aval. Sans Falcosidekick, on a Falco isolé. Avec, on a 60+ destinations possibles : Slack, PagerDuty, Webex, Mattermost, Discord, Elasticsearch, Loki, Splunk, S3, NATS, Kafka, AWS Lambda, GCP Pub/Sub, et la plupart des SIEM/SOAR.

Pattern de prod typique :

• Alertes priority: ERROR ou CRITICAL → PagerDuty (oncall)
• Toutes les alertes → Slack channel #sec-alerts pour visibilité équipe
• Toutes les alertes → Loki via push HTTP, indexées par labels K8s
• Alertes de catégorie sensible (filesystem, secrets) → S3 bucket immutable pour audit

Falcosidekick UI (sous-projet) offre une interface web pour parcourir les alertes en quasi temps réel. Pratique pour les équipes qui n'ont pas encore intégré un SIEM complet.

Falco produit du JSON structuré. L'ingestion dans un SIEM est mécanique. Quelques patterns courants :

• Wazuh : Falco events ingérés via Filebeat ou agent Wazuh, corrélation côté manager. Voir notre article wazuh-siem pour le contexte.
• Loki : push HTTP direct depuis Falcosidekick, label set falco_rule, priority, k8s_namespace, k8s_pod. Dashboards Grafana prêts à l'emploi sur le hub Grafana.
• Elastic : via Elastic SIEM rules adaptées. La cohérence d'index nécessite un mapping ECS pour bénéficier des dashboards built-in.
• SOAR (Tines, Shuffle, Cortex XSOAR) : webhook Falcosidekick déclenche playbook automatique. Exemple : alerte "shell in pod" → cordon noeud, isolation pod, snapshot mémoire pour forensics, page oncall.

Pour la couche logging applicative générique, stack Loki ou Vector restent valides comme passerelles.

Bruit initial. À l'activation, Falco génère beaucoup d'alertes "Terminal shell in container" car les images d'init, les jobs CronJob, les sidecars peuvent légitimement spawner des shells. Pendant 2-3 semaines, baseline du bruit, ajout d'exclusions par namespace ou par image, jusqu'à ne garder que les vraies anomalies.

Charge syscall élevée. Sur des workloads très IO-intensive (DB, queues), le volume d'événements eBPF capturés peut peser. Filtrer agressivement à la source via syscall_event_drops.threshold ou exclure les containers connus pour être bruyants.

Drift entre règles upstream et règles custom. Le ruleset Falco évolue. Prévoir une revue trimestrielle pour réintégrer les patterns qui ont été ajoutés upstream.

Faux positifs et alert fatigue. Une équipe sécurité noyée sous 1000 alertes/jour ne lit plus. Le critère de succès n'est pas "Falco déployé", c'est "alertes Falco actionnées par l'oncall avec un taux de faux positifs sous 10%".

Compatibilité kernel. En passant de eBPF legacy à modern_ebpf, vérifier les kernels du parc. Sur des distros LTS anciennes, le kernel 5.8 n'est pas garanti.

Sur les clusters K8s qu'on opère pour nos clients, Falco est devenu la brique runtime security par défaut. La valeur ne vient pas de l'install (5 minutes en Helm), mais du tuning des règles, de l'intégration SIEM/SOAR, et du runbook qui transforme une alerte en action humaine. Si vous avez Falco déployé mais que les alertes finissent dans un Slack que personne ne lit, on peut auditer votre dispositif et opérer le pipeline jusqu'à l'oncall pour qu'il devienne réellement efficace.

• Falco documentation officielle : architecture, règles, drivers, plugins.
• GitHub falcosecurity/falco : code, releases, ruleset upstream.
• Falco CNCF graduated announcement - Sysdig : étape de maturité du projet.
• CNCF Falco landscape : positionnement et adopters.
• Falcosidekick GitHub : outputs, intégrations, configuration.
• MITRE ATT&CK for Containers : référentiel des techniques d'attaque adressées par les règles Falco.