Falco : détection runtime Kubernetes

À la fin de ce tutoriel, vous installerez Falco sur un cluster lab, comprendrez la détection runtime (syscalls / eBPF), déclencherez une alerte (shell dans un conteneur, écriture sous /etc), lirez les events, ajouterez une règle légère, et sketcherez l’envoi vers un webhook / SIEM — sans inventer de métriques bidons.

Niveau : Intermédiaire · Temps estimé : 55–75 min · Versions cibles : Kubernetes 1.29+ · Falco 0.39+ (driver eBPF moderne) · Helm 3 · kind / k3s / EKS · Dernière vérification : 2026-09-11 · Region cloud (si EKS) : ca-central-1

Slug : wow-falco-runtime · Série : WOW (34/50) · Mot-clé SEO : falco kubernetes · Publish : READY

← Précédent : Cosign / Sigstore · → Suivant : Pipeline DevSecOps · Aussi : Pod Security Admission · Network Policies · RBAC · Argo CD · Homelab k3s

Prérequis

• Cluster lab : kind, k3s (homelab) ou EKS jetable en ca-central-1
• kubectl configuré ; Helm 3 recommandé
• Bases K8s sécurité : RBAC · Pod Security Admission · Network Policies
• Droits pour installer un DaemonSet privilégié (driver eBPF / kernel module selon distro)
• Coût estimé : ~0 € en kind/k3s. Sur EKS : contrôleur ~0,10 USD/h + nœuds — destroy le jour même en ca-central-1

kubectl version --client
kubectl get nodes -o wide
helm version --short
# Si AWS EKS lab :
# export AWS_PROFILE=lab AWS_DEFAULT_REGION=ca-central-1
# aws sts get-caller-identity

Ce que nous allons construire

Lab Falco runtime (WOW 34/50) — kind/k3s ou EKS ca-central-1
  ├── Pourquoi la détection runtime (vs scan + audit)
  ├── Falco : eBPF / syscalls + moteur de règles
  ├── Install Helm (chart officiel) + DaemonSet
  ├── Règles de base + déclencheurs (shell, write /etc)
  ├── Lecture logs / events Falco
  ├── Custom rule légère (YAML)
  ├── Sketch falcosidekick → webhook / SIEM
  └── Nettoyage + quiz + FAQ + maillage WOW 33/35

(Schéma — alt : « Falco DaemonSet observe les syscalls des pods et émet des alertes runtime vers stdout ou falcosidekick ».)

Étape 1 — Pourquoi la détection runtime en 2026 ?

Les scans (Trivy, WOW 31) et la signature (Cosign, WOW 33) couvrent le avant. NetworkPolicies et Pod Security Admission limitent ce qu’un pod peut faire. Il reste le trou classique : un conteneur légitime qui dérive après le start — reverse shell, dump de secrets, write sous /etc, miner.

La détection runtime observe syscalls / exécutions / fichiers / réseau et alerte hors profil. Ce n’est pas un substitut au RBAC ou à l’admission : c’est la dernière ligne quand le mauvais code tourne déjà.

Couche	Exemple DEH	Quand ça agit
Supply chain	Trivy, SBOM, Cosign	Build / push / pull
Admission	PSA, Gatekeeper/OPA	Avant le pod Running
Réseau	NetworkPolicy	Connexions L3/L4
Runtime	Falco	Pendant l’exécution

Étape 2 — Falco vs audit logs vs eBPF (vue claire)

Falco (CNCF) voit les syscalls des processus conteneur (execve, open, connect…). Les règles YAML matchent conditions + priorité (Notice → Emergency).

Approche	Force	Limite
Audit logs K8s	API server (who/what sur le control plane)	Peu de visibilité inside le conteneur
eBPF générique	Très riche, custom	Pas un moteur règles sécu prêt à l’emploi
Falco	Règles runtime + communauté	CPU/IO ; faux positifs à tuner

En 2026, préférez le driver eBPF moderne sur kernels récents ; le module legacy reste un fallback. Documentez ce que votre nœud utilise (falco --version / logs DaemonSet).

Pitch DEH : « Falco ne remplace pas Trivy ni Cosign : il détecte l’anormal après le déploiement. »

Étape 3 — Installer Falco (Helm)

Chart officiel Falco ; vérifiez helm search repo / notes 2026 — ne pinnez pas une version inventée.

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
kubectl create namespace falco --dry-run=client -o yaml | kubectl apply -f -

helm upgrade --install falco falcosecurity/falco 
  --namespace falco 
  --set tty=true 
  --set falco.http_output.enabled=false 
  --set falco.json_output=true 
  --wait --timeout 10m

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

Attendu : DaemonSet Ready (1 pod / nœud). Sur kind, driver/privileged peut coincer — kubectl describe avant d’empiler des --set. k3s homelab : souvent plus simple. EKS ca-central-1 : AMI/kernel eBPF OK, tags Owner=lab, destroy planifié.

Étape 4 — Règles de base et déclencher une alerte

Le ruleset par défaut couvre shell en conteneur, writes sensibles, package managers… Déclenchez pour voir l’event.

kubectl run falco-lab --image=busybox:1.36 --restart=Never -- sleep 3600
kubectl wait --for=condition=Ready pod/falco-lab --timeout=60s
kubectl exec -it falco-lab -- sh -c 'cat /etc/passwd; ls /'
kubectl exec falco-lab -- sh -c 'touch /etc/falco-lab-probe 2>/dev/null || echo write-blocked'
kubectl -n falco logs -l app.kubernetes.io/name=falco -f --tail=20

JSON attendu (rule, priority, output, metadata k8s). Pas de métriques inventées : validez que votre règle a matché dans votre lab.

Déclencheur	Intention	Suite typique
kubectl exec … sh	Shell interactif	Règle « shell in container »
Write /etc	Drift config	Write sensitive (si FS + règle)
Package manager	Drift image	Règles communauté

Étape 5 — Custom rule légère

Règle étroite (pod lab) pour apprendre le format — jamais un catch-all prod.

# Extrait conceptuel — values Helm / ConfigMap chart (doc officielle)
- rule: DEH Lab Touch Marker File
  desc: Lab marker under /tmp in falco-lab
  condition: >
    spawned_process and container and
    container.name = "falco-lab" and
    proc.name in (touch, sh) and
    fd.name startswith /tmp/deh-falco
  output: "DEH lab marker (cmd=%proc.cmdline container=%container.name)"
  priority: WARNING
  tags: [deh, lab, filesystem]

kubectl exec falco-lab -- touch /tmp/deh-falco-marker
kubectl -n falco logs -l app.kubernetes.io/name=falco --tail=30 | grep -i deh || true

Tags, priorité juste, condition étroite, test ns lab, revue Git (Argo CD). Trop large = fatigue d’alerte.

Étape 6 — Intégration SIEM / webhook (sketch)

Lab : stdout JSON. Équipe : falcosidekick vers Slack / ES / Loki.

# Sketch — subchart / chart dédié (docs 2026)
# helm upgrade falco falcosecurity/falco -n falco --reuse-values 
#   --set falcosidekick.enabled=true 
#   --set falcosidekick.config.webhook.address="https://hooks.example.lab/falco"

Puis dédup, rate-limit, runbook WARNING vs CRITICAL. L’alerte ≠ incident response (WOW 27). Suite pipeline : WOW 35.

Étape 7 — Erreurs fréquentes

Symptôme	Cause probable	Correction
Pod Falco CrashLoop	Driver / kernel incompatible	Logs init ; basculer eBPF moderne ; vérifier kernel kind/EKS
Aucune alerte sur exec	Ruleset désactivé / filtre	Vérifier falco.yaml rules files ; json_output ; namespace
Trop d’alertes	Règles trop larges	Custom rules étroites ; exceptions documentées
Permission denied DaemonSet	PSA / restricted ns	Installez Falco dans ns dédié avec droits adaptés
EKS coûteux oublié	Cluster laissé allumé	Destroy le jour même en ca-central-1

Défense en profondeur : PSA, Network Policies, RBAC — Falco détecte, les policies préviennent.

Nettoyage

kubectl delete pod falco-lab --ignore-not-found
helm uninstall falco -n falco || true
kubectl delete ns falco --ignore-not-found
# eksctl delete cluster --name wow-falco-lab --region ca-central-1

Si EKS : vérifiez LB / NAT oubliés en ca-central-1.

Coûts

Poste	Ordre de grandeur
kind / k3s local	~0 € (CPU lab)
Falco DaemonSet	Coût compute nœuds (overhead CPU/mémoire modéré — mesurez chez vous)
EKS contrôleur ca-central-1	~0,10 USD/h — éviter hors lab court
falcosidekick + SIEM SaaS	Selon stack (hors scope chiffres inventés)

Quiz (5 questions)

1. Falco sert surtout à :
– A. Remplacer Trivy au build
– B. Détecter des comportements anormaux runtime via syscalls / eBPF
– C. Signer les images

2. Par rapport aux audit logs K8s, Falco voit surtout :
– A. Uniquement les appels API server
– B. L’activité processus / fichiers / réseau côté nœud & conteneurs
– C. Les tickets Jira

3. Region lab DEH si vous utilisez EKS :
– A. us-east-1 par défaut
– B. ca-central-1
– C. eu-central-1 obligatoire

4. Une bonne custom rule lab est :
– A. condition: true sur tout le cluster
– B. Étroite (ns/pod/chemin) + testée + versionnée
– C. Copiée sans tags ni priorité

5. Après Cosign (WOW 33), Falco apporte :
– A. La signature d’images
– B. La détection pendant l’exécution malgré une image signée
– C. Le remplacement des NetworkPolicies

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

FAQ

Falco remplace-t-il Pod Security Admission ?

Non. PSA/Gatekeeper bloquent au start ; Falco alerte au runtime. Complémentaires — PSA.

kind ou k3s ?

kind = CI jetable ; k3s = homelab (guide). EKS seulement pour le chemin managé — destroy same day ca-central-1.

falcosidekick jour 1 ?

Non. Validez d’abord les logs JSON, puis routez avec destinataire + runbook.

eBPF ou module kernel ?

eBPF moderne sur kernels récents ; module legacy en fallback documenté.

Priorité shell en prod ?

WARNING ou CRITICAL selon contexte ; exceptions nominatives, pas « disable all ».

Lien DevSecOps ?

Scan → sign → GitOps → Falco → incident. Suite : WOW 35, Trivy, SBOM.

Pour aller plus loin

• Cosign / Sigstore · Pipeline DevSecOps
• Trivy · SBOM · Incident runbooks
• PSA · Network Policies · RBAC
• Argo CD · Homelab k3s

Maillage série WOW

← Précédent	Cosign / Sigstore : signer ses images (WOW 33)
→ Suivant	Pipeline DevSecOps de A à Z (WOW 35)
Aussi	Trivy · Homelab k3s · Argo CD · PSA

---

Meta publication (SEO) — Publish READY

• Title SEO : Falco : détection runtime Kubernetes (guide FR)
• Meta description (≤ 160) : Falco sur Kubernetes : eBPF, règles, alerte shell/write /etc, falcosidekick, lab kind/k3s ou EKS ca-central-1. Guide FR WOW 34/50.
• Focus keyword : falco kubernetes
• Secondary : Falco runtime, détection runtime Kubernetes, falcosidekick, eBPF Falco
• Image : assets/web/devopelastichayway/cover-wow-falco-runtime-1200x630.webp
• Cover alt : Falco DaemonSet et alertes runtime sur cluster Kubernetes lab
• Catégorie : WOW / Kubernetes / Sécurité · Schema : HowTo + FAQPage + Article
• URL : https://devopelastichayway.com/tutoriels/wow-falco-runtime/
• Statut : Publish READY — WP-CLI parent 5463 · Region : ca-central-1