Falco - Détection des menaces runtime dans Kubernetes

Falco est l’outil de référence pour détecter les comportements anormaux dans vos conteneurs Kubernetes en temps réel. Projet CNCF Graduated depuis février 2024, il surveille les appels système (syscalls) et les événements d’audit Kubernetes pour identifier les menaces : shell spawné dans un conteneur, lecture de fichiers sensibles, connexions réseau suspectes. Ce guide vous montre comment déployer Falco, comprendre ses règles de détection, et créer vos propres alertes personnalisées.

Contexte CKS

Falco est explicitement mentionné dans le blueprint CKS (domaine “Monitoring, Logging and Runtime Security”). Maîtriser son déploiement et la personnalisation des règles est essentiel pour l’examen.

Prérequis

• Cluster Kubernetes Linux fonctionnel
• Nœuds compatibles avec le mode de capture choisi (Modern eBPF, kernel module…)
• Helm v3 installé
• kubectl configuré avec accès cluster-admin
• Bases en sécurité Linux (syscalls, capabilities)

Qu’est-ce que Falco ?

Falco détecte les comportements suspects au niveau du runtime en analysant deux sources d’événements :

Source	Description	Exemples de détection
Syscalls kernel	Appels système des conteneurs via eBPF ou module kernel	Shell spawné, fichier sensible lu, binaire modifié
Audit Events K8s	Événements de l’API Server Kubernetes	Pod créé en mode privileged, exec dans un pod, secrets accédés

Glissez pour voir

Architecture simplifiée

┌─────────────────────────────────────────────────────────────────┐
│                        Nœud Kubernetes                          │
│  ┌─────────────┐    ┌─────────────────────────────────────────┐│
│  │ Conteneur A │    │               Falco                     ││
│  │ └─syscalls──┼────►  ┌─────────┐   ┌────────┐   ┌────────┐ ││
│  └─────────────┘    │  │ Event   │──►│ Engine │──►│ Outputs│ ││
│  ┌─────────────┐    │  │ Source  │   │ Rules  │   │ Alerts │ ││
│  │ Conteneur B │    │  └─────────┘   └────────┘   └────────┘ ││
│  │ └─syscalls──┼────►                                         ││
│  └─────────────┘    └─────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────┘

Falco fonctionne comme un DaemonSet : un pod par nœud qui capture les événements de tous les conteneurs.

Sources d’événements :

• Kernel : syscalls capturés via Modern eBPF, eBPF legacy ou module kernel
• Plugins : événements Kubernetes Audit, CloudTrail, etc.

Ce que Falco ne fait pas

Falco détecte des comportements suspects au runtime. Il ne remplace pas :

• Un scanner de vulnérabilités d’images (utilisez Trivy)
• Un audit de configuration cluster (utilisez kube-bench)
• Une politique d’admission Kubernetes (utilisez Pod Security Standards)
• Un système de blocage automatique (Falco alerte, il ne bloque pas par défaut)

Installation avec Helm

Déploiement standard

1. Ajouter le dépôt Helm Falco

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

2. Installer Falco avec détection automatique du driver

   helm install falco falcosecurity/falco \
     --namespace falco \
     --create-namespace \
     --set driver.kind=auto \
     --set tty=true \
     --set falco.json_output=true \
     --set falco.json_include_output_property=true

   Paramètre tty=true obligatoire

   Le paramètre tty=true est indispensable pour voir les alertes dans kubectl logs. Sans lui, Falco fonctionne mais n’affiche rien sur stdout.

   Choix du driver

   Le chart Falco recommande driver.kind=auto, qui privilégie le Modern eBPF probe quand le noyau le permet (5.8+), puis bascule automatiquement vers d’autres mécanismes compatibles (eBPF legacy, module kernel).

3. Vérifier le déploiement

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

   Résultat attendu :

   NAME          READY   STATUS    RESTARTS   AGE
   falco-xxxxx   2/2     Running   0          2m

Options d’installation avancées

Option	Valeur	Description
tty	true	Obligatoire — active la sortie des alertes sur stdout
driver.kind	auto	Recommandé — sélection automatique du meilleur driver
driver.kind	modern_ebpf	Modern eBPF probe (noyau 5.8+, intégré au binaire)
driver.kind	ebpf	eBPF legacy (historique, cas spécifiques)
driver.kind	kmod	Module kernel (compatibilité, nécessite headers)
falco.json_output	true	Sortie JSON structurée (recommandé pour parsing)
falco.grpc.enabled	true/false	Active l’API gRPC pour intégrations externes
falcosidekick.enabled	true	Déploie Falcosidekick pour router les alertes
falco.rules_file	Liste de fichiers	Fichiers de règles à charger

Glissez pour voir

Modern eBPF vs Legacy

Le Modern eBPF probe est la cible privilégiée : il est intégré au binaire Falco et évite la complexité des drivers externes. Si votre noyau le supporte (5.8+), c’est le choix optimal.

Comprendre les règles Falco

Les règles Falco sont écrites en YAML avec trois composants principaux :

Structure d’une règle

# 1. Listes : ensembles de valeurs réutilisables
- list: sensitive_files
  items: [/etc/shadow, /etc/passwd, /etc/sudoers]

# 2. Macros : conditions réutilisables
- macro: container
  condition: container.id != host

- macro: open_read
  condition: evt.type in (open, openat) and evt.is_open_read=true

# 3. Règles : logique de détection complète
- rule: Read sensitive file in container
  desc: Detect reading of sensitive files inside containers
  condition: open_read and container and fd.name in (sensitive_files)
  output: >
    Sensitive file read in container
    (file=%fd.name user=%user.name container=%container.name
    image=%container.image.repository)
  priority: WARNING
  tags: [filesystem, cks]

Priorités d’alertes

Priorité	Usage	Exemple
EMERGENCY	Système inutilisable	-
ALERT	Action immédiate requise	Malware détecté
CRITICAL	Conditions critiques	Conteneur privileged créé
ERROR	Erreurs importantes	Échec d’authentification répété
WARNING	Comportement suspect	Lecture /etc/shadow
NOTICE	Événement normal mais notable	Shell spawné (peut être légitime)
INFO	Information	Nouveau conteneur démarré
DEBUG	Debug	-

Glissez pour voir

Champs disponibles couramment utilisés

Pour écrire des conditions de détection efficaces, vous devez connaître les champs Falco disponibles. Ces champs permettent d’accéder aux informations sur les processus, conteneurs, fichiers, réseau et utilisateurs lors de l’évaluation d’un événement :

# Processus
proc.name        # Nom du processus (bash, python)
proc.pname       # Nom du processus parent
proc.cmdline     # Ligne de commande complète

# Conteneur
container.id     # ID du conteneur
container.name   # Nom du conteneur
container.image.repository  # Image sans tag

# Fichiers
fd.name          # Chemin du fichier
fd.directory     # Répertoire parent

# Réseau
fd.sip           # IP source
fd.sport         # Port source
fd.dip           # IP destination
fd.dport         # Port destination

# Utilisateur
user.name        # Nom utilisateur
user.uid         # UID

Règles incluses par défaut

Falco inclut plus de 100 règles de détection. Les plus importantes pour la CKS :

Détection terminal/shell

# Observer les alertes en temps réel
kubectl logs -n falco -l app.kubernetes.io/name=falco -f | grep -i shell

Tester la détection :

# Dans un autre terminal, spawner un shell
kubectl run test-shell --image=nginx --rm -it -- /bin/bash

Alerte générée :

{
  "output": "Notice A shell was spawned in a container (user=root container=test-shell shell=bash)",
  "priority": "Notice",
  "rule": "Terminal shell in container"
}

Lecture de fichiers sensibles

Règle incluse par défaut :

- rule: Read sensitive file untrusted
  desc: Detect reads of sensitive files by non-trusted programs
  condition: >
    sensitive_files and open_read
    and proc_name_exists
    and not proc.name in (known_sensitive_file_readers)
  output: >
    Sensitive file opened (file=%fd.name proc=%proc.name
    container=%container.name)
  priority: WARNING

Écriture dans répertoires système

- rule: Write below etc
  desc: Detect writes beneath /etc directory
  condition: >
    write and container
    and fd.name startswith /etc
  output: >
    File below /etc written (file=%fd.name container=%container.name)
  priority: ERROR

Créer des règles personnalisées

Méthode via ConfigMap

1. Créer un fichier de règles personnalisées

   custom-rules.yaml

   customRules:
     custom-rules.yaml: |-
       - list: allowed_images
         items: [myregistry.io/app, myregistry.io/api]
   
       - rule: Container from unauthorized image
         desc: Detect containers from non-approved images
         condition: >
           container and evt.type=container
           and not container.image.repository in (allowed_images)
         output: >
           Unauthorized image used
           (image=%container.image.repository container=%container.name
           namespace=%k8s.ns.name)
         priority: WARNING
         tags: [container, compliance]
   
       - rule: Crypto mining detection
         desc: Detect potential crypto mining activity
         condition: >
           container and spawned_process
           and (proc.name in (xmrig, minerd, minergate, cpuminer)
                or proc.cmdline contains "stratum+tcp://")
         output: >
           Crypto mining suspected
           (proc=%proc.name cmdline=%proc.cmdline container=%container.name)
         priority: CRITICAL
         tags: [cryptomining, malware]

2. Déployer avec Helm

   helm upgrade falco falcosecurity/falco \
     --namespace falco \
     --reuse-values \
     -f custom-rules.yaml

3. Vérifier le chargement

   kubectl logs -n falco -l app.kubernetes.io/name=falco | grep -i "custom-rules"

Désactiver une règle par défaut

Pour désactiver une règle bruyante sans modifier les fichiers originaux :

customRules:
  custom-rules.yaml: |-
    - rule: Terminal shell in container
      enabled: false

Ou remplacer la condition pour un namespace spécifique :

customRules:
  custom-rules.yaml: |-
    - rule: Terminal shell in container
      condition: >
        spawned_process and container
        and shell_procs and proc.tty != 0
        and not k8s.ns.name in (debug-namespace, dev)

Sortie des alertes (Outputs)

Configuration des canaux de sortie

Falco peut envoyer les alertes vers plusieurs destinations :

# values.yaml pour Helm
falco:
  json_output: true

  stdout_output:
    enabled: true

  file_output:
    enabled: true
    filename: /var/log/falco/alerts.log

  http_output:
    enabled: true
    url: http://alertmanager:9093/api/v1/alerts

Falcosidekick pour intégrations avancées

Recommandation

En production, utilisez Falcosidekick comme routeur d’alertes. Il supporte 50+ destinations : Slack, PagerDuty, Elasticsearch, Prometheus, etc.

helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --reuse-values \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/xxx"

Vérifier Falcosidekick :

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

Intégration avec Kubernetes Audit Logs

Falco peut consommer les événements d’audit Kubernetes via des plugins dédiés. Cette intégration est distincte de la capture des syscalls kernel et dépend de votre plateforme.

Architecture à deux sources

Le DaemonSet Falco capture les syscalls kernel (comportements dans les conteneurs). Les événements d’audit Kubernetes (actions sur l’API) nécessitent une configuration séparée via plugin. Ne confondez pas les deux sources.

Concepts clés

Source	Capture	Exemples
Kernel (syscalls)	DaemonSet Falco sur chaque nœud	Shell spawné, fichier lu, connexion réseau
K8s Audit (plugin)	Webhook depuis l’API Server	Pod créé, secret accédé, RBAC modifié

Glissez pour voir

Activer le plugin K8s Audit

Pour les clusters autogérés, configurez l’API Server pour envoyer les événements d’audit vers Falco :

# values.yaml pour Helm
falco:
  plugins:
    - name: k8saudit
      library_path: libk8saudit.so
      init_config: ""
      open_params: "http://:9765/k8s-audit"
  load_plugins: [k8saudit]

Clusters managés (EKS, GKE, AKS)

Sur les clusters managés, les logs d’audit sont souvent accessibles via CloudWatch, Stackdriver ou Azure Monitor. Falco peut les consommer via des plugins spécifiques (ex: k8saudit-eks). Consultez la documentation Falco pour votre plateforme.

Règles K8s Audit incluses

# Exemples de règles d'audit Kubernetes
- rule: K8s Secret Get Attempted
  desc: Detect attempts to get secrets
  condition: >
    ka.verb in (get, list) and ka.target.resource=secrets
  output: >
    Secret access attempted
    (user=%ka.user.name secret=%ka.target.name ns=%ka.target.namespace)
  priority: WARNING
  source: k8s_audit

- rule: Create Privileged Pod
  desc: Detect creation of privileged pods
  condition: >
    ka.verb=create and ka.target.resource=pods
    and ka.req.pod.containers.privileged=true
  output: >
    Privileged pod created (user=%ka.user.name pod=%ka.target.name)
  priority: CRITICAL
  source: k8s_audit

Vérification et tests

Déclencher des alertes de test

# Test 1 : Shell dans un conteneur
kubectl run test-falco --image=alpine --rm -it -- /bin/sh -c "cat /etc/shadow"

# Test 2 : Écriture dans /etc
kubectl run test-write --image=alpine --rm -it -- /bin/sh -c "touch /etc/test"

# Test 3 : Lecture sensitive file
kubectl run test-read --image=alpine --rm -it -- /bin/sh -c "cat /etc/passwd"

Surveiller les alertes

# JSON formaté
kubectl logs -n falco -l app.kubernetes.io/name=falco -f | jq .

# Filtrer par priorité
kubectl logs -n falco -l app.kubernetes.io/name=falco | grep -i "warning\|error\|critical"

Dépannage

Falco ne démarre pas

# Vérifier les événements
kubectl describe pod -n falco -l app.kubernetes.io/name=falco

# Problèmes de driver courants
kubectl logs -n falco -l app.kubernetes.io/name=falco -c falco-driver-loader

Solutions courantes :

Symptôme	Cause probable	Solution
Driver eBPF échoue	Kernel < 5.8	Utiliser driver.kind=module
Module kernel échoue	Headers kernel manquants	Installer linux-headers-$(uname -r)
Pas d’alertes	Règles désactivées	Vérifier falco.rules_file

Glissez pour voir

Règles personnalisées non chargées

# Vérifier la syntaxe YAML
kubectl get configmap -n falco falco-rules -o yaml

# Logs de chargement des règles
kubectl logs -n falco -l app.kubernetes.io/name=falco | grep -i "rule\|error\|warn"

Bonnes pratiques

Filtrage par namespace

Exclure les namespaces de monitoring/debug pour réduire le bruit.

Priorités appropriées

Réserver CRITICAL/ALERT pour les vraies urgences nécessitant une action.

Tags cohérents

Utiliser des tags pour filtrer (mitre, compliance, cks, filesystem).

Tests réguliers

Valider que les règles détectent bien les comportements attendus.

Gestion du bruit et faux positifs

Falco génère beaucoup d’alertes par défaut. En production, le tuning est essentiel.

Sources de bruit courantes

Source	Exemple	Solution
Namespaces de debug	kubectl exec dans kube-system	Exclure le namespace
Opérateurs Kubernetes	Controllers qui lisent des secrets	Whitelist par image
Jobs d’administration	Backups, maintenance	Exclure par label
Conteneurs toolbox	Images de debug avec shells	Exclure par image

Glissez pour voir

Exemple de règle avec exclusions

customRules:
  tuning.yaml: |-
    - rule: Terminal shell in container
      condition: >
        spawned_process and container
        and shell_procs and proc.tty != 0
        and not k8s.ns.name in (kube-system, monitoring, debug)
        and not container.image.repository in (busybox, alpine/debug)

Stratégie de tuning recommandée

1. Déployer en mode observation : Commencer sans alerting externe
2. Collecter les faux positifs : Analyser les logs pendant 1-2 semaines
3. Créer des exceptions : Whitelists par namespace, image, ou processus
4. Activer les alertes : Connecter Falcosidekick après stabilisation
5. Itérer : Ajuster au fil des déploiements

Falcoctl : gestion des artefacts

falcoctl est l’outil CLI pour gérer les règles et plugins Falco.

# Installer falcoctl
curl -L https://github.com/falcosecurity/falcoctl/releases/latest/download/falcoctl_linux_amd64.tar.gz | tar xz
sudo mv falcoctl /usr/local/bin/

# Lister les règles disponibles
falcoctl artifact list

# Installer des règles depuis le registry
falcoctl artifact install falco-rules

Écosystème moderne

L’écosystème Falco 2026 s’appuie sur falcoctl pour la gestion des artefacts (règles, plugins). Les ConfigMaps restent valides pour les règles personnalisées, mais falcoctl simplifie les mises à jour.

À retenir

Concept	Description
Falco	Outil CNCF Graduated de détection runtime (syscalls + plugins)
Driver	auto recommandé → Modern eBPF si noyau 5.8+, sinon fallback
Règles	YAML avec listes, macros, et conditions de détection
Priorités	EMERGENCY → DEBUG selon la criticité
Falcosidekick	Routeur d’alertes vers 50+ destinations
K8s Audit	Plugin séparé pour les événements de l’API Server
falcoctl	CLI pour gérer les artefacts (règles, plugins)

Glissez pour voir

Prochaines étapes

Audit Logs Kubernetes

Configurer les logs d’audit de l’API Server pour traçabilité complète. Configurer les Audit Logs

Network Policies

Compléter la sécurité runtime avec l’isolation réseau. Network Policies

CIS Benchmark

Auditer la configuration du cluster avec kube-bench. CIS Benchmark

Quiz

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

8 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →