Intégration Falco + OpenTelemetry : corrélation runtime security et observabilité — tutoriel 2026

Méta-description : Falco détecte les comportements suspects à l’exécution. OpenTelemetry trace l’application. Les marier permet de répondre à la question critique : « cet appel suspect, sur quelle requête utilisateur a-t-il eu lieu ? ». Tutoriel pas-à-pas 2026 pour cluster k3s sur Hetzner CX22.

Pourquoi corréler sécurité runtime et observabilité ?

En 2026, deux disciplines ont mûri en parallèle dans l’écosystème cloud-native : la runtime security (détecter qu’un processus suspect lit /etc/shadow ou se connecte à une IP inconnue) et l’observabilité applicative (tracer une requête HTTP du load-balancer à la base de données en passant par chaque microservice). Le problème, c’est qu’elles vivent dans des silos : Falco crache des alertes JSON dans Loki ou Slack, pendant que Tempo, Jaeger ou Grafana montrent les traces OpenTelemetry — et personne ne fait le lien.

Pourtant, la question opérationnelle est toujours la même : « cette alerte Falco « shell-in-container », elle a eu lieu pendant quelle requête utilisateur, sur quel endpoint, depuis quelle IP cliente ? ». Sans corrélation, ton SOC perd 30 minutes à reconstituer le contexte. Avec corrélation, l’analyste a la trace OTel complète en un clic.

Ce tutoriel pose les bases techniques de cette corrélation. Il complète notre guide général Sécurité supply-chain logiciel : SBOM, signing, scanning (2026) et notre tutoriel Policy Controller Sigstore.

Prérequis

• Un cluster k3s ou kind avec au moins 4 Go RAM disponibles (Falco + OTel Collector consomment ~600 Mo).
• Une stack d’observabilité existante : Grafana + Tempo + Loki ou équivalent. Si tu pars de zéro, suis notre guide self-hosting Coolify + Hetzner pour déployer Grafana en 15 minutes.
• Connaissance de base de Helm et kubectl.
• Application instrumentée avec un SDK OpenTelemetry (Node.js, Python, Go, Java, .NET — peu importe).
• Hetzner CX22 (4,15 € HT/mois soit ~2 700 F CFA) ou supérieur. Pour un cluster prod, un CX32 (8 Go RAM) est recommandé.

Architecture cible

Voici comment les composants vont s’articuler :

1. Falco tourne en DaemonSet et lit les syscalls via eBPF (ou kernel module). Il publie chaque alerte au format JSON enrichi.
2. Falcosidekick reçoit les alertes Falco et les transforme en plusieurs flux : webhook, Slack, Mattermost, mais surtout export OTLP (OpenTelemetry Protocol).
3. OpenTelemetry Collector reçoit les traces de l’application et les alertes Falco. Il enrichit les alertes avec le trace_id et span_id de la requête en cours, puis route vers Tempo.
4. Tempo + Grafana affichent traces et alertes corrélées dans la même vue Explore.

Cette architecture est entièrement open-source, gratuite, et tient sur un cluster à 10 € HT/mois (CX32 8 Go RAM).

Installation de Falco

On utilise le chart Helm officiel maintenu par The Falco Project :

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
kubectl create namespace falco

helm install falco falcosecurity/falco \
  --namespace falco \
  --version 4.4.0 \
  --set driver.kind=ebpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.otlp.traces.endpoint=http://otel-collector.observability:4318/v1/traces \
  --set tty=true

Note importante : driver.kind=ebpf nécessite un noyau Linux 5.8+. Sur Ubuntu 22.04 LTS (kernel 5.15) ou 24.04 LTS (6.8), c’est OK. Pour un kernel ancien, utilise driver.kind=modern_ebpf ou retombe sur kernel_module.

Vérifie l’installation :

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

Tu dois voir des lignes commençant par {"hostname":"k3s-1","output":"...","priority":"Notice","rule":"..."}.

Installation du Collector OpenTelemetry

Le Collector reçoit les traces OTel de ton application (port 4317 gRPC ou 4318 HTTP) et les alertes Falco depuis Falcosidekick :

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
kubectl create namespace observability

cat > otel-values.yaml <<EOF
mode: deployment
config:
  receivers:
    otlp:
      protocols:
        grpc: {}
        http: {}
  processors:
    batch: {}
    attributes/falco:
      actions:
      - key: source.type
        value: falco
        action: insert
  exporters:
    otlp/tempo:
      endpoint: tempo.observability:4317
      tls:
        insecure: true
  service:
    pipelines:
      traces:
        receivers: [otlp]
        processors: [batch, attributes/falco]
        exporters: [otlp/tempo]
EOF

helm install otel-collector open-telemetry/opentelemetry-collector \
  --namespace observability \
  --values otel-values.yaml

Corréler les alertes avec les traces applicatives

L’astuce centrale est d’utiliser le process ID émis par Falco pour retrouver le contexte OTel actif dans le pod cible. Falco fournit dans chaque alerte les champs proc.name, proc.pid, container.id, k8s.pod.name. Ton application instrumentée OTel partage les mêmes champs k8s.pod.name via le resource detector Kubernetes.

Concrètement, dans Grafana, tu crées une Trace-to-Logs corrélation qui mappe le k8s.pod.name et le timestamp entre les deux flux. Quand tu visualises une trace OTel d’une requête HTTP qui a généré une alerte Falco au même moment dans le même pod, tu vois directement les deux côte à côte.

Pour aller plus loin, ajoute dans Falcosidekick la directive customfields qui injecte des labels supplémentaires :

customfields:
  environment: production
  region: dakar
  cluster: k3s-prod

Règles Falco utiles pour une PME

Falco est livré avec ~80 règles génériques. Voici les 5 plus pertinentes pour une PME ouest-africaine qui héberge un site WooCommerce, une API métier et quelques workers :

• Terminal Shell in Container — un shell interactif (bash, sh, zsh) lancé dans un pod = signal fort d’intrusion ou de débogage non documenté.
• Write Below Etc — écriture dans /etc par un processus non root = persistance d’attaquant.
• Read Sensitive File Untrusted — lecture de /etc/shadow, ~/.ssh/id_rsa par un processus inattendu.
• Outbound Connection To C2 Servers — connexions vers IPs malveillantes connues (utilise une threat-intel feed type AbuseIPDB).
• Container Drift Detected — un binaire exécuté qui n’était pas dans l’image originale = installation d’outil par attaquant.

Adaptation au contexte ouest-africain

Trois particularités à intégrer pour Dakar, Abidjan, Bamako, Ouagadougou et Conakry :

• Latence vers les feeds threat-intel — les feeds publics (AbuseIPDB, AlienVault OTX) sont hébergés aux USA. Latence ~200 ms depuis Dakar. Pour 1 alerte/seconde, c’est négligeable. Au-delà, mets en cache local 24h.
• Coût stockage des logs Falco — Falco peut générer 100-500 Mo de logs/jour pour un cluster de 20 pods actifs. Sur Hetzner Object Storage, ça coûte ~0,01 €/mois. Configure une rétention de 30 jours active + archive 90 jours froide.
• Gardez la conformité — la loi 2008-12 sénégalaise sur la protection des données personnelles impose la traçabilité des accès aux données sensibles. Les alertes Falco constituent une preuve technique exploitable en audit.

Cas d’usage concrets

Trois exemples de corrélations qui ont fait gagner du temps à des équipes ITSkillsCenter en 2025 :

1. SaaS RH à Abidjan — alerte « Read Sensitive File Untrusted » sur /etc/shadow. Trace OTel correspondante : requête GET /api/users/export par utilisateur authentifié john@client.ci. Verdict : faille SSRF dans la fonctionnalité d’export. Patch déployé en 2 heures.
2. E-commerce à Dakar — alerte « Outbound Connection » vers IP de minage de cryptomonnaie. Trace OTel : requête déclenchée par un cron WordPress vulnérable (plugin obsolète). Plugin retiré, signature Sigstore activée pour les futures images.
3. Plateforme média à Ouagadougou — alerte « Shell in Container » à 3h du matin. Trace OTel : aucune requête utilisateur active. Verdict : compromission d’un compte CI/CD via token GitHub fuité. Token rotated, MFA imposé.

Erreurs fréquentes à éviter

• Activer toutes les règles Falco par défaut — tu seras noyé sous les faux positifs. Démarre avec 5 règles, observe 7 jours, ajuste, ajoute progressivement.
• Ignorer les ressources — sans resources.limits, Falco peut consommer 1 Go de RAM lors d’un pic. Limite à 512 Mi.
• Oublier de signer les images Falco/OTel elles-mêmes — applique la même politique Sigstore à tes outils de sécurité.
• Confondre alerte et incident — une alerte Falco est un signal, pas une preuve d’attaque. Documente le triage.
• Ne pas tester le pipeline — lance régulièrement kubectl exec sur un pod pour vérifier que l’alerte arrive bien dans Grafana avec sa trace.

Checklist post-déploiement

• ✅ Falco DaemonSet en état Ready sur tous les nodes
• ✅ Falcosidekick configuré avec endpoint OTLP
• ✅ OpenTelemetry Collector reçoit traces application + alertes Falco
• ✅ Grafana datasource Tempo configuré
• ✅ Trace-to-Logs correlation activée sur k8s.pod.name
• ✅ 5 règles Falco minimum actives (custom rules + default)
• ✅ Alerte Slack/Mattermost configurée pour priorité Critical/Error uniquement
• ✅ Test end-to-end : kubectl exec -it pod -- bash déclenche bien une alerte visible dans Grafana avec contexte applicatif

FAQ

Falco fonctionne-t-il sur les nodes ARM (Hetzner CAX21) ?

Oui depuis Falco 0.36+. Les charts Helm détectent automatiquement l’architecture. Vérifie juste que le kernel est 5.10+ pour le mode eBPF.

Quelle différence entre Falco et un EDR commercial type CrowdStrike ?

Falco se concentre sur les conteneurs et les hôtes Linux. Pas de gestion centralisée propriétaire, pas de console SaaS. C’est plus simple et gratuit, mais demande de monter sa propre stack d’observabilité. Pour une PME < 50 personnes IT, Falco + Grafana suffit largement.

Le mode eBPF est-il compatible avec OVHcloud Managed Kubernetes ?

Oui, OVHcloud expose un kernel récent. Pour Scaleway Kapsule, vérifie la version du nœud (les anciens pools peuvent encore être en kernel 5.4).

Quelle rétention recommander pour les alertes ?

30 jours actives en chaud (Loki ou Tempo) + 1 an d’archive froide en object storage. Pour conformité ISO 27001, 1 an minimum est généralement requis.

Pour aller plus loin

• 📖 Retour au guide général Sécurité supply-chain logiciel
• 🔐 Policy Controller Sigstore sur Kubernetes pour bloquer les images non signées
• 📊 IAM open-source pour PME : Keycloak, Authelia, Authentik (2026)
• 🌍 Documentation officielle Falco et opentelemetry.io

Besoin d’accompagnement sur ta runtime security ?

Tu opères un cluster Kubernetes ou une flotte de VPS Linux et tu veux un vrai pipeline détection-corrélation-réponse, sans payer 50 000 € de licence EDR ? ITSkillsCenter propose un audit gratuit de 30 minutes pour évaluer ta posture runtime. Contacte-nous via WhatsApp +221 78 226 83 77 ou demande directement ton audit gratuit en ligne.

Philosophie de la corrélation : pourquoi la sécurité moderne est une discipline d’observabilité

La frontière entre sécurité et observabilité s’efface depuis 2023, et ce n’est pas un hasard. Les attaques modernes ne sont plus des intrusions ponctuelles que tu détectes avec un IDS et bloques avec un firewall. Ce sont des chaînes longues : reconnaissance, compromission initiale, persistance, élévation de privilèges, mouvement latéral, exfiltration. Chaque étape laisse des traces fonctionnelles dans tes logs métier, dans tes traces applicatives, dans tes métriques de performance. Les voir comme des événements isolés condamne ton équipe à toujours arriver après la bataille.

L’approche corrélée Falco + OpenTelemetry change radicalement la donne. Quand un analyste reçoit une alerte « Outbound Connection To Unknown IP », au lieu de chercher manuellement dans Loki quel pod c’était, quelle requête utilisateur l’a déclenchée, et quel était le contexte business, il a tout ça en une vue Grafana. La conséquence pratique : un incident qui prenait 4 heures à investiguer en 2022 prend désormais 20 minutes en 2026. Pour une PME francophone qui ne peut pas se permettre un SOC 24/7, c’est la différence entre détecter un incident en cours ou découvrir l’exfiltration trois semaines après.

Propagation du trace context : le détail qui change tout

OpenTelemetry standardise depuis 2021 la propagation du trace context via les en-têtes HTTP traceparent et tracestate définis dans la spec W3C. Chaque microservice qui reçoit une requête lit ces en-têtes, en hérite le trace_id, et l’injecte dans toutes ses opérations sortantes (appels HTTP, requêtes SQL, messages Kafka). Le résultat : une seule requête utilisateur de l’API gateway au worker asynchrone partage le même trace_id sur 10 services différents.

L’enjeu pour la corrélation Falco, c’est que les alertes runtime n’ont pas accès direct à ce contexte (Falco lit des syscalls noyau, pas des en-têtes HTTP). On contourne la difficulté en utilisant la fenêtre temporelle + le pod name comme clé de jointure. Concrètement, Grafana retrouve toutes les traces actives sur le pod X dans la fenêtre [alerte – 5s ; alerte + 1s] et les affiche en regard. C’est une approximation, mais elle fonctionne dans 95 % des cas en production.

Dashboards Grafana prêts à l’emploi

Trois dashboards prêts à l’emploi sont disponibles sur grafana.com/dashboards et que tu peux importer en 30 secondes. Le premier (ID 11914) affiche un overview Falco multi-cluster avec heatmap par règle, par namespace, par hostname. Le deuxième (ID 16310) est dédié à OpenTelemetry Collector et te montre la santé de tes pipelines de télémétrie. Le troisième dashboard, à construire toi-même, est le « SOC view » qui combine les deux flux : panel haut avec alertes Falco du dernier quart d’heure, panel bas avec les traces OTel correspondantes filtrées sur les pods affectés. Compte 2 heures pour le construire, mais il devient le tableau de bord central de ton équipe astreinte.

Plan de formation interne pour ton équipe

Déployer Falco + OpenTelemetry sans former l’équipe à les exploiter, c’est gaspiller son investissement. Voici un plan en 4 sessions de 2 heures que nous utilisons en mission ITSkillsCenter chez nos clients d’Afrique de l’Ouest :

1. Session 1 — Fondamentaux runtime security : qu’est-ce qu’un syscall, comment fonctionne eBPF, lecture d’une alerte Falco brute, taxonomie MITRE ATT&CK appliquée aux conteneurs. Public : développeurs et ops.
2. Session 2 — OpenTelemetry pour la sécurité : modèle de données traces/spans, ressources et attributs, correlation cross-services, instrumentation auto vs manuelle. Public : développeurs.
3. Session 3 — Triage en pratique : étude de 5 incidents simulés sur cluster de démo, du clic sur l’alerte à la rédaction du rapport post-mortem. Public : ops et astreintes.
4. Session 4 — Tuning et faux positifs : analyse des règles Falco custom, exclusions par pod label, ajustement du seuil de bruit, métriques de qualité du SOC. Public : ops avancés.

Cette formation peut être organisée en présentiel à Dakar, Abidjan ou Ouagadougou, ou en visio pour les équipes distribuées. Compte 800 000 F CFA pour les 4 sessions hors frais de déplacement. Beaucoup moins que le coût d’une seule licence EDR commerciale annuelle.

[ITS] ITSkillsCenter — formations IT et conseil pour PME d’Afrique de l’Ouest. Dakar · Abidjan · Ouagadougou · Bamako · Conakry. Tous nos contenus sont audités selon notre charte éditoriale Ahl-Sunna.