Aller au contenu

Guides

Connecter le backstop eBPF

L'observateur eBPF au niveau noyau — vérité terrain non coopérative pour les I/O fichier et réseau qu'aucun agent ne peut éviter.

Dernière mise à jour:

Le backstop eBPF est l’observateur de vérité terrain non coopératif. Il s’attache aux tracepoints syscall du noyau et rapporte les I/O fichier et réseau comme des arêtes de carte d’accès qu’aucun processus utilisateur ne peut éviter, désactiver ou déformer. Là où la télémétrie coopérative fait confiance à l’agent pour rapporter honnêtement, le backstop non — il observe le noyau, pas l’agent.

Pour le modèle de source général et la structure OLIVARES_SOURCES_CONFIG, voir Connecter une source. Pour le chemin coopératif que le backstop complète, voir Connecter Claude Code.

Ce qu’il observe

Le backstop instrumente les syscalls au niveau noyau — open, read, write, connect, sendto, recvfrom et leurs variantes — et émet une observation par événement I/O pertinent. La classification lecture/écriture provient du syscall lui-même, pas de ce que l’agent prétend, elle est donc autoritaire de la même manière que la classe READ/WRITE de pgAudit est autoritaire : le noyau a effectué l’opération, donc l’opération a eu lieu.

Le résultat est un flux d’arêtes de carte d’accès attribuant les I/O fichier et réseau à une identité de processus sur l’hôte. Ces arêtes alimentent la même carte d’accès que toute autre source.

Pourquoi il existe

La télémétrie coopérative — exports OpenTelemetry, charges utiles de hooks, introspection MCP — est plus riche et de plus haut niveau, mais elle est coopérative : c’est l’agent qui l’émet. Un agent qui désactive son exporteur OTel, ou un runtime qui n’en a jamais eu, ne produit aucun signal coopératif.

Le backstop eBPF comble cette lacune. Un agent qui arrête d’exporter la télémétrie fait toujours des syscalls ; le noyau les voit toujours ; le backstop les rapporte toujours. C’est la vérité terrain que le document Connecter Claude Code référence :

La vérité terrain pour l’activité véritablement non coopérative est le backstop noyau/eBPF, pas cette heuristique.

Cette heuristique — détecter une session qui arrête d’émettre OTel alors que ses hooks continuent de tirer — est un signal d’anomalie côté coopératif. Le backstop rend le côté non coopératif observable.

Niveau de couverture

Le backstop est de niveau clean dans le modèle de fidélité. Lecture vs écriture est déterminé depuis le syscall, pas depuis ce que l’agent prétend. Le document de fidélité le liste aux côtés de pgAudit et CloudTrail : « la vérité terrain eBPF au niveau du noyau ». Une couverture clean n’implique pas une attribution clean — voir les limites ci-dessous.

Quand l’utiliser vs l’observation coopérative

Ils se composent ; ils ne se remplacent pas.

  • Coopératif (OTel, hooks, MCP) — contexte de plus haut niveau : sessions, outils, modèles, coûts. La carte plus riche.
  • Non coopératif (eBPF) — la garantie anti-évasion : ce qui s’est réellement passé au niveau noyau, indépendamment de ce que l’agent a choisi de rapporter.

Exécutez les deux. Le chemin coopératif construit la carte riche contre laquelle vous gouvernez. Le backstop fournit le plancher infalsifiable qui capture tout ce que le chemin coopératif a manqué — évasion, mauvaise configuration, ou un runtime sans télémétrie.

Modèle de déploiement

Le backstop s’exécute sur chaque hôte où les agents s’exécutent, câblé dans le serve standard comme type de source ebpf aux côtés de pgaudit, s3cloudtrail, runtime, mcp, et claude. Parce que les programmes eBPF s’attachent au noyau de l’hôte, une instance par hôte couvre chaque processus d’agent. Il n’y a pas d’étape d’installation par agent.

Capacités Linux

Le traçage eBPF nécessite des privilèges noyau élevés. Au minimum, le processus chargeant les programmes eBPF a besoin de capacités de la famille CAP_BPF et CAP_PERFMON (ou équivalent, selon la version du noyau — les noyaux plus anciens regroupent celles-ci dans CAP_SYS_ADMIN).

:::caution L’ensemble exact de capacités dépend de votre version de noyau, distribution, et module de sécurité (AppArmor, SELinux). Consultez la propre documentation du connecteur pour les flags précis requis — cette page ne liste pas un ensemble définitif car il varie selon les environnements. L’exécution dans un conteneur nécessite des autorisations de capacités explicites (et possiblement un montage de système de fichiers BPF) ; un pod Kubernetes verrouillé nécessite des surcharges securityContext. :::

Configuration

Sélectionnez kind: "ebpf" dans OLIVARES_SOURCES_CONFIG, en utilisant la même structure d’entrée source que tout autre connecteur :

{
  "sources": [
    {
      "name": "host-backstop",
      "kind": "ebpf",
      "tenant": "acme",
      "config": {}
    }
  ]
}

Les clés config exactes sont détenues par le connecteur ; lisez son descripteur plutôt que de copier un schéma non vérifié. L’objet config ci-dessus est intentionnellement vide — cette page suit la même règle que Connecter une source : nous ne documentons que les clés que nous avons vérifiées, et nous n’avons pas vérifié la surface de configuration du connecteur eBPF depuis ces docs web.

Propriétés anti-évasion

Le backstop ne dépend pas de la coopération de l’agent :

  • Un agent qui désactive son exporteur OTel génère toujours des syscalls noyau — le backstop les voit.
  • Un agent qui ment dans sa télémétrie coopérative ne peut pas mentir au noyau. L’enregistrement de syscall fait autorité.
  • Un serveur MCP qui rapporte de manière erronée readOnlyHint / destructiveHint n’affecte pas ce que le backstop observe — ce sont des signaux coopératifs qu’il ne consomme pas.

L’heuristique côté coopératif dans Connecter Claude Code — une session dont l’OTel devient silencieux alors que les hooks continuent de tirer — est un signal de détection. Le backstop est la vérité terrain vers laquelle ce signal pointe.

Limites honnêtes

Le backstop observe ce que le noyau voit, pas ce que l’agent a l’intention de faire. Cette distinction compte :

  • L’attribution est au niveau processus. Les I/O sont attribuées à une identité de processus (PID, UID, chemin du binaire). Si plusieurs agents partagent un processus, le backstop ne peut pas séparer leurs accès — l’attribution est approximate, pas firm. L’attribution par agent nécessite un signal d’identité par agent ; voir Fidélité.
  • Pas de contexte de session ou d’outil. Le backstop voit des syscalls, pas des sessions ou des noms d’outils. Il ne peut pas vous dire quel appel d’outil a déclenché une écriture de fichier — seulement que le processus a écrit le fichier. Le chemin coopératif porte ce contexte.
  • Dépendance à la version du noyau. La disponibilité des tracepoints eBPF varie selon les versions de noyau. Confirmez la version minimale du noyau contre la propre documentation du connecteur.
  • Pas de contenu de charge utile. Comme toute source, le backstop émet des identifiants et une classification lecture/écriture, jamais de contenus de fichiers ou de charges utiles réseau.

Voir aussi

Rechercher la documentation