DigraphDocs Docker Infrastructure Graph

Docs / Безопасность

Безопасность

Инструмент наблюдения не должен становиться самой привилегированной частью инфраструктуры. Поэтому доступ к Docker идёт через узкий агент, опасные действия выключены по умолчанию, а секреты и токены шифруются.

Модель прав

Единый переключатель PRIVILEGES — security boundary, поэтому задаётся только через env и не меняется из интерфейса.

ЗначениеЧто разрешаетПо умолчанию
read-onlyТолько чтение: граф, история, логи, inspectда
actionsStart, stop, restart, pause, kill, removeнет
execТерминал и exec внутрь контейнеранет
pushДоставка секретов; требует execнет
composeup/down/restart/pull проектовнет
allВсе перечисленные возможностинет

Проверка выполняется дважды: в приложении (скрытые кнопки и 403) и в docker-api (независимая политика и запись deny в аудит).

Агент вместо сокета

  • Веб-контейнер не монтирует docker.sock; сокет есть только у docker-api и compose-runner.
  • Приложение общается с агентом по типизированному /v1, а не сырым Docker API.
  • Raw-пути ограничены allow-list и доступны только сканерам томов и уязвимостей.
  • Агент маскирует Config.Env, не-compose labels и креденшелы в истории слоёв.

Аутентификация

МеханизмДетали
Пароль контураAUTH_TOKEN; слабые и короткие значения останавливают запуск
JWTAccess 15 минут, refresh 7 дней, HS256; refresh ротируется при каждом обновлении
Rate limitНе более 5 попыток входа в минуту с одного IP
OIDC (портал)Authorization Code + PKCE (S256), nonce, проверка подписи по JWKS, allowlist по email/домену
Обмен SSOПровайдерские токены меняются на пару JWT через одноразовый HttpOnly-cookie
WebSocketПроверка Origin (same-origin + ALLOWED_ORIGINS)

Fail-closed. Без AUTH_TOKEN приложение не стартует. AUTH_DISABLED=true — только явный opt-out для доверенной локальной машины.

Шифрование

  • Каждый секрет шифруется AES-256-GCM собственным data key.
  • При заданном SECRET_MASTER_KEY data key оборачивается мастер-ключом и хранится с префиксом v2: (envelope).
  • AI-ключ и секрет вебхука хранятся отдельно и никогда не возвращаются в браузер — только флаг «задан».
  • Токены контуров в БД портала шифруются PORTAL_SECRET_MASTER_KEY и не попадают в UI.
  • Ротация мастер-ключа пере-оборачивает все data key и AI-ключ в одной транзакции.

Аудит и redaction

docker-api пишет в кольцевой буфер отказы (DENY) и все мутирующие вызовы. Приложение добавляет собственные события: действия с контейнерами, CRUD секретов, push, изменение настроек. Страница /#/security показывает решение, причину и IP клиента, /#/events — общую ленту.

Redaction логов включён по умолчанию: пароли, токены, JWT, URL-креденшелы и приватные ключи вырезаются из live-логов, истории и захваченных срезов.

Харденинг

  • Read-only rootfs у приложения и sidecar'ов, cap_drop, no-new-privileges.
  • Базовые и compose-образы закреплены по digest; scripts/check-pins.sh проверяет репозиторий.
  • Registry: pull анонимный, push — только по логину; каталог репозиториев (/v2/_catalog) без креденшелов закрыт.
  • Сетевые сегменты backend, control, telemetry — внутренние.
  • Статические сайты (лендинг, docs) работают под непривилегированным nginx, без cap'ов, со строгим CSP.
  • Компоуз-раннер принимает только узкий набор действий; произвольные аргументы запрещены.

Рекомендации для продакшена

  1. Поставьте TLS перед контуром и порталом; включите HSTS и редирект с HTTP.
  2. Настройте OIDC SSO на портале и ограничьте доступ по email или домену.
  3. Храните SECRET_MASTER_KEY в менеджере секретов, а не в git; делайте резервную копию ключа отдельно от базы.
  4. Оставьте PRIVILEGES=read-only, пока действия действительно не нужны; включайте по одному.
  5. Ограничьте сетевой доступ к docker-api и порту контура на уровне хоста.
  6. Не храните приватные образы в registry с анонимным pull: для них нужен token-auth или отдельный приватный реестр.
  7. Проверяйте /#/security и ленту событий; настройте вебхуки на критические события.
  8. Делайте бэкапы SQLite и проверяйте restore на стенде.