Secure Links

Los Secure Links conectan recursos compatibles gestionados por Opfield sin convertir el destino en un endpoint público de uso general.

El término abarca una conectividad privada de alcance limitado con una propiedad duradera en Opfield. No implica que todas las rutas privadas usen el mismo componente de ejecución. Los enlaces a upstreams de ingress y las vinculaciones de bases de datos gestionadas tienen propietarios, credenciales, registros de ciclo de vida y señales de diagnóstico distintos.

Requisitos previos y límite de confianza

Ambos extremos deben ser recursos compatibles gestionados por Opfield con identidades estables, y sus nodos propietarios deben estar en línea con capacidades compatibles. Relay debe estar en buen estado y ser accesible desde los nodos participantes. Quien hace la llamada necesita permiso para leer el recurso de destino y modificar el recurso propietario de la relación.

Selecciona el servicio o el puerto de la aplicación en el que realmente escucha el proceso. No hace falta un puerto publicado en el host solo para crear un enlace privado, y abrir uno no repara una ruta privada fallida. Opfield no crea reglas de cortafuegos en el host ni hace accesibles redes arbitrarias.

Vinculaciones de bases de datos

Una vinculación de base de datos gestionada conecta un Container, un Deployment o un servicio de Compose compatibles con una base de datos gestionada. Opfield crea un usuario o rol del motor separado para la vinculación y concede solo los permisos de base de datos necesarios. Entrega a la carga de trabajo el material de conexión específico de la vinculación; la credencial de propietario de la base de datos no se expone.

La carga de trabajo llega a la base de datos a través del conector de Secure Links compartido de su nodo Docker, en una pequeña red privada propia para la vinculación. No hay un Container conector por vinculación ni un listener en el host que reiniciar, inspeccionar o sustituir. El enlace y la identidad del motor son registros separados pero coordinados, de modo que la rotación de credenciales, el cambio de permisos o la eliminación de una carga de trabajo no alteran silenciosamente otra vinculación.

Recrear la carga de trabajo mantiene disponible la vinculación, porque la autorización sigue la identidad estable del recurso de Opfield y no un ID de Container transitorio. Opfield concilia el enlace y vuelve a inyectar los ajustes de conexión actuales. Eliminar la vinculación elimina el enlace y retira su identidad del motor mediante un único ciclo de vida registrado; el camino normal no debe dejar roles ni usuarios huérfanos.

Ante una vinculación de base de datos fallida, comprueba la base de datos gestionada y el nodo Storage, después el nodo Docker de destino y la carga de trabajo, el estado deseado de la vinculación, el conector de Secure Links del nodo, la identidad del motor y sus permisos y, por último, la configuración de la aplicación. No elimines a mano el rol, la red de enlace ni el conector como paso genérico de reparación. Eso puede convertir una discrepancia recuperable en una identidad huérfana o en un fallo de conciliación futuro.

Container links

Un container link da a un Container, un Deployment o un servicio de Compose acceso privado a un puerto de otra carga de trabajo, en el mismo nodo o en otro. El consumidor llega al destino como alias:port; el destino no necesita ningún puerto publicado, y el enlace abre solo ese puerto, en una sola dirección. Los enlaces dentro de un nodo se quedan en ese nodo; los enlaces entre nodos viajan a través del Relay.

Conector compartido y redes de enlace

Desde la 2.11.1, cada nodo Docker ejecuta un único conector de Secure Links compartido para todas sus vinculaciones de bases de datos, enlaces de almacenamiento y container links. No hay contenedores conectores por enlace ni listeners en el host. Cada enlace recibe una pequeña red privada propia, a la que se une el consumidor; el conector responde allí al alias del enlace.

Las redes de enlace nuevas toman sus direcciones de un rango dedicado, 10.213.x.x (un /16) por defecto, un /26 por enlace, de modo que los enlaces nunca agotan los pools de direcciones que Docker asigna a tus propias redes. Las redes creadas antes de la 2.11.1 conservan sus direcciones. El daemon omite las subredes que ya usan las redes Docker o las propias rutas del host. Si el rango se solapa con una red a la que el nodo llega a través de su ruta predeterminada, como una red de la sede o una VPN detrás de un router, fija otro rango IPv4 de /26 o mayor en el archivo de configuración del daemon de Docker, /etc/docker-daemon/config.yaml:

docker:
  secure_links:
    subnet_pool: "<IPv4 range in CIDR notation>"

Reinicia el daemon de Docker tras el cambio. Solo las redes de enlace nuevas usan el nuevo rango; las existentes conservan el suyo hasta que se recrea su enlace.

Cuando se actualiza el propio conector, el conector anterior entrega sus conexiones abiertas al nuevo, que las mantiene sin reconexión. Un conector anterior a la 2.11.4 no puede entregarlas: las conserva hasta una hora y después las cierra una vez, y una tercera actualización dentro de esa hora cierra de inmediato las conexiones del conector más antiguo.

Enlaces a upstreams de ingress

Las Routes y las Additional Routes pueden apuntar a recursos Docker compatibles a través de un Secure Link. Opfield valida el recurso y el puerto de aplicación seleccionados, crea la relación y concilia un conector propiedad de Opfield a través de Relay. El conector que se usa para el tráfico de nginx a la carga de trabajo es un componente de ejecución real, pero queda fuera de las API ordinarias de ciclo de vida de los usuarios.

Un enlace creado por una Route gestionada pertenece a esa Route. Es visible para el diagnóstico, pero no se puede eliminar por separado; desactivar la Route conserva su configuración y su relación, mientras que eliminar la Route retira, tras la conciliación, la vinculación que le pertenece. Reiniciar o recrear la carga de trabajo mantiene el enlace, porque la Route apunta al recurso estable de Opfield. La promoción de un Deployment y los cambios de revisión de Compose resuelven el entorno de ejecución activo detrás de la misma identidad de nivel superior.

En la 2.11, los listeners de Secure Link de un nodo Ingress siguen aceptando conexiones bajo carga. Antes, desde la 2.10.0, el daemon de nginx comprobaba cada conexión nueva con un volcado completo de la configuración de nginx, de modo que un nodo Ingress se atascaba por encima de unas 100 conexiones nuevas de Secure Link por segundo y seguía fallando peticiones mucho después de que bajara la carga. Ahora la comprobación usa información de procesos en caché: un nodo Ingress de un solo núcleo gestiona miles de conexiones nuevas por segundo, las conexiones por encima de 1024 en establecimiento se rechazan de inmediato para que nginx conmute rápidamente en lugar de encolarlas, las conexiones que un cliente ya abandonó se descartan sin abrir un túnel, y el listener se recupera en cuanto baja la carga. Un error transitorio al aceptar, como quedarse sin descriptores de archivo, ya no detiene un listener hasta que se reinicia el daemon.

Las configuraciones avanzadas de nginx pueden usar vinculaciones adicionales gestionadas por separado con su propio ciclo de vida. No las confundas con las vinculaciones propiedad de una Route. Antes de eliminar una vinculación gestionada por el usuario, identifica todas las configuraciones que hacen referencia a ella.

Flujo normal y verificación

Para un upstream de ingress, elige el destino gestionado en el editor de la Route o de la Additional Route, selecciona el servicio o el puerto de la aplicación y el protocolo, guarda y espera tanto a la conciliación del Secure Link como a la validación de la configuración de nginx. Después verifica la identidad del destino, el estado del conector, el estado de la Route y una petición externa real.

Para una base de datos gestionada, crea la vinculación desde la carga de trabajo y la base de datos compatibles, elige un acceso con el mínimo privilegio, espera a la identidad del motor y al enlace, aplica la configuración de la carga de trabajo cuando sea necesario y ejecuta una consulta real de la aplicación. Confirma la telemetría de la vinculación y los logs tanto de la carga de trabajo como de la base de datos.

La verificación debe demostrar la ruta prevista, no solo la existencia de un registro. Para Ingress, inspecciona la disponibilidad de Relay, las conexiones de ambos nodos, la latencia de establecimiento, los flujos activos, el caudal, el estado de finalización, los rechazos de admisión, los logs de nginx y el comportamiento de la aplicación. Para las vinculaciones de bases de datos, inspecciona la preparación de la base de datos, la conciliación del enlace, el estado del principal del motor, la conectividad de la aplicación y la configuración actual de la carga de trabajo.

Lo que no hacen los Secure Links

• No son una VPN ni una red superpuesta de uso general.
• No proporcionan reenvío arbitrario de TCP ni de SSH.
• No abren automáticamente los cortafuegos de los hosts.
• No eliminan la necesidad de autenticación a nivel de aplicación cuando el protocolo de destino la requiere.

Tampoco transfieren la propiedad del recurso de destino, no hacen portables las cargas de trabajo no compatibles ni autorizan a un usuario que no tiene acceso a alguno de los dos lados. Un Secure Link no es motivo para exponer las interfaces de control de los daemons, los puertos de propietario de las bases de datos ni las credenciales internas de los conectores.

Fallos y recuperación segura

Si una Route de ingress se guarda pero el tráfico falla, comprueba que la Route está activada y su estado de mantenimiento, la revisión de nginx, Relay, la conectividad de los nodos Ingress y Docker, el entorno de ejecución y el puerto del destino, la admisión del conector y, después, los logs de la aplicación y el comportamiento del protocolo. No publiques un puerto interno de la carga de trabajo como solución provisional sin documentar.

Si se produce una interrupción de un nodo o de Relay, restablece la conectividad y espera a una conciliación nueva de capacidades y del estado deseado antes de sustituir identidades. Conserva el historial de operaciones y los ID de petición. Si una eliminación se interrumpe, conserva el registro duradero del propietario o de la vinculación para que Opfield pueda completar la limpieza. La eliminación manual de conectores, redes o principales del motor propiedad de Opfield es una acción de recuperación excepcional que requiere un procedimiento coordinado, no una primera respuesta.