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.

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

Architecture simplifiée

Le schéma suit le trajet d'un événement à l'intérieur d'un nœud : la source capture le syscall, le moteur de règles l'évalue, puis les outputs émettent une alerte si une condition correspond. Aucun composant central n'est nécessaire, tout se joue sur le nœud lui-même.

┌─────────────────────────────────────────────────────────────────┐
│                        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.

Installation avec Helm

Le chart officiel falcosecurity/falco installe le DaemonSet, les règles par défaut et, en option, le routeur d'alertes. Deux paramètres décident du résultat obtenu : driver.kind, qui choisit le mécanisme de capture des syscalls, et tty, sans lequel aucune alerte n'apparaît dans les logs. Se tromper sur ces deux points donne un Falco qui tourne sans rien remonter, c'est le piège le plus courant.

Déploiement standard

Ces trois étapes suffisent à obtenir un Falco fonctionnel qui écrit ses alertes au format JSON sur la sortie standard.

Ajouter le dépôt Helm Falco

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

Installer Falco avec détection automatique du driver
Fenêtre de terminal
```
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
```
Le paramètre tty=true est indispensable pour voir les alertes dans kubectl logs. Sans lui, Falco fonctionne mais n'affiche rien sur stdout.

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).

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

Ces valeurs se passent en --set sur la ligne de commande ou dans un fichier values.yaml. Les deux premières lignes sont les seules réellement indispensables à un déploiement exploitable ; les suivantes dépendent du contexte, en particulier le choix explicite du driver quand auto échoue.

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

Comprendre les règles Falco

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

Structure d'une règle

Une règle Falco s'appuie sur trois briques déclarées dans le même fichier. Les listes regroupent des valeurs, les macros nomment des conditions réutilisables, et la règle combine le tout avec un message de sortie et une priorité. L'exemple ci-dessous présente les trois dans l'ordre où le moteur les résout : une règle ne peut référencer qu'une macro ou une liste déjà définie.

# 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

Le champ priority ne change rien à la détection elle-même : il sert au filtrage en aval, typiquement pour décider ce qui déclenche une astreinte. Les niveaux EMERGENCY et DEBUG restent marginaux dans les règles livrées.

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	-

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

La règle Terminal shell in container, fournie par défaut, se déclenche dès qu'un processus shell obtient un terminal à l'intérieur d'un conteneur.

# 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

La macro write couvre les syscalls d'écriture ; associée à fd.name startswith /etc, elle repère les modifications de configuration système dans un conteneur, qui n'ont aucune raison d'exister sur une image immuable.

- 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

Les règles fournies couvrent des comportements génériques, pas votre contexte : registres autorisés, noms de processus internes, namespaces de recette. Vos propres règles vivent donc dans un fichier séparé, chargé en plus des règles par défaut. Cette séparation évite de modifier des fichiers que la prochaine mise à jour du chart écraserait.

Méthode via ConfigMap

La clé customRules du chart crée une ConfigMap montée dans le pod Falco : chaque entrée y devient un fichier de règles chargé au démarrage.

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

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]

Déployer avec Helm

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

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)

Détecter ne sert à rien si personne ne voit l'alerte. Falco sait alimenter plusieurs canaux simultanément : la sortie standard, un fichier sur le nœud et un appel HTTP. Activez json_output dès que les alertes sont consommées par un autre outil, car le format texte par défaut n'est pas structuré et se parse mal.

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

Falcosidekick se déploie avec le même chart et prend en charge la diffusion vers les outils d'alerting, ce qui évite d'écrire et d'exploiter un récepteur HTTP maison.

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.

Concepts clés

Ces deux sources ne se recouvrent pas : la première observe ce qui se passe dans les conteneurs, la seconde ce qui est demandé à l'API Server. Une commande comme kubectl exec apparaît dans les deux, sous deux angles différents.

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é

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]

Règles K8s Audit incluses

Ces règles portent source: k8s_audit et utilisent les champs préfixés ka., propres au plugin d'audit : elles ne se déclenchent jamais tant que le plugin n'est pas chargé.

# 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

Après l'installation, vérifiez la chaîne complète, de la capture jusqu'à l'affichage de l'alerte. Le plus rapide consiste à provoquer volontairement un comportement couvert par les règles par défaut, puis à observer la sortie du DaemonSet.

Déclencher des alertes de test

Ces trois commandes déclenchent chacune une règle livrée avec Falco ; l'option --rm supprime le pod de test dès que la commande se termine.

# 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

Sans tty=true au moment de l'installation, ces commandes ne renvoient rien, même quand Falco détecte correctement les événements.

# 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

Deux pannes reviennent en boucle : le pod ne démarre pas faute de driver compatible avec le noyau, ou il démarre sans charger vos règles. Les deux se diagnostiquent dans les logs, mais pas dans le même conteneur du pod.

Falco ne démarre pas

Le chargement du driver s'effectue dans un conteneur dédié, falco-driver-loader : c'est là qu'il faut lire les logs, pas dans le conteneur falco lui-même.

# 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`

Règles personnalisées non chargées

Vérifiez d'abord que la ConfigMap contient bien le contenu attendu, puis cherchez dans les logs de démarrage la ligne de chargement du fichier : les erreurs de syntaxe y sont signalé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

Ces quatre réflexes pèsent davantage sur la qualité de la détection que le nombre de règles activées. Une règle qui se déclenche cent fois par jour finit par être ignorée, ce qui revient exactement à ne pas l'avoir écrite.

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

Le bruit vient rarement d'une règle mal écrite : il vient d'activités légitimes que Falco ne peut pas distinguer d'une attaque. Identifiez la source récurrente avant d'écrire une exclusion, sinon vous neutralisez la détection bien au-delà du cas visé.

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

Exemple de règle avec exclusions

Redéfinir une règle sous le même nom remplace intégralement sa condition : on repart donc de la condition d'origine, à laquelle on ajoute les clauses not nécessaires.

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

L'ordre de ces étapes compte. Brancher l'alerting vers une équipe avant d'avoir filtré le bruit garantit que les alertes seront ignorées au bout de quelques jours, y compris les vraies.

Déployer en mode observation : Commencer sans alerting externe
Collecter les faux positifs : Analyser les logs pendant 1-2 semaines
Créer des exceptions : Whitelists par namespace, image, ou processus
Activer les alertes : Connecter Falcosidekick après stabilisation
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, version epinglee et archive verifiee
VERSION=0.11.0
curl -fsSLO "https://github.com/falcosecurity/falcoctl/releases/download/v$VERSION/falcoctl_${VERSION}_linux_amd64.tar.gz"
curl -fsSLO "https://github.com/falcosecurity/falcoctl/releases/download/v$VERSION/falcoctl_${VERSION}_checksums.txt"
grep " falcoctl_${VERSION}_linux_amd64.tar.gz$" "falcoctl_${VERSION}_checksums.txt" | sha256sum -c -
tar -xzf "falcoctl_${VERSION}_linux_amd64.tar.gz" falcoctl
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

À 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)

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

Dix questions pour vérifier votre compréhension de Falco avant l'examen CKS.

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