Безопасность и контроль данных
Как Conveyor ограничивает утечку данных, изолирует плагины и фиксирует действия для разбора инцидентов.
На какие вопросы отвечает раздел: Остаются ли данные в вашем периметре? Какие TCP-маршруты допустимы для plugin executor? Чем отличаются Трассировка Запуска и журнал аудита?
Контур данных
Conveyor делит инфраструктуру на сегменты: data tier (PostgreSQL, Vault, Redis), оркестрация и исполнители. Сегменты могут жить в разных сетевых зонах. Сервисы оркестрации обращаются к data tier. Назначение шага исполнителю и ответ о его выполнении идут через runtime-control-plane по TCP. Встроенный executor может стоять рядом с ядром. Plugin executors чаще выносят в отдельный сегмент с CIDR allowlist.
Данные Запусков и секреты остаются в вашей инфраструктуре, пока вы сами не настроите исходящую интеграцию. Телеметрия (OpenTelemetry) включается при явной настройке экспорта. Переменные перечислены в справочнике конфигурации. В docker demo все контуры в одном контейнере. На production-стенде сегментацию сети задаёте вы.
Исходящие вызовы узлов (REST, почта, LLM) и egress-политики настраиваются на вашей стороне.
Условные обозначения: зелёная стрелка — доступ сервисов оркестрации к data tier; синяя — маршрут через runtime-control-plane.
Изоляция плагинов
К plugin executor из вашей сети платформа принимает входящие TCP-соединения (из allowlist) двух видов: публикация манифеста в plugin-manager и ответ о выполнении шага в runtime-control-plane. На схеме те же маршруты. Исполнитель получает payload конкретного шага.
| Переменная | Назначение |
|---|---|
PLUGIN_MANAGER_ALLOW_CIDRS | Подсети, с которых принимается TCP к приёму манифестов |
PLUGIN_MANAGER_INGRESS_TOKEN | Токен в манифесте плагина |
PLUGIN_CONTROL_PLANE_ALLOW_CIDRS | Подсети для ingress ответов исполнителей |
PLUGIN_CONTROL_PLANE_KEY | Ключ внутренних маршрутов control-plane |
Полный перечень см. в разделе «Развёртывание» и справочнике.
Аутентификация и авторизация
В docker demo вход через встроенные учётки с сидингом. WebAuthn и регистрация по умолчанию отключены (см. раздел «Развёртывание»).
В production используются JWT (access/refresh) и passkeys (WebAuthn). Вход через корпоративный IdP (OIDC, Keycloak) запланирован. Статус и сценарий внедрения описаны в «Администрировании».
Ключи API и MCP (afk_*) выдаются с областями действия. Маршруты /metrics и
/audit принимают запросы из подсетей allowlist (см. API_SENSITIVE_ROUTE_CIDRS в
справочнике).
Роли и тарифы задают видимость разделов редактора и допустимые действия: создание процессов, триггеры, пресеты.
Аудит и трассируемость
Трассировка Запуска фиксирует статусы узлов и результаты выполнения шагов, которые вернули исполнители. Это основной источник при разборе инцидента по конкретному Запуску.
Журнал аудита записывает действия пользователей в интерфейсе (создание,
изменение, удаление ресурсов). Он не дублирует Трассировку Запуска. Записи старше
срока хранения удаляет сервис audit-retention (переменная AUDIT_RETENTION_DAYS).
Где смотреть Трассировку Запуска в UI и как выгружать оба журнала, описано в «Наблюдаемости».
Дальше
- Развёртывание: переменные периметра и demo
- Наблюдаемость: экспорт трассировки и журнала