RBAC empêche une action non autorisée de se produire. Falco détecte un comportement anormal pendant qu’il se produit. Aucun des deux ne répond à une question qui se pose systématiquement après un incident de sécurité : qui, précisément, a fait quoi, quand, et avec quelle identité. Sans Audit Policy activée sur le serveur API, cette question n’a tout simplement aucune réponse, quelle que soit la qualité du reste de la sécurité en place.

Ce que le serveur API enregistre, à condition de le demander

Chaque requête au serveur API Kubernetes (créer un pod, lire un Secret, supprimer un namespace) peut être journalisée, mais rien n’est enregistré par défaut : une Audit Policy explicite définit quelles requêtes journaliser et à quel niveau de détail.

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]

Sans cette policy, un accès à un Secret sensible (un get réussi, une lecture complète du contenu) ne laisse absolument aucune trace exploitable après coup : la question « qui a lu ce Secret la semaine dernière » n’a pas de réponse si personne n’a activé l’audit logging avant que la question ne se pose.

Quatre niveaux, un compromis volume contre détail

None n’enregistre rien pour les requêtes concernées. Metadata enregistre qui a fait la requête, quand, sur quelle ressource, mais jamais le contenu de la requête ni de la réponse. Request ajoute le contenu de la requête (utile pour savoir ce qui a été demandé), sans la réponse. RequestResponse enregistre tout, y compris le contenu complet de la réponse, le niveau le plus coûteux en volume de logs.

# Metadata suffit pour la plupart des ressources :
# qui, quand, quoi, sans le contenu complet
- level: Metadata
  resources:
    - group: ""
      resources: ["pods", "deployments"]
# RequestResponse réservé aux ressources vraiment sensibles,
# le contenu complet coûte cher en volume
- level: RequestResponse
  resources:
    - group: ""
      resources: ["secrets"]

Appliquer RequestResponse à toutes les ressources du cluster génère un volume de logs qui devient rapidement ingérable et coûteux à stocker : la policy se construit ressource par ressource, réservant le niveau le plus détaillé aux objets qui justifient réellement ce coût (Secrets, RBAC, ressources de sécurité), Metadata suffisant pour le reste.

Ce qui distingue l’audit log de tout le reste

Le RBAC répond à « cette action était-elle autorisée ? », toujours avant qu’elle ne se produise. Falco répond à « ce comportement à l’exécution est-il anormal ? », en temps réel. L’audit log répond à une question différente des deux : « que s’est-il réellement passé, historiquement, via l’API ? », une trace immuable une fois écrite, consultée après coup, souvent des jours ou des semaines après les faits, quand la question ne se posait encore à personne au moment des faits.

# Interroger l'audit log après coup, pour une question
# que personne n'avait anticipée au moment des faits
grep '"verb":"get".*"resource":"secrets"' audit.log | jq .user.username

À retenir

RBAC empêche, Falco détecte en direct, l’audit logging répond après coup à une question que ni l’un ni l’autre ne couvre : qui a fait quoi, précisément, via l’API. Sans Audit Policy explicite (rien n’est journalisé par défaut), cette question reste sans réponse, quelle que soit la qualité du reste de la sécurité déployée. Le niveau de détail (Metadata à RequestResponse) se choisit ressource par ressource, réservant le coût du détail complet aux objets qui le justifient, une des pièces qui complètent une fiabilité et observabilité qui couvre la sécurité au-delà de la seule prévention.