Подключение eBPF бэкстопа

Наблюдатель уровня ядра eBPF — некооперативная наземная истина для файлового и сетевого I/O, которую ни один агент не может обойти.

eBPF бэкстоп — это некооперативный наблюдатель наземной истины. Он подключается к точкам трассировки системных вызовов ядра и сообщает о файловом и сетевом I/O как рёбрах карты доступа, которые ни один процесс пользовательского пространства не может обойти, отключить или исказить. Где кооперативная телеметрия доверяет агенту честно сообщать, бэкстоп этого не делает — он наблюдает ядро, а не агента.

Для общей модели источников и структуры OLIVARES_SOURCES_CONFIG см. Подключение источника. Для кооперативного пути, который бэкстоп дополняет, см. Подключение Claude Code.

Что он наблюдает

Бэкстоп инструментирует системные вызовы уровня ядра — open, read, write, connect, sendto, recvfrom и их варианты — и генерирует одно наблюдение на каждое релевантное событие I/O. Классификация чтения/записи берётся из самого системного вызова, а не из того, что заявляет агент, поэтому она авторитетна так же, как авторитетен класс READ/WRITE pgAudit: ядро выполнило операцию, следовательно, операция произошла.

Результат — поток рёбер карты доступа, атрибутирующий файловый и сетевой I/O идентичности процесса на хосте. Эти рёбра питают ту же карту доступа, что и каждый другой источник.

Зачем он существует

Кооперативная телеметрия — экспорт OpenTelemetry, полезные нагрузки хуков, интроспекция MCP — богаче и выше уровнем, но она кооперативна: агент сам генерирует её. Агент, который отключает свой OTel-экспортёр, или среда выполнения, у которой его никогда не было, не производит никакого кооперативного сигнала.

eBPF бэкстоп закрывает этот пробел. Агент, который прекращает экспорт телеметрии, всё ещё выполняет системные вызовы; ядро всё ещё их видит; бэкстоп всё ещё о них сообщает. Это наземная истина, на которую ссылается документация Подключение Claude Code:

Наземная истина для действительно некооперативной активности — это ядерный/eBPF бэкстоп, а не эта эвристика.

Эта эвристика — обнаружение сессии, которая прекращает генерировать OTel, пока её хуки продолжают срабатывать — является аномальным сигналом кооперативной стороны. Бэкстоп делает некооперативную сторону наблюдаемой.

Уровень покрытия

Бэкстоп — это уровень clean в модели точности. Чтение и запись определяется из системного вызова, а не из того, что заявляет агент. В документации по точности он указан наряду с pgAudit и CloudTrail: «наземная истина eBPF уровня ядра». Чистое покрытие не подразумевает чистую атрибуцию — см. ограничения ниже.

Когда использовать его vs кооперативное наблюдение

Они дополняют друг друга; они не заменяют друг друга.

Кооперативное (OTel, хуки, MCP) — более высокоуровневый контекст: сессии, инструменты, модели, затраты. Более богатая карта.
Некооперативное (eBPF) — гарантия защиты от обхода: что фактически произошло на уровне ядра, независимо от того, что агент решил сообщить.

Запускайте оба. Кооперативный путь строит богатую карту, по которой вы управляете. Бэкстоп предоставляет неподделываемый минимум, который ловит всё, что пропустил кооперативный путь — обход, неправильная конфигурация или среда без телеметрии.

Модель развёртывания

Бэкстоп работает на каждом хосте, где выполняются агенты, подключённый к стандартному serve как тип источника ebpf наряду с pgaudit, s3cloudtrail, runtime, mcp и claude. Поскольку программы eBPF подключаются к ядру хоста, один экземпляр на хост покрывает каждый процесс агента. Нет шага установки для каждого агента.

Привилегии Linux

Трассировка eBPF требует повышенных привилегий ядра. Как минимум, процессу, загружающему программы eBPF, нужны привилегии семейства CAP_BPF и CAP_PERFMON (или эквивалент, в зависимости от версии ядра — старые ядра объединяют их в CAP_SYS_ADMIN).

:::caution Точный набор привилегий зависит от версии ядра, дистрибутива и модуля безопасности (AppArmor, SELinux). Проверьте документацию коннектора для точных требуемых флагов — эта страница не приводит исчерпывающий набор, потому что он варьируется между окружениями. Запуск в контейнере требует явных грантов привилегий (и, возможно, монтирования файловой системы BPF); заблокированный под Kubernetes требует переопределений securityContext. :::

Конфигурация

Выберите kind: "ebpf" в OLIVARES_SOURCES_CONFIG, используя ту же структуру записи источника, что и каждый другой коннектор:

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

Точные ключи конфигурации принадлежат коннектору; читайте его дескриптор, а не копируйте неверифицированную схему. Объект config выше намеренно пуст — эта страница следует тому же правилу, что и Подключение источника: мы документируем только ключи, которые верифицировали, а мы не верифицировали поверхность конфигурации eBPF-коннектора из этих веб-документов.

Свойства защиты от обхода

Бэкстоп не зависит от кооперации агента:

Агент, который отключает свой OTel-экспортёр, всё ещё генерирует системные вызовы ядра — бэкстоп их видит.
Агент, который лжёт в своей кооперативной телеметрии, не может лгать ядру. Запись системного вызова авторитетна.
MCP-сервер, который неверно сообщает readOnlyHint / destructiveHint, не влияет на то, что наблюдает бэкстоп — это кооперативные сигналы, которые он не потребляет.

Кооперативная эвристика в Подключение Claude Code — сессия, чей OTel замолкает, пока хуки продолжают срабатывать — это сигнал обнаружения. Бэкстоп — это наземная истина, на которую указывает этот сигнал.

Честные ограничения

Бэкстоп наблюдает то, что видит ядро, а не то, что намеревается агент. Это различие имеет значение:

Атрибуция на уровне процесса. I/O атрибутируется идентичности процесса (PID, UID, путь бинарного файла). Если несколько агентов разделяют один процесс, бэкстоп не может разделить их доступы — атрибуция approximate, а не firm. Атрибуция по агенту требует сигнала идентичности по агенту; см. Точность.
Нет контекста сессии или инструмента. Бэкстоп видит системные вызовы, а не сессии или имена инструментов. Он не может сказать, какой вызов инструмента вызвал запись файла — только что процесс записал файл. Кооперативный путь несёт этот контекст.
Зависимость от версии ядра. Доступность точек трассировки eBPF варьируется между версиями ядра. Подтвердите минимальную версию ядра по документации коннектора.
Нет содержимого полезной нагрузки. Как и каждый источник, бэкстоп генерирует идентификаторы и классификацию чтения/записи, никогда — содержимое файлов или сетевые полезные нагрузки.

Связанные материалы

Подключение источника — общая модель источников и файл конфигурации.
Подключение Claude Code — кооперативный путь, который бэкстоп дополняет.
Покрытие и точность атрибуции — оси clean/lossy/opaque и firm/approximate/unknown.
Карта доступа — что строят эти наблюдения.