Files
orchestrator/docs/work-items/ORCH-022/07-infra-requirements.md

4.6 KiB
Raw Blame History

07 — Инфраструктурные требования: Security-гейт (ORCH-022)

См. 06-adr/ADR-001-security-gate.md (Р-2, Р-3, Р-8). Топология не меняется (один сервер mva154, Docker Compose). Новые требования — только инструменты сканирования и сетевой доступ к CVE-фиду.

I-1. Бинарь gitleaks в образе

  • Что: статический Go-бинарь gitleaks (secret-scanning), устанавливается в Dockerfile (НЕ pip-пакет). Зафиксировать версию (pinned release) для детерминизма.
  • Почему в образе, а не на хосте: гейт исполняется внутри контейнера оркестратора (advance_stage); сканируется per-task worktree, смонтированный в контейнер.
  • Оффлайн: gitleaks не требует сети (правила локальны) → гарантия «секрет всегда блокирует» (BR-2) не зависит от доступности интернета.
  • Контракт exit-кодов: 0 = чисто, 1 = найдены секреты, ≥2 = ошибка инструмента (≥2 → never-raise degrade-вердикт гейта).

I-2. pip-audit в зависимостях

  • Что: Python-пакет pip-audit (dependency audit), добавляется в requirements.txt (pinned-версия).
  • Источник advisory: OSV / PyPI advisory DB — требует сетевого доступа (исходящий HTTPS к OSV/PyPI).
  • Цель v1: аудит requirements.txt корня репо (Python-стек, A3). Мульти-стек — follow-up.

I-3. Сетевой доступ к CVE-фиду (degrade-политика)

  • Требование: исходящий HTTPS из прод-контейнера к OSV/PyPI advisory.
  • При недоступности (Р-3): fail-open + громкий warning по умолчанию — dep-audit не краснит гейт из-за сетевого сбоя (анти-петля ORCH-061); фиксируется deps_audit_degraded: true + Telegram + лог. Флаг security_dep_audit_fail_closed (дефолт false) — для перевода в строгий режим без редеплоя кода.
  • Секреты не зависят от сети (I-1) — критическая гарантия безусловна.

I-4. Конфиг-файлы в репозитории (версионируемые, BR-13)

  • .gitleaks.toml (корень репо): правила + аллоулист заведомо-безопасных совпадений (плейсхолдеры .env.example, тест-фикстуры). Версионируется, ревьюится как код.

I-5. Env-флаги (.env.example + хост .env/.env.staging)

Переменная Дефолт Назначение
ORCH_SECURITY_GATE_ENABLED true глобальный kill-switch
ORCH_SECURITY_GATE_REPOS `` (пусто) CSV scope; пусто → только self-hosting
ORCH_SECURITY_DEP_BLOCK_SEVERITY HIGH порог блокировки зависимостей
ORCH_SECURITY_SCAN_TIMEOUT_S 300 таймаут каждого внешнего вызова сканера
ORCH_SECURITY_DEP_AUDIT_FAIL_CLOSED false строгий режим при недоступном фиде
ORCH_SECURITY_SECRETS_BLOCK true секреты блокируют (всегда по дефолту)

Секреты-значения в гит НЕ коммитятся (CLAUDE.md §8) — только дефолты в .env.example.

I-6. Ресурсы и тайминги

  • Время сканирования добавляется к каждому прогону задачи на ребре deploy-staging → deploy, ограничено ORCH_SECURITY_SCAN_TIMEOUT_S (по образцу merge_retest_timeout_s).
  • Гейт исполняется ДО merge-gate/image-freshness (дёшево фейлить до дорогих rebase/rebuild).

I-7. Self-hosting safety (инвариант)

Гейт только читает/сканирует (git, gitleaks, pip-audit, запись артефакта). Не вызывает деплой-хук, не рестартит/не трогает прод-контейнер (8500/8501). Прод-деплой ORCH-022 — строго через staging-гейт (8501).