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.

Falco est explicitement cité dans le programme CKS, au domaine Monitoring, Logging and Runtime Security. Savoir le déployer et personnaliser ses règles fait donc partie des attendus de l'examen, ce qui n'est pas le cas de tous les outils de ce module.

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.

Architecture de Falco sur un nœud Kubernetes : les appels système des conteneurs sont capturés par la source eBPF, évalués par le moteur de règles, puis transformés en alertes par les sorties

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.

Une mise au point utile avant d'aller plus loin, parce que Falco est souvent présenté comme une solution de sécurité à lui seul. Falco détecte des comportements pendant l'exécution, et c'est tout. Il ne remplace ni un scanner de vulnérabilités d'images, rôle de Trivy, ni un audit de configuration du cluster, rôle de kube-bench, ni une politique d'admission, rôle des Pod Security Standards. Ces quatre outils couvrent quatre moments différents, et aucun ne rattrape ce qu'un autre a laissé passer.

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 : driver.kind, qui choisit le mécanisme de capture des appels système, et tty, sans lequel aucune alerte n'apparaît dans les journaux. 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 force la sortie de Falco en mode ligne par ligne au lieu du tampon par blocs qu'un processus sans terminal utilise par défaut. Sur un cluster peu bavard, cela évite d'attendre que le tampon se remplisse pour voir une alerte.

Ce n'est pas une condition pour voir les alertes. Vérifié sur Falco 0.44.1 : sans ce réglage, une alerte déclenchée apparaît dans kubectl logs en environ trois secondes, exactement comme avec. Si vous ne voyez rien, cherchez ailleurs, du côté de la sonde ou de la règle, pas de ce paramètre.

Le chart recommande driver.kind=auto, et c'est le bon réglage par défaut : il privilégie la sonde eBPF moderne quand le noyau la permet, à partir de la version 5.8, et bascule sinon vers les mécanismes plus anciens, eBPF historique ou module noyau.

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

Entre les trois mécanismes de capture, la sonde eBPF moderne est la cible à viser : elle est intégrée au binaire Falco, ce qui supprime toute la complexité des drivers externes à compiler et à maintenir au rythme des mises à jour du noyau. Si votre noyau est en 5.8 ou plus récent, il n'y a pas de raison de choisir autre chose.

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

Écrire une condition de détection suppose de connaître les champs que Falco expose. Ils donnent accès, au moment où l'événement est évalué, aux informations sur le processus, le conteneur, le fichier, le réseau et l'utilisateur.

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

Vérifier quelle sonde Falco a réellement choisie

C'est la première chose à lire après l'installation, et elle tient en une ligne des journaux :

kubectl -n falco logs ds/falco | grep -i probe

Opening 'syscall' source with modern BPF probe.
Loaded event sources: syscall

modern BPF probe est ce qu'il faut voir : la sonde est intégrée au binaire, sans module noyau à compiler ni à maintenir. Sur un noyau Linux 6.8, avec le BTF disponible, driver.kind=auto la retient sans configuration supplémentaire. L'installation du chart prend une cinquantaine de secondes et déploie un DaemonSet, donc un Pod par nœud.

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:1.28@sha256:146adea4768b83c607d0bdfa4188464e3da6e0a3ad4475db1d1d8f64f27c29cc --rm -it -- /bin/bash

Le -it n'est pas un confort d'affichage, il conditionne la détection. Vérifié en lab : un kubectl exec sans terminal exécute bien un shell dans le conteneur et ne déclenche pas cette règle, alors que la règle sur les fichiers sensibles, elle, se déclenche normalement au même moment. La règle s'appelle « Terminal shell », et elle prend ce mot au sérieux.

Conséquence à retenir pour la détection réelle : un attaquant qui exécute des commandes sans allouer de terminal passe sous cette règle. Elle couvre l'intrusion interactive, pas l'exécution de commandes.

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

La règle Read sensitive file untrusted surveille les lectures de fichiers comme /etc/shadow ou /etc/sudoers, regroupés dans la macro sensitive_files. Un conteneur applicatif n'a aucune raison de les ouvrir : une alerte ici signale soit une reconnaissance après compromission, soit un outil mal placé dans l'image.

Cette règle est aussi celle qui produit le plus de faux positifs, parce que certains agents légitimes lisent ces fichiers. Le réflexe est alors d'allonger la liste known_sensitive_file_readers, jamais de désactiver la règle : vous gardez la détection et vous documentez au passage ce qui est autorisé à lire quoi.

- 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 appels système 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'alerte, ce qui évite d'écrire et d'exploiter un récepteur HTTP maison.

En production, ne laissez pas les alertes dans kubectl logs : ajoutez Falcosidekick, un routeur qui les distribue vers plus de cinquante destinations, Slack, PagerDuty, Elasticsearch ou Prometheus selon votre chaîne d'alerte existante. Une détection que personne ne lit ne sert à rien.

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.

Ne confondez pas les deux sources d'événements, c'est la confusion la plus coûteuse sur ce sujet. Le DaemonSet Falco capture les appels système du noyau, donc ce qui se passe dans les conteneurs. Les journaux d'audit Kubernetes, eux, décrivent les actions sur l'API, et leur consommation demande une configuration séparée, par plugin. Chercher une action kubectl dans les alertes du DaemonSet ne donnera jamais rien.

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]

Sur un cluster managé, les journaux d'audit ne sont pas à votre main : ils arrivent dans CloudWatch, Stackdriver ou Azure Monitor selon le fournisseur. Falco sait les consommer par des plugins dédiés, k8saudit-eks par exemple. La documentation Falco détaille le plugin correspondant à votre plateforme.

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:3.22@sha256:14358309a308569c32bdc37e2e0e9694be33a9d99e68afb0f5ff33cc1f695dce --rm -it -- /bin/sh -c "cat /etc/shadow"

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

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

Surveiller les alertes

Ces commandes fonctionnent avec ou sans tty=true : ce réglage change le moment où la ligne sort, pas le fait qu'elle sorte.

# 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 le contenu attendu, puis cherchez dans les journaux de démarrage la ligne de chargement du fichier : c'est là que les erreurs de syntaxe 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 les alertes vers une équipe avant d'avoir filtré le bruit garantit qu'elles 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

L'outillage a changé : falcoctl gère désormais les artefacts, règles et plugins, et simplifie nettement leur mise à jour. Les ConfigMaps restent valides pour vos règles personnalisées, mais ne construisez pas toute votre chaîne dessus si vous démarrez aujourd'hui.

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

Pour aller plus loin

Choisir sa certification : Situer la KCSA et la CKS une fois le volet sécurité parcouru.
Parcours KCSA : La certification qui valide précisément ces compétences de sécurité.

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

7 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