Два self-hosted S3, которые доверяют друг другу: DataSafeS3 v1.1.0

Репозиторий: github.com/DirektorBani/DataSafeS3
Лицензия: Apache-2.0
Релиз: DataSafeS3 CE v1.1.0 (июль 2026)

---

28 июня я описал патчи v1.0.1 и v1.0.2: SBOM, SSRF, JWT в URL после SSO, rate limit на login. В конце той статьи остались два «хвоста» — Prometheus /metrics без пароля и временный флаг STORAGE_OUTBOUND_HTTP_ALLOW для HTTP-sink’ов. Я прямо написал: следите за v1.1.0.

5 июля вышел v1.1.0. Перед ним — v1.0.3 (30 июня), который многие пролетели, потому что выглядел «техническим». Зря: там заложили то, что в 1.1.0 ударило по конфигам.

Если вы ещё не читали обзор v1.0.0 — там контекст: зачем DataSafeS3, кому подходит, честные минусы. Здесь только дельта после v1.0.2.

v1.0.3 — то, что кажется скучным, пока не прилетит pentest

30 июня мы выпустили v1.0.3. Без громких заголовков. Зато три вещи, которые потом всплывают в разговорах с админами.

Шифрование полей в метаданных (opt-in). Access keys, credentials для gateway, системные секреты в Postgres/Bolt можно хранить в envelope (enc:v1:). По умолчанию выключено. Community Edition, без license gate. Дамп метаданных украли — в нём не лежат ключи S3 открытым текстом. Миграция 012 на старте server, гайд EN/RU в репозитории.

Vault — но не SDK внутри storage-server. Мы сознательно не тащили HashiCorp SDK в бинарь. Vault Agent или Injector кладёт секреты в STORAGE_* env. У кого Vault уже крутится в k8s — привычный паттерн. Compose overlay и Helm example лежат в deploy/.

Панель Security в консоли. Admin → Settings → Security. Слабые env vars, статус field encryption. Раньше то же самое было только через API security-status — удобно для скрипта, неудобно для человека перед выкатом.

И главное для тех, кто апгрейдится сейчас: в v1.0.3 мы deprecated STORAGE_OUTBOUND_HTTP_ALLOW. В upgrade guide написали — в 1.1.0 переменная исчезнет. Я видел compose, где Loki на http://127.0.0.1:3100 висел в файле с названием production. Две недели на перевод sink’а на HTTPS или на dev-overlay с STORAGE_DEV=true. Не идеально, но лучше, чем выключить свет без предупреждения.

v1.1.0 — HTTP outbound и metrics

Исходящие URL

STORAGE_OUTBOUND_HTTP_ALLOW удалено.

Webhooks, Loki, Elasticsearch, «Test hook» в админке — в production только публичный HTTPS. HTTP и private IP — если STORAGE_DEV=true на в не-prod стеке.

После апгрейда логи перестали уходить? Посмотрите URL. Были предупреждения в статье про v1.0.2. Upgrade guide RU.

Prometheus

Задаёте STORAGE_METRICS_TOKEN — /metrics требует bearer. Пустой токен — старый открытый режим, но storage-server прям кричит в лог при старте в production-сценариях.

На review v1.0.2 мы оставили metrics «на потом». Потом наступило именно сейчас :). Обновите scrape config — пример в deploy/docker/prometheus.yml. Helm: storageServer.config.metricsToken. Консоль без bearer на дашборде покажет нули — это нормально, смотрите метрики в Grafana.

Share links

Токен публичной ссылки бакета отдаётся один раз при создании. Исключение связано с безопасностью данных.

Мониторинг в консоли — при metrics token Grafana/Prometheus ходят с bearer.

Teams и MFA

В прошлой статье Teams числились в списке «не в патче». В 1.1.0 — Admin → Teams: создание, участники, привязка пользователей. REST + UI, OpenAPI в full spec.

MFA wizard — пошаговый TOTP в профиле.

Security panel из v1.0.3 никуда не делась — перед релизом я сам туда заглядываю чаще, чем в другие разделы.

Тенанты — это изоляция подразделений. Teams — ещё один слой «кто с кем в одной команде/офисе».

Trusted clusters

Офис и DR. Два ЦОД. Lab Site A и Site B на ноутбуке. Нужно понять, что remote — ваш, и копировать объекты после PUT/DELETE. Опционально — federation с привязкой peer к кластеру.

Gateway replication (любой S3 по access key) и site replication по AK/SK на peer — были. Trusted clusters — другой путь: два DataSafeS3, которые вы явно спарили.

Pairing через mTLS и обмен CA. Join-токен dsjoin_* — 15 минут, одноразовый, в БД хеш. Client cert на 90 дней, rotator на leader обновляет заранее. Private keys на хранятся диске в cluster-certs/. В консоли — страница Кластеры и как правило «локальный bucket → remote bucket».

Самая частая ошибка на стенде, который я прогонял: STORAGE_CLUSTER_ENDPOINT=http://127.0.0.1:9002. Site B в Docker вас не видит. На Docker Desktop — host.docker.internal. Звучит банально но пока не потратишь вечер на «pairing failed» без логов на remote.

Это lab-уровень, не готовый DR. Backup cluster-certs/ — как backup TLS. Подробно: trusted clusters RU.

Gateway — репликация на внешний S3. Trusted clusters — между двумя DataSafeS3 после pairing.

HA v2 в том же теге

Erasure backend (STORAGE_OBJECT_BACKEND=erasure), Postgres leader lock, site replication в админке, скрипты в scripts/ha/. QA на релизе показал 112 PASS, HA lab(локально) прогон без FAIL.

Репозиторий для contrib

Параллельно с релизом: CONTRIBUTING.md, семь спек развертывания на PR, feature-audit 111+ проверок, примеры Go S3 SDK и Python admin script, образы :main на GHCR.

Звёзд на GitHub мало. Но мы за то, чтобы в opensoure было всё, что сейчас находится в лучших практиках.

Обновление

docker pull ghcr.io/direktorbani/datasafe-storage-server:v1.1.0docker pull ghcr.io/direktorbani/datasafe-console:v1.1.0

Пошагово: upgrade guide RU. Полный список: CHANGELOG.

Итог

v1.0.3 дал opt-in шифрование метаданных, Vault Agent pattern, Security panel — и время подготовиться к исчезновению HTTP hatch.

v1.1.0 hatch убрали, metrics закрыли bearer’ом, share links — hash-only, Teams в UI, trusted clusters и HA v2 lab(локально). Закрыли хвосты из статьи про v1.0.2.

DataSafeS3 всё ещё молодой open source. Цель та же: self-hosted S3, за который не стыдно администратору — не только автору.

Уязвимости — SECURITY.md.

• Обзор v1.0.0

• v1.0.1 и v1.0.2

• Release v1.1.0 на GitHub

---

Автор: Илья Трачук — разработчик DataSafeS3