Как связать два self-hosted S3 без лишних костылей

Self-hosted S3-хранилище часто начинается как простой сервис для бэкапов, артефактов CI и внутренних файлов. Но как только появляется второй кластер, всё усложняется: нужно безопасно передавать данные между площадками, не открывать лишние endpoint’ы наружу и понимать, кому именно можно доверять.

DataSafeS3 v1.1.0 как раз двигается в эту сторону. Главная идея релиза — сделать пару независимых S3-кластеров не набором вручную связанных сервисов, а управляемой схемой с доверенными кластерами, mTLS и более строгими настройками доступа.

Зачем self-hosted S3 нужна модель доверия

В домашней лаборатории или небольшой инфраструктуре S3-совместимое хранилище обычно живёт рядом с MinIO, reverse proxy, backup-agent’ами, мониторингом и несколькими внутренними приложениями. Пока кластер один, модель безопасности относительно простая: есть пользователи, ключи доступа, политики bucket’ов и сетевые правила.

Проблемы начинаются при репликации или синхронизации между двумя инсталляциями. Например, один кластер стоит дома, второй — на VPS или в офисе. Нужно, чтобы они обменивались данными, но при этом не превращались в открытую поверхность атаки. Если связь держится на временных HTTP-обходах, ручных токенах или слишком широких firewall-правилах, такую схему трудно сопровождать и ещё труднее проверять.

Подход trusted clusters полезен тем, что доверие становится явной частью конфигурации. Кластер не просто «ходит по URL» к соседу, а работает с заранее определённым партнёром, для которого можно отдельно контролировать идентичность, сертификаты, доступные операции и границы взаимодействия.

Что даёт mTLS между кластерами

mTLS закрывает один из самых неприятных вопросов межкластерного обмена: как убедиться, что на другой стороне действительно ожидаемый сервис. Обычный TLS подтверждает сервер клиенту, но в инфраструктурных связках этого часто мало. При mutual TLS обе стороны предъявляют сертификаты, и соединение устанавливается только если проверка прошла взаимно.

Для S3-сценариев это особенно важно. Репликация, sink’и и внутренние сервисные вызовы работают с данными, которые обычно не должны проходить через публичный контур. mTLS позволяет строить связку, где компрометация одного URL или ошибка DNS-настройки не должна автоматически давать доступ к каналу обмена.

Практический плюс — такую схему проще документировать и аудитить. В runbook можно явно указать, какие сертификаты принадлежат каким кластерам, как выполняется ротация и какие действия нужны при выводе площадки из эксплуатации.

Уход от HTTP-костыля для sink’ов

В релизе v1.1.0 отдельно отмечено удаление HTTP-костыля для sink’ов. Для homelab и небольших команд это важнее, чем может показаться. Любой временный обходной путь в инфраструктуре со временем становится постоянным: его добавляют в firewall, заворачивают в proxy, забывают в docker-compose и начинают считать нормой.

Когда обмен между компонентами переводится на более строгую схему, уменьшается количество исключений. Меньше отдельных портов, меньше неочевидных переменных окружения, меньше мест, где после обновления может сломаться pairing. Это не только про безопасность, но и про эксплуатацию: чем меньше специальных условий, тем проще восстановить сервис после переезда, обновления Docker-сети или смены домена.

Метрики не должны быть публичной витриной

Ещё одно изменение — закрытие /metrics. Внутренние метрики часто недооценивают: кажется, что там нет пользовательских данных, значит endpoint безопасен. На практике Prometheus-метрики могут раскрывать версии, имена bucket’ов, внутренние ошибки, сетевые адреса, особенности нагрузки и косвенные признаки инцидентов.

Для self-hosted-сервисов хорошее правило простое: метрики должны быть доступны только мониторингу. Если Prometheus живёт в той же Docker-сети или Kubernetes-кластере, публичный доступ к /metrics обычно не нужен. Если сбор идёт с отдельной машины, лучше ограничить маршрут VPN, reverse proxy с auth или firewall-правилами.

Закрытый metrics-endpoint помогает избежать ситуации, когда сервис вроде бы защищён, но рядом торчит диагностический интерфейс, по которому можно собрать карту системы.

Teams в UI как шаг к нормальной эксплуатации

Появление Teams в интерфейсе — не только косметика. Даже в маленькой команде быстро возникает потребность отделить роли: кто управляет кластером, кто отвечает за резервные копии, кто имеет доступ к конкретным проектам, а кто только смотрит состояние.

Для homelab это тоже актуально. Один и тот же S3 может обслуживать семейный архив, CI-артефакты, staging-окружение и резервные копии рабочих станций. Когда доступы разложены по командам, меньше соблазна использовать один общий admin-key для всего подряд.

Важно, чтобы UI не подменял собой инфраструктурную дисциплину. Команды удобны для ежедневной работы, но ключи, политики и сертификаты всё равно стоит хранить и ротировать осознанно: через password manager, sealed secrets, age/sops или другой привычный механизм.

Pairing failed в Docker: где обычно искать причину

В контексте v1.0.3 упоминается типичный сценарий с ошибкой pairing failed на Docker. Такие проблемы чаще всего возникают не из-за «магии» приложения, а на стыке контейнерной сети, имён сервисов и публичных URL.

При разборе подобных ошибок полезно пройти короткий чеклист:

• совпадает ли URL, по которому один кластер обращается к другому, с тем адресом, который реально доступен из контейнера;
• не используется ли localhost там, где нужен service name из docker-compose;
• проброшены ли нужные порты только туда, куда действительно требуется;
• доверяет ли контейнер CA, которым подписан сертификат соседнего кластера;
• не ломает ли reverse proxy заголовки или TLS-терминацию;
• одинаково ли настроены время и DNS на обеих сторонах.

После перехода к trusted clusters и mTLS такие ошибки не исчезают полностью, но становятся более диагностируемыми. Если соединение не устанавливается, можно отдельно проверить сеть, сертификаты, доверенную конфигурацию и права конкретной связки.

Как аккуратно обновляться до v1.1.0

Для production-подобной установки обновление лучше делать как инфраструктурное изменение, а не как обычный docker compose pull && up -d. Минимальный безопасный план выглядит так:

1. Снять резервную копию конфигурации, ключей и данных, которые нужны для восстановления.
2. Зафиксировать текущую схему сетевых связей: какие endpoint’ы открыты, кто ходит к /metrics, какие sink’и настроены.
3. Подготовить сертификаты и доверенные пары кластеров, если планируется mTLS.
4. Обновить сначала тестовую или вторичную площадку.
5. Проверить pairing, репликацию, доступность bucket’ов и сбор метрик.
6. Убрать устаревшие HTTP-исключения и лишние firewall-правила.

Самый частый риск в таких миграциях — оставить старый обходной путь «на всякий случай». В итоге новая защищённая схема существует параллельно со старой открытой, и реальный уровень безопасности почти не меняется. После успешной проверки стоит отдельно пройтись по compose-файлам, reverse proxy и правилам доступа.

Итог

DataSafeS3 v1.1.0 выглядит как релиз про взросление self-hosted S3-инфраструктуры. Trusted clusters задают явную модель доверия между площадками, mTLS делает межкластерный обмен строже, закрытый /metrics уменьшает утечки диагностической информации, а Teams в UI помогает навести порядок в доступах.

Для homelab это хороший повод пересмотреть собственную схему: где хранилище доступно извне, как организована репликация, кто видит метрики и какие временные HTTP-решения давно пора удалить. Даже если кластер небольшой, такие настройки быстро окупаются, когда нужно обновить систему, восстановиться после сбоя или доказать самому себе, что данные не ездят по инфраструктуре «на доверии к сетке».