Перейти к основному содержимому

Работа в консоли qf

Руководство описывает повседневную работу с политиками, хостами и сетевыми событиями в Web UI. Установка и настройка инфраструктуры описаны в руководстве по развёртыванию.

Подробности о правилах и политиках, селекторах, группах объектов и хостов и статусах хостов вынесены в отдельные гайды. Здесь описаны только операции в интерфейсе.

1. Вход и обзор (Dashboard)​

Консоль доступна по адресу https://<cp-host>/app/. После входа по паролю или через SSO открывается Dashboard со статусами хостов и последними событиями.

Слева — навигация: Hosts, Policies, Object Groups, Host Groups, Verdicts, Flows, Audit Log, Tokens, Users. Переключатель темы и меню пользователя — справа сверху.

2. Энролмент нового хоста​

Хост подключается по enrollment-токену. Токен может назначить хосту лейблы и добавить его в группу.

Шаги​

  1. Tokens → New token.

  2. Тип bulk (для массового энролла) или single_host.

  3. Задать Label key/value — например role=web. Эти лейблы получит каждый хост, энролленный токеном (определяют, какие политики к нему применятся).

  4. TTL и Max uses — срок и лимит использований.

  5. Create.

  6. UI покажет токен один раз и базовый agent.conf.

Рабочая конфигурация на целевом хосте содержит базовые поля и способ проверки CA:

QF_ENDPOINT=cp.example.com
QF_ENROLL_TOKEN=PASTE_ENROLL_TOKEN_HERE
QF_ENROLL_CA=/etc/qf/ca.crt

CA-файл нужно получить по доверенному каналу до первого запуска. Вместо PEM-файла можно использовать пин по отпечатку или получение CA через публично доверенный REST API. Все варианты описаны в гайде по ручному энролменту.

Запуск агента:

sudo systemctl enable --now qf-agent

Агент проверяет CA, получает клиентский сертификат и подключается к Control Plane. После подтверждения конфигурации хост появляется в Hosts со статусом Active и лейблами из токена.

Вкладка API Tokens — отдельные токены для CI/автоматизации (роли admin/editor/auditor).

3. Обзор хостов и статус​

Hosts — список флота: статус, лейблы, IP, версия агента, поколение (gen), последний heartbeat. Фильтр по hostname/лейблу и по статусам сверху.

Статусы: Active (на связи, конфиг подтверждён), Pending (применяет изменения), Degraded (долго не подтверждает), Stale (нет heartbeat).

Клик по хосту → детальная страница:

  • Agent info — версия, ядро, поколения (desired/confirmed), heartbeat.
  • Datapath & capabilities — режим attach (TCX/classic), лимит правил (2048; eBPF-фичи bpf_loop+ringbuf, mainline ≥5.17 или бэкпорт), ОС, CPU, наличие Cilium, ip_forward.
  • Interfaces — интерфейсы, адреса, какой приаттачен.
  • Вкладки: Policies, Ruleset (эффективные правила), Verdicts, Flows, Counters, Groups.

4. Создание политики​

Политика объединяет селектор хостов и набор правил.

Шаги​

  1. Policies → New policy.
  2. Имя, описание, приоритет (меньше число = выше при first-match).
  3. Селектор хостов → Лейблы — например role=web. Политика применяется ко всем хостам с этим эффективным лейблом, включая унаследованные от групп.
  4. Добавить правило — для каждого правила:
    • Direction: ingress / egress.
    • Action: allow / deny / log.
    • Match: протокол, порты (одиночные 443 и диапазоны 8080-8090), CIDR, или ссылка на object group; опционально TCP-флаги и conntrack-state.
    • Log + rate-limit — логировать срабатывания.
  5. Сохранить политику. При создании отдельного предпросмотра нет, поэтому для широкой области сначала используется действие log.

⚠️ deny без match блокирует весь поддерживаемый трафик, а блокировка порта 22 может закрыть SSH. Агент сохраняет исходящие соединения к IPv4-адресам Control Plane, разрешённым при его старте, но не защищает другие административные каналы. Перед широким запретом нужны разрешающие правила для них и этап наблюдения с действием log. Default action = ALLOW: без явного deny трафик проходит.

Политика с пустым (match-all) селектором требует подтверждения вводом её имени — защита от случайного применения на весь флот.

Версии и откат​

Изменения существующей политики выполняются во вкладке Редактирование. Действие Зафиксировать изменение и посмотреть зону влияния создаёт черновик и показывает затронутые хосты и различия правил. Enforcement меняется только после действия Применить.

Вкладка История хранит снимок каждого применения. Действие Откатить создаёт новую текущую версию на основе выбранного снимка, после чего Control Plane пересчитывает конфигурации затронутых хостов.

5. Группы хостов​

Группа задаёт общие лейблы для своих членов — удобно для «всех web-серверов».

  1. Host Groups → New group.
  2. Имя, лейблы (role=web, env=prod), приоритет.
  3. Добавить членов (хосты).

Лейблы группы наследуются хостами; прямые лейблы хоста перекрывают групповые. Изменение лейбла группы пересчитывает политики для всех её членов. Селектор role=web выбирает членов группы, у которых итоговый набор лейблов содержит это значение.

Новая группа сохраняется сразу. Изменение существующей группы сначала создаётся как черновик действием Зафиксировать изменение и посмотреть зону влияния. Лейблы и состав участников меняются только после действия Применить.

6. Object Groups (переиспользуемые наборы)​

Чтобы не дублировать списки IP/портов в правилах:

  1. Object Groups → New.
  2. Тип:
    • ipset — список CIDR/IP (203.0.113.0/24).
    • portset — порты и диапазоны (443, 8080-8090).
    • hostset — селектор → динамически резолвится в IP подходящих хостов.
  3. В правиле политики сослаться на набор через соответствующее поле IP-, port- или host-set.

Правка набора пересчитывает все политики, где он используется. Набор, на который ссылается правило, нельзя удалить. Пустые ipset и portset отклоняются при сохранении. Если динамический hostset временно не находит хосты, пустое значение не превращается в ANY. Затронутый хост сохраняет last-good generation, пока набор снова не станет непустым.

Новый набор сохраняется сразу. Изменение существующего набора проходит через черновик, Зону влияния и действие Применить.

7. Наблюдаемость​

Flows — какие соединения идут​

Flows при включённой отправке flow-событий показывает соединения, адреса, протокол и объём данных. Доступны поиск по порту, сортировка и фильтры.

Включить на хосте: на странице хоста переключатель Flow events.

Verdicts — сработавшие правила​

Verdicts показывает срабатывания логируемых правил, в том числе deny: время, правило, направление, адреса и порты. По этим данным определяется правило, остановившее трафик.

Counters​

Вкладка Counters на хосте — счётчики попаданий по каждому правилу (пакеты/байты). Глобальные pass/drop и заполнение карт видны в метриках хоста (heartbeat).

8. Разбор инцидента (deny)​

Типовой сценарий «почему не идёт трафик»:

  1. Hosts → хост → Ruleset — посмотреть эффективные правила (что реально применено).
  2. Verdicts — найти deny-события по порту/адресу: какое правило сработало.
  3. Counters — подтвердить рост счётчика этого правила.
  4. Исправить лишнее правило или порядок правил. Меньшее значение Priority проверяется раньше.

9. Audit Log​

Audit Log показывает, кто, что и когда менял: мутации политик, групп, токенов и хостов с состоянием до и после и именем автора. Доступ к журналу есть только у роли admin.

10. Правила безопасной работы​

  • Default ALLOW — фильтруется только явный deny; забыть правило = трафик пройдёт, а не упадёт.
  • deny без match и ограничения порта 22 вводятся только после разрешающих правил для административного доступа, проверки зоны влияния и этапа log.
  • Зона влияния проверяется перед применением изменений существующей политики с широким selector.
  • Сначала log-правило (понаблюдать в Verdicts), потом deny.
  • Токены показываются один раз — хранить безопасно, отзывать при утечке.
  • Число эффективных правил должно укладываться в лимит, указанный в Datapath & capabilities для конкретного хоста.