Сетевые разрешения в Upferry: доступ к базе без доступа в интернет

Оставьте сервису нужные подключения

Представим веб-приложение с PostgreSQL. Оно должно обслуживать посетителей и читать свою базу, но обращаться к внешним API ему незачем. Явная сетевая политика позволяет применить это правило вне кода приложения.

В этом примере вы разрешаете postgres:5432. Другой порт, невыбранный сервис, сервис в другом окружении и публичный адрес в интернете остаются недоступными. Для разрешённого подключения используйте внутреннее имя, например postgres или postgres.upferry.internal.

Включите ограничение в Settings

Откройте сервис в Upferry и перейдите в Settings → Сетевые разрешения.

1. Выберите режим «Ограничен».
2. Отметьте внутренний сервис и TCP-порты, к которым нужен доступ. Для PostgreSQL это обычно postgres и порт 5432.
3. Сохраните настройку и выполните деплой. Форма позволяет сразу запустить деплой выбранного окружения.

Пустой список запрещает все новые исходящие соединения. Существующие сервисы остаются в открытом режиме, пока вы явно не измените политику и не выполните деплой.

Сохранённая настройка и действующая политика

Панель отдельно показывает сохранённый режим и политику работающего деплоя. Сохранение без деплоя не меняет запущенное приложение. Если замена не удалась, предыдущая версия продолжает работать со своей прежней политикой.

Настройка общая для сервиса во всех его окружениях. Чтобы применить изменение, выполните деплой в каждом работающем окружении. Разрешённое подключение ведёт только к выбранному сервису в том же окружении.

Если ограничение нужно с самого первого выполнения кода, задайте политику до его запуска. При создании сервиса с автодеплоем первый запуск происходит в открытом режиме.

Те же правила для задач и откатов

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

Cron читает текущую настройку владельца перед каждым новым запуском. Уже выполняющаяся задача сохраняет прежнюю политику. При откате образа остаются текущие сетевые разрешения из панели: старый образ не возвращает старую, более свободную политику.

Разрешение привязано к выбранному сервису, а не к имени, которое можно занять повторно. Удаление сервиса и создание другого с тем же именем не переносит доступ.

Сначала проверьте внешние зависимости

Режим «Ограничен» закрывает и внешние API, и почтовых провайдеров, и публичный DNS. Если приложение обращается к платёжному API, Resend или Telegram, эти подключения ему нужны и без изменений оно в таком режиме работать не сможет. Разрешения для внешних доменов в эту версию не входят.

В этой версии политика действует для работающего приложения, cron и команд перед деплоем. Установка зависимостей и сборка образа сохраняют обычный доступ к сети. Разрешаются внутренние TCP-подключения; исходящие UDP и IPv6 заблокированы.

Это один из уровней защиты. Разрешённый сервис может переслать данные дальше, а приложение может включить чувствительные данные в ответ на входящий запрос. Сетевые разрешения не предотвращают эти действия и не защищают от компрометации хоста.

Посмотрите недавние блокировки

В том же разделе Settings видны выборочные адреса назначения, порты, счётчики пакетов и приблизительное время последнего пакета. Содержимое запросов и учётные данные не записываются.

Это ограниченная выборка, а не полный аудит соединений. Запись удаляется после десяти минут без учтённых пакетов. Пустой список не доказывает, что попыток заблокированного доступа не было.

Уже доступно

Сетевые разрешения включены на нашей production-установке. Перед выпуском мы проверили Linux на amd64, подключения к PostgreSQL, оба пути DNS, восстановление после перезапуска Docker, cron и команды перед деплоем. Затем прошли полный сценарий через боевой API и HTTPS-маршрутизацию, включая откат и удаление ресурсов.

Начните с сервиса, чьи подключения вам понятны. Оставьте только необходимые внутренние сервисы и порты, выполните деплой и проверьте, что приложение работает как ожидается.