RBAC décide qui peut créer quoi, NetworkPolicy décide qui peut parler à qui, Pod Security Standards restreint ce qu’un pod peut faire dès sa création. Ces trois mécanismes partagent un point commun : ils agissent avant ou au moment où un pod démarre, jamais après. Une fois le pod en cours d’exécution, respectant toutes ces règles en apparence, rien ne surveille plus ce qui se passe réellement à l’intérieur.

L’angle mort que les contrôles statiques ne couvrent pas

Un conteneur qui respecte runAsNonRoot, dont l’image est signée, dont les permissions RBAC sont minimales, peut malgré tout être compromis via une vulnérabilité applicative exploitée à l’exécution : une injection de commande qui ouvre un shell, une bibliothèque compromise qui lit des fichiers sensibles, un processus qui tente une élévation de privilège locale. Aucun des contrôles statiques déjà couverts ne détecte ce comportement, puisqu’ils valident une configuration au moment de la création, pas un comportement en cours d’exécution.

Falco : observer les appels système en direct

Falco s’appuie sur eBPF (le même mécanisme qui permet à Cilium de remplacer kube-proxy) pour observer les appels système exécutés par chaque processus, en temps réel, et les comparer à des règles qui décrivent un comportement anormal. Un shell lancé à l’intérieur d’un conteneur qui n’en attend jamais, une lecture de /etc/shadow, une tentative d’écriture dans un binaire système : chaque règle Falco décrit un motif précis à surveiller.

# Règle Falco : détecte un shell lancé dans un conteneur,
# un motif qui n'a normalement aucune raison d'exister
- rule: Terminal shell in container
  desc: A shell was spawned inside a container
  condition: spawned_process and container and shell_procs
  output: "Shell spawned in container (user=%user.name container=%container.name)"
  priority: WARNING

Ce que ça change par rapport à un scan d’image

Un scan d’image (voir l’article sur le scan et la signature d’images) détecte des vulnérabilités connues dans les composants d’une image, avant son déploiement. Falco détecte un comportement anormal en cours d’exécution, indépendamment de la présence d’une CVE connue : une image parfaitement scannée et sans vulnérabilité répertoriée peut toujours être exploitée par une chaîne d’attaque nouvelle, que seul un comportement observé à l’exécution révèle.

Le vrai défi : le réglage, pas le déploiement

Installer Falco est la partie simple ; le vrai travail consiste à ajuster les règles pour un environnement spécifique, faute de quoi le volume d’alertes devient ingérable. Une règle générique comme « shell lancé dans un conteneur » déclenche une alerte légitime pour un conteneur de débogage manuel (voir l’article sur le debug via conteneurs éphémères), qui n’a rien d’une intrusion. Sans exceptions explicites pour ces cas connus, l’équipe qui reçoit les alertes apprend vite à les ignorer, ce qui annule tout le bénéfice de l’outil.

# Exception explicite pour un cas légitime connu,
# sans quoi chaque debug manuel déclenche une fausse alerte
- macro: allowed_debug_shell
  condition: container.name = "debug-session"

À retenir

RBAC, NetworkPolicy et Pod Security Standards agissent tous avant ou au moment où un pod démarre, laissant un angle mort total sur ce qui se passe une fois qu’il tourne. Falco comble cet angle mort en observant les appels système en temps réel via eBPF, détectant un comportement anormal indépendamment de toute CVE connue, une capacité qu’aucun scan d’image ne peut offrir. Le vrai travail n’est pas le déploiement mais le réglage des règles pour éliminer les faux positifs prévisibles (debug manuel, outils légitimes), sans quoi l’alerte fatigue rend l’outil inutile, un des piliers d’une fiabilité et observabilité qui couvre la sécurité en profondeur, pas seulement à l’admission.