Permisos de red en Upferry: acceso a la base de datos sin acceso a Internet
Un servicio que utiliza PostgreSQL no siempre necesita conectarse al resto de Internet. Una herramienta interna, una aplicación de pruebas o una tarea programada puede necesitar una sola conexión: a su propia base de datos.
Ahora puedes expresar esa necesidad en los ajustes de Upferry. Activa el modo Restringido, selecciona un servicio y su puerto TCP y despliega. Las conexiones salientes nuevas quedan bloqueadas, salvo las conexiones internas que hayas permitido.
postgres:5432✓ PermitidoInternet× BloqueadoConserva las conexiones necesarias
Imagina una aplicación web con PostgreSQL. Debe atender a sus visitantes y consultar su base de datos, pero no necesita llamar a una API externa. Una política explícita permite aplicar ese requisito fuera del código de la aplicación.
En este ejemplo permites postgres:5432. Otro puerto, un servicio no seleccionado, un servicio de otro entorno y una dirección pública de Internet siguen sin estar disponibles. Usa el nombre interno, como postgres o postgres.upferry.internal, para la conexión permitida.
Actívalo en Settings
Abre el servicio en Upferry y ve a Settings → Permisos de red.
- Selecciona el modo Restringido.
- Marca el servicio interno y los puertos TCP necesarios. Para PostgreSQL suele ser postgres en el puerto 5432.
- Guarda y despliega. El formulario puede desplegar el entorno seleccionado inmediatamente después de guardar.
Una lista vacía bloquea todas las conexiones salientes nuevas. Los servicios existentes conservan el modo Abierto hasta que cambies y despliegues su política de forma explícita.
Guardar no significa aplicar
El panel muestra por separado la configuración guardada y la política del despliegue en ejecución. Guardar sin desplegar no modifica ese despliegue. Si la sustitución falla, la versión anterior sigue funcionando con su política anterior.
La configuración pertenece al servicio y se comparte entre sus entornos. Despliega cada entorno en ejecución para aplicar el cambio allí. El permiso solo alcanza al servicio seleccionado en el mismo entorno.
Si necesitas restricciones desde la primera ejecución del código, configura la política antes de desplegarlo. Crear un servicio con despliegue automático inicia ese primer despliegue en modo Abierto.
Las mismas reglas para tareas y reversiones
Los comandos pre-deploy reciben la misma política que la aplicación. Una migración puede conectarse a la base de datos permitida sin obtener una salida independiente a Internet.
Cron lee la configuración actual del propietario antes de cada nueva ejecución. Una tarea que ya está en curso conserva su política anterior. Revertir una imagen mantiene los permisos de red actuales del panel: una imagen antigua no restaura una política antigua más permisiva.
El permiso sigue la identidad del servicio seleccionado. Eliminarlo y crear otro con el mismo nombre no transfiere el acceso.
Revisa primero las dependencias externas
El modo Restringido también bloquea las API externas, los proveedores de correo y el DNS público. Si tu aplicación utiliza una API de pagos, Resend o Telegram, necesita esas conexiones y no funcionará sin cambios en este modo. Esta versión no incluye listas de dominios públicos permitidos.
Esta versión controla la aplicación en ejecución, cron y los comandos pre-deploy. La instalación de dependencias y la compilación de imágenes conservan su acceso habitual a la red. Se permiten conexiones TCP internas; UDP e IPv6 salientes quedan bloqueados.
Es una capa de protección. Un servicio permitido puede reenviar datos y una aplicación puede incluir datos sensibles en una respuesta web. Los permisos de red no impiden esas acciones ni protegen frente a un host comprometido.
Consulta los destinos bloqueados recientes
La misma sección de Settings muestra direcciones de destino, puertos, contadores de paquetes muestreados y una hora aproximada del último paquete. No registra el contenido de las solicitudes ni las credenciales.
Es una muestra limitada, no una auditoría completa de conexiones. Las entradas caducan tras diez minutos sin paquetes registrados. Una lista vacía no demuestra que no se haya bloqueado tráfico.
Ya disponible
Los permisos de red están activados en nuestra instalación de producción. Antes del lanzamiento comprobamos Linux en amd64, PostgreSQL, ambas rutas DNS, la recuperación tras reiniciar Docker, cron y pre-deploy. También verificamos el flujo completo con la API y el enrutamiento HTTPS de producción, incluida la reversión y la limpieza de recursos.
Empieza por un servicio cuyas conexiones conozcas. Permite únicamente los servicios internos y los puertos necesarios, despliega y comprueba que la aplicación siga funcionando como esperas.