Правила файрвола описываются как код, проходят ревью в pull request (PR) и раскатываются автоматически по всему парку, так что файрвол становится частью вашего GitOps (управление инфраструктурой через git). Terraform-провайдер и REST API управляют политиками; взаимный TLS (mTLS) и подписанные Ed25519-бандлы защищают доставку от подмены; журнал аудита «было → стало» фиксирует каждое изменение. Наружу система не обращается: ни телеметрии, ни лицензионной активации. Один процесс закрывает задачи Dev, Sec и Ops.
Автоматизация в qf — это управление файрволом на каждом сервере (host-firewall) как кодом: политики и группы объектов (object-группы) описываются декларативно, проходят ревью в pull request, применяются через CI и версионируются в git. Центр управления (control plane) компилирует изменение в подписанные пакеты политики (бандлы) и рассылает их агентам по mTLS, а журнал аудита «было → стало» фиксирует, кто и что изменил. Ни одно правило файрвола не задаётся в обход кода.
Это решает задачу DevSecOps сразу для трёх ролей. Dev описывает доступы рядом с сервисом; Sec ставит ревью и подпись как контрольную точку в CI; Ops получает воспроизводимую раскатку без ручного iptables на каждом хосте. Один pull request проходит через привычный процесс ревью и превращается в изменение правил на всём парке.
Изменение политики проходит тот же путь, что и любой код: описание → ревью → предпросмотр → слияние → раскатка.
Ресурсы qf_policy и qf_object_group описываются в Terraform или через REST API — ресурс qf_policy задаёт селектор источника и назначения (метка app=front → app=db, порт 5432/tcp). Метки-селекторы (label selectors) вместо адресов: правило «фронт → БД» остаётся верным, когда парк меняется.
Изменение уходит в pull request. Предпросмотр (dry-run) в пайплайне показывает, какие хосты и правила изменятся ещё до применения: ревьюер видит эффект, а не только текстовый диф.
После слияния центр управления каскадно пересчитывает все затронутые хосты. Осиротевших машин и забытых правил не остаётся: пересчёт исходит из селекторов, а не из ручных списков.
Центр управления (CP) компилирует эффективный набор правил в пакет политики (бандл), подписывает его ключом Ed25519 и рассылает агентам по mTLS. Подпись — это подтверждение подлинности политики, а не лицензионный замок и не механизм активации.
Агент проверяет подпись и mTLS-канал, применяет бандл в обработке пакетов в ядре (датапате). Запись аудита «было → стало» фиксирует изменение и может пересылаться в SIEM вместе с событиями вердиктов (verdicts).
Если агент теряет связь с центром управления и не восстанавливает её за ~60 с, срабатывает dead-man watchdog: агент откатывается на предыдущее поколение бандла. Это предсказуемый откат по потере связи, а не детекция «плохой» политики.
Ресурсы qf_policy и qf_object_group в вашем стейте. Провайдер пока ставится локально — он ещё не опубликован в публичном Terraform Registry (v0.0.1).
Тот же контракт под капотом UI и провайдера. Скрипты, собственные пайплайны и интеграции работают через задокументированный REST-интерфейс.
Встроенный удостоверяющий центр (CA): регистрация (enrollment) агентов, ротация и отзыв сертификатов. Канал агент↔CP — взаимный TLS. Агент не обращается наружу (нет phone-home) и не требует лицензионной активации или телеметрии — контур работает в изолированном режиме без интернета (air-gap).
Каждый бандл подписан Ed25519, и агент применяет только проверенную политику. Подлинность подтверждается при доставке, а не держится на доверии к сети.
Новый хост поднимается с двумя ключами в agent.conf; метки приходят из токена регистрации (zero-touch enrollment). Ни одного ручного шага на каждый хост, токен расходуется при подключении.
Каждое изменение записано в журнал аудита: кто и что менял, состояние до и после. Поток аудита и события вердиктов пересылаются в SIEM (форматы CEF / LEEF / ECS / RFC5424).
Разработчик описывает нужные потоки метками-селекторами в том же репозитории, что и код. Тикет в сеть и знание топологии парка не нужны.
Безопасность ставит обязательное ревью, предпросмотр и подпись бандла как условие слияния. Ed25519 + mTLS + аудит — воспроизводимая цепочка доверия.
Эксплуатация получает каскадную раскатку на весь парк из одного источника истины. Никаких расходящихся наборов правил на отдельных хостах.
Три независимых слоя между центром управления и датапатом агента — аутентификация канала, подпись политики и неизменяемый след.
| Слой | Механизм | Что гарантирует |
|---|---|---|
| Канал | mTLS gRPC | Взаимная аутентификация агента и CP: обе стороны предъявляют сертификат, выданный встроенным удостоверяющим центром (CA). |
| Политика | Подпись Ed25519 | Агент применяет только бандл с корректной подписью — доставленная политика подлинна и не подменена в пути. |
| След | Аудит «было → стало» | Каждое изменение зафиксировано с состоянием «до» и «после»; поток пересылается в SIEM для внешнего хранения. |
Отказоустойчивый (HA) центр управления — 2 реплики за TCP-балансировщиком с общим PKI (RWX) и единым MASTER_KEY / JWT_SECRET; это не развёртывание «под ключ» (turnkey). Ed25519 — подтверждение подлинности политики, а не лицензионный механизм.
Сколько занимает раскатка, что нужно на хосте для регистрации и сколько агентов держит один управляющий сервер.
Terraform-провайдер v0.0.1 пока не в публичном Registry.
Обращения наружу (phone-home) нет — это подтверждено разбором кода. Агент и центр управления общаются только между собой по взаимному TLS (mTLS); наружу система не обращается, ни телеметрии, ни лицензионной активации. Развёртывание полностью у вас (self-host, on-prem); контур работает в изолированном режиме без интернета (air-gap) — образы берутся из локального зеркала, а доверие к центру управления закрепляется отпечатком удостоверяющего центра вне основного канала. Ed25519 здесь — подтверждение подлинности политики, а не лицензионный механизм.
Да, провайдер есть: ресурсы qf_policy и qf_object_group. Но он пока не опубликован в публичном Terraform Registry (версия 0.0.1) и ставится локально. Для команд, которым нужен строго registry-провайдер, это стоит учитывать при планировании.
Двумя независимыми слоями. Канал агент↔CP — взаимный TLS (mTLS) с сертификатами от встроенного удостоверяющего центра (CA). Сам бандл подписан ключом Ed25519, и агент применяет только политику с корректной подписью. Ed25519 здесь — подтверждение подлинности политики, а не лицензионный замок.
Нет. qf работает на уровне L3/L4 (IP-адреса, порты, протоколы TCP/UDP/ICMP по IPv4). Прикладного разбора (L7/DPI) нет; непарсимый L4 (SCTP/GRE/ESP) проходит мимо правил; IPv6-CIDR не энфорсится. Полные границы покрытия расписаны в разделе про архитектуру (/architecture).
Да. Предпросмотр (dry-run) показывает, какие хосты и правила изменятся. Его удобно встроить в CI как контрольную точку в pull request. Наблюдаемый трафик доступен отдельно на странице хоста (вкладки Counters / Verdicts), а не внутри самого превью.
Агент продолжает энфорсить последний применённый бандл из офлайн-кэша — центр управления не стоит в датапате. Если связь не восстановлена за ~60 с, срабатывает dead-man watchdog и агент откатывается на предыдущее поколение бандла. Это откат по потере связи, а не автоматическая детекция «плохой» политики.