qf хостовый firewall на eBPF
eBPF control plane

Автономный центр управления для eBPF host-firewall — без Kubernetes и etcd

Центр управления (control plane) один: он компилирует и подписывает политику, а eBPF-агент на каждом сервере применяет (enforcement) её в ядре. qf разграничивает доступ между серверами, то есть горизонтальный (east-west) трафик внутри сегмента. При этом центр управления никогда не стоит в пути пакета (datapath).

как устроена архитектура

Центр управления и лёгкие агенты

qf делится на две части: центр управления (control plane) и по одному лёгкому агенту на каждый сервер. Центр управления компилирует политики по меткам-селекторам в данные BPF-карт и рассылает подписанные пакеты политики (бандлы) по mTLS gRPC-потоку, а агент применяет (enforcement) их в ядре. Так qf разграничивает горизонтальный (east-west) доступ между серверами внутри сегмента: управление централизовано, применение правил распределено по серверам.

Центр управления автономен: без Kubernetes, без etcd, без service mesh. Всё его состояние хранится в PostgreSQL и каталоге PKI, поэтому он работает одним процессом под systemd или в контейнере. Не нужен ещё один управляющий слой, который надо обслуживать, и нет обращений наружу (phone-home).

поток

От изменения политики до применения в ядре

От изменения политики в UI до записей в BPF-картах: компиляция, подпись, раздача по номеру генерации, применение правил.

  1. 01

    Политика по меткам

    Оператор описывает политики по меткам-селекторам и группы объектов (ipset / portset / hostset) через REST или UI. Источник правды — политика, а не хост.

  2. 02

    Компиляция + каскад

    Изменение запускает каскадный пересчёт затронутых серверов. Центр управления строит эффективный набор правил (ruleset) и компилирует его в данные BPF-карт для каждого сервера.

  3. 03

    Подпись + раздача

    Каждый бандл подписывается Ed25519 (аутентичность политики) и раздаётся живым агентам по двунаправленному mTLS gRPC-потоку с инкрементным номером генерации.

  4. 04

    Применение в ядре

    Агент проверяет подпись, транслирует бандл в записи BPF-карт и применяет к работающему eBPF-пути данных (datapath) на TC-хуке — без зависимости от iptables.

  5. 05

    Поток обратно

    Агенты стримят обратно события вердиктов, системные и flow-события плюс счётчики; центр управления партиционирует их в PostgreSQL и раздаёт живые обновления в UI.

Центр управления не стоит в пути пакета

Если центр управления недоступен, агенты продолжают применять последний бандл из офлайн-кэша и буферизуют события до восстановления связи. Обрыв связи не рвёт трафик (fail-open): падение центра управления не останавливает путь данных.

компоненты

Из чего состоит система

01 · центр управления

Автономный центр управления (control plane)

Один Go-процесс: компилятор политик, PKI/CA, gRPC-сервер для агентов, REST/UI. Состояние — PostgreSQL плюс каталог PKI, без Kubernetes и etcd. От 1 vCPU / 256 МБ RAM; отказоустойчивость — 2 реплики за TCP-балансировщиком с общим PKI и одним master-ключом.

02 · агенты

Лёгкие агенты на каждом сервере

Небольшой Go-бинарь: загружает eBPF-объекты, управляет BPF-картами и цепляется к интерфейсу. Применяет последний известный бандл даже офлайн и потребляет минимум ресурсов.

03 · gRPC-поток

Подписанные бандлы по gRPC

Двунаправленный mTLS-поток между агентом и центром управления. Новые бандлы раздаются по номеру генерации; отдельный unary-сервис отвечает за одноразовую регистрацию агента (enrollment). События и счётчики идут обратно по тому же соединению.

04 · путь данных

Attach под ядро (kernel-adaptive)

TCX на ядрах ≥6.6 (сосуществует с Cilium), классический TC (clsact + cls_bpf) на <6.6 без Cilium. Две BPF-сборки: до 2048 правил на ≥5.17 и ограниченный вариант на 32 правила для 5.15–5.16. Вариант выбирается при загрузке по возможностям ядра.

валидация

Встраивается в архитектуру, которая у вас уже есть

qf — файрвол на каждом сервере (host-firewall), а не оверлей или оркестратор. Он встаёт рядом с тем, что у вас уже развёрнуто, и не забирает управление на себя.

Дополняет периметр, не заменяет

Периметровый шлюз (NGFW) режет вертикальный трафик север-юг (north-south) на границе зон и не видит связей между серверами внутри сегмента. qf разграничивает горизонтальный (east-west) доступ в ядре каждого сервера. Он дополняет периметр, а не подменяет его.

Сосуществует с Cilium

На ядре ≥6.6 qf цепляется через TCX и работает рядом с Cilium без конфликта за qdisc. На <6.6 с уже подключённым Cilium qf отказывается стартовать, чтобы не создать конфликт. Это явный предел, о котором сказано заранее.

Не нужно распутывать iptables

Применение правил — это eBPF на TC-хуке, а не правила netfilter. qf не переписывает ваши цепочки iptables/nftables; он гоняет L3/L4-фильтр в ядре и не трогает остальной стек.

Не нужен новый оркестратор

Центр управления не требует ни Kubernetes, ни etcd, ни service mesh. Управление файрволом не превращается в ещё одну распределённую систему, которую надо обслуживать.

Работает в закрытом контуре

Никаких обращений наружу (phone-home). Регистрация агента — registry-mirror плюс OOB-пиннинг отпечатка CA, а агенты применяют правила и офлайн, так что та же архитектура работает в изолированном контуре без интернета (air-gap).

граница покрытия

Что qf режет, а что проходит мимо

qf разграничивает горизонтальный (east-west) доступ на уровне L3/L4 по IPv4. Под правила попадает не весь трафик: часть протоколов проходит мимо, и «весь east-west» qf не закрывает.

режем

L3/L4 по IPv4

TCP, UDP, ICMP/ICMPv6 по IPv4: подсети (CIDR), диапазоны портов, TCP-флаги, состояние соединения (conntrack). Это ядро правил и режима «по умолчанию запрещать» (default-deny).

мимо

Прикладного уровня (L7) нет

qf работает на L3/L4 и не разбирает содержимое пакетов: ни L7-политик, ни разбора протоколов приложений (DPI). Для правил по HTTP-путям, доменам или SNI нужен отдельный слой.

мимо

Непарсимый L4 проходит

Матчер разбирает TCP/UDP/ICMP. Непарсимые протоколы L4 (SCTP, GRE, ESP, OSPF) проходят мимо правил и НЕ попадают под «по умолчанию запрещать». Если они есть в парке, это надо учитывать в модели угроз.

мимо

IPv6-CIDR не энфорсится

qf — IPv4-first. По умолчанию IPv6 дропается целиком; при включённом v6 фильтр по подсетям (CIDR) не применяется: IPv6 покрывается best-effort по протоколу и порту, но не по CIDR.

факт-числа

Масштаб и честные пределы

5000+
агентов на один центр управления
0
зависимостей от Kubernetes / etcd
≥ 5.15
минимальное ядро Linux
256 МБ
центр управления от 1 vCPU / 256 МБ

Один центр управления обслуживает более 5000 агентов. Веерная раздача (fan-out) идёт последовательно: политика на 500 серверов раскатывается за 5–15 секунд, на 5000 — за 30–90 секунд. На ядрах <6.6 с уже подключённым Cilium qf отказывается стартовать.

вопросы

Частые вопросы

Что qf НЕ фильтрует?

qf работает на L3/L4 по IPv4: TCP/UDP/ICMP, подсети (CIDR), порты, TCP-флаги. Прикладного уровня (L7) и разбора содержимого (DPI) нет. Непарсимый L4 — SCTP, GRE, ESP, OSPF — проходит мимо правил и не попадает под «по умолчанию запрещать» (default-deny). IPv6 по подсетям (CIDR) не энфорсится: по умолчанию v6 дропается, иначе покрывается best-effort по протоколу и порту. Поэтому «весь east-west» — это преувеличение: на деле qf разграничивает горизонтальный доступ на L3/L4 по IPv4.

Почему без Kubernetes и etcd?

Потому что host-firewall не должен требовать держать ради него ещё одну распределённую систему. Центр управления — один Go-процесс, состояние которого это PostgreSQL плюс каталог PKI. Он работает автономно под systemd или в контейнере, а отказоустойчивость — это просто две реплики за TCP-балансировщиком.

Что будет, если центр управления упадёт?

Применение правил продолжается. Центр управления не стоит в пути пакета (datapath). Агенты применяют последний подписанный бандл из офлайн-кэша и буферизуют события на диск до восстановления связи. Так задумано (fail-open): забытая политика или недоступный центр управления не отрежут сервер.

Как откатить неудачную политику?

Отдельной кнопки «мгновенный откат» нет. Перед применением есть предпросмотр влияния (dry-run) и режим наблюдения (observe / would-deny) — видно, кого заденет политика, без дропа. Каждое применение — новое поколение бандла; предыдущие версии политики и поколения сохраняются, аудит фиксирует «было → стало», поэтому откат — это возврат к прошлому поколению, а не отдельная операция.

Сосуществует ли qf с Cilium?

На ядре ≥6.6 qf цепляется через TCX и сосуществует с Cilium. На <6.6 без Cilium используется классический TC. На <6.6 с уже подключённым Cilium qf отказывается стартовать, чтобы не конфликтовать за qdisc. Это явный, задокументированный предел, а не тихий сбой.

Какова накладная нагрузка датапата на пакет?

Фильтр работает inline в ядре на TC-хуке; накладная нагрузка на пакет (ns/пакет) зависит от ядра, числа правил и конфигурации и снимается харнессом bench-bpf на целевом хосте. Это замер, а не расчёт: единой цифры «ns/пакет» не существует.

Как масштабируется и где пределы?

Один центр управления тянет более 5000 агентов. Раздача бандлов (fan-out) последовательная: 500 серверов получают новую политику за 5–15 секунд, 5000 — за 30–90 секунд. Ёмкость правил — до 2048 на ядрах ≥5.17 и 32 на 5.15–5.16.

Как qf встанет в ваш парк