Devin Connect

​

Qué hace Devin Connect

• Túnel inverso: el Gateway establece una conexión de salida hacia un endpoint del lado de Devin sobre TLS y Devin envía las solicitudes de conexión de vuelta por ese túnel. No se abre nada de entrada hacia tu red ni se necesita ninguna integración con el proveedor de nube.
• AWS PrivateLink: colocas el Gateway detrás de un Network Load Balancer y un VPC Endpoint Service, y Cognition lo consume con un Interface VPC Endpoint en la VPC de tu dedicated tenant. El tráfico permanece en la red troncal de AWS y Devin se conecta directamente al Gateway mediante IP privadas.

• VPC single-tenant dedicada. Tu despliegue de Devin se ejecuta en su propia VPC (consulta el modelo de Despliegue Dedicado para el Cliente). Las VM de Devin envían el tráfico de tus destinos enrutados hacia el Gateway mediante el control de salida configurado por Cognition.
• Denegación predeterminada, aplicada dos veces. Las routes se aplican en el Gateway y en el lado de Devin, de modo que un cambio de configuración en un solo lado no puede ampliar el acceso. Enrutar un destino nunca amplía los permisos de una sesión: el security profile de la sesión igualmente tiene que permitirlo.
• El TLS de tu aplicación es de extremo a extremo. El Gateway reenvía flujos de bytes opacos.
• El DNS permanece dentro de tu red. Los destinos de las routes se resuelven con tus resolvers (de forma predeterminada, el resolver del sistema del host del Gateway, o los servidores de nombres que configures).
• Un solo despliegue cubre todos los destinos enrutados. Basta con agregar nombres de host y rangos IPv4 en los Settings de Devin en lugar de montar una infraestructura específica para cada servicio.

​

Elegir un modo de conectividad

​

Configurar Devin Connect

1. Elige “Add gateway”, asígnale un nombre y selecciona un tipo de conexión: “Tunnel” para el túnel inverso o “Direct” para AWS PrivateLink. Si eliges “Direct”, introduce también el nombre DNS y el puerto del Interface Endpoint (consulta la pestaña AWS PrivateLink).
2. En la card del gateway, elige “Add destination” para cada destino al que Devin deba acceder a través de él: un nombre de host exacto, o una dirección IPv4 o un CIDR como 10.20.0.0/16. No se admiten comodines. Cada destino solo puede pertenecer a un gateway.
3. En los gateways de túnel, elige “Generate token” para registrarlo. El token de inscripción se muestra una sola vez, Devin nunca lo almacena y puedes rotarlo o revocarlo en cualquier momento con “Regenerate token”. Los gateways directos no tienen ningún túnel que autenticar, por lo que este paso no se aplica.
4. En los gateways de túnel, copia el fragmento de despliegue correspondiente a tu plataforma (Docker, Kubernetes, AWS ECS, Terraform en ECS o EC2, o un host Linux). El fragmento incluye un config.yaml listo para ejecutar, generado a partir de los destinos del gateway, así que vuelve a copiarlo cada vez que los modifiques.

​

Destinos de nombre de host e IPv4

• Los nombres de host se comparan con el nombre al que se conecta la sesión, que se obtiene del SNI de TLS o del encabezado HTTP Host. Por eso, solo routean tráfico TLS y HTTP sin cifrar. El Gateway resuelve el nombre con tu DNS.
• Las direcciones IPv4 y los CIDR se comparan con la IP de destino de la conexión, por lo que routean cualquier protocolo TCP, incluidas las conexiones SSH y a bases de datos. Devin no resuelve tus nombres internos para estas routes: las sesiones se conectan por dirección IP, o bien tú proporcionas la resolución de nombres en el entorno; por ejemplo, mediante entradas en /etc/hosts configuradas en tu blueprint.

​

Modos de conectividad

• Túnel inverso
• AWS PrivateLink

El Gateway establece N túneles TLS salientes hacia tu tenant endpoint, <customer>.gateway.devinenterprise.com:443. Nunca abres un puerto entrante. Un túnel registrado solo transporta los flujos que el lado de Devin abre hacia tu Gateway; no constituye una vía de entrada hacia Devin.El registro funciona así:

1. Devin te emite un enrollment token para el gateway del túnel desde la settings page “Devin Connect”.
2. Instalas el token en el host del Gateway, en la ruta a la que apunta tunnel.auth_token_file.
3. El Gateway se conecta a <customer>.gateway.devinenterprise.com:443, verifica el certificado de servidor del borde de Devin y presenta el token.
4. El borde valida el token (comparación en tiempo constante contra un resumen almacenado; el token en bruto nunca se almacena del lado de Devin) y registra el túnel. A partir de ese momento, las conexiones que Devin inicia hacia los destinos del gateway circulan por él.

El túnel se configura con una sección tunnel y sin dirección listen, de modo que el host del Gateway no expone ningún puerto de proxy:

tunnel:
  endpoint: acme.gateway.devinenterprise.com:443
  gateway_id: gw-1
  # Enrollment token, en una sola línea; se vuelve a leer en cada intento de
  # conexión, por lo que puede rotarse sin reiniciar.
  auth_token_file: /etc/devin-gateway/tunnel-token
  # carrier: websocket   # predeterminado; use `direct` para desactivar el framing WebSocket.
  # ca_file: corp-ca.pem # solo si un proxy corporativo de inspección TLS vuelve a firmar
  #                      # la conexión con el edge.
  # egress_proxy:        # proxy HTTP CONNECT de salida del cliente, si es necesario.
  #   addr: proxy.corp.example:3128

Campo	Descripción
endpoint	Tu tenant endpoint, <customer>.gateway.devinenterprise.com:443.
gateway_id	Identificador de esta instancia de Gateway, usado en los logs y las metrics.
auth_token_file	Ruta al archivo de una sola línea con el enrollment token.
carrier	websocket (predeterminado) o direct. Ambos ejecutan el mismo protocolo dentro de la misma conexión TLS; websocket añade encuadre HTTP Upgrade para rutas de salida que no admiten TLS sin procesar.
ca_file	Paquete PEM de CA para verificar el certificado del edge de Devin; solo se necesita detrás de un corporate TLS-inspection proxy que vuelve a firmar los certificados.
egress_proxy	Tu proxy HTTP CONNECT de salida (addr, auth opcional), si el tráfico saliente debe pasar por uno.
connection_pool	size (1-16 túneles, recargable) y max_streams_per_connection (2-2048).

Elementos adicionales de la lista de verificación para este modo:

• Permite la salida desde el Gateway hacia <customer>.gateway.devinenterprise.com:443 y hacia tus servicios internos incluidos en la allowlist. No se necesitan reglas de entrada.
• Guarda el enrollment token en tu gestor de secrets y móntalo como archivo. Nunca lo incluyas en images, en configuración bajo control de versiones ni en logs; el Gateway nunca lo registra.
• Opcionalmente, proporciona a Cognition tus CIDR ranges de salida para restringir el endpoint público a nivel de IP (defensa en profundidad; el enrollment token sigue siendo la barrera de autenticación).

El Gateway expone el proxy de allowlist en un listener local HTTP CONNECT, y Devin accede a ese listener a través de PrivateLink:

1. Despliegas el Gateway en una subred privada de tu VPC de AWS con una dirección listen.
2. Colocas un Network Load Balancer delante de él apuntando al puerto del listener y creas un VPC Endpoint Service a partir de ese NLB.
3. Agregas la AWS account de Cognition como principal permitido y envías a Cognition el nombre del endpoint service.
4. Cognition crea un Interface VPC Endpoint en la VPC de tu tenant dedicado y te envía su nombre DNS. Esto envía una solicitud de conexión a tu endpoint service, que tú apruebas (o se acepta automáticamente, si habilitaste esa opción en el servicio).
5. En la settings page de “Devin Connect”, agregas un gateway con la conexión “Direct”, introduces el nombre DNS del interface endpoint y el puerto del listener, y agregas los destinos que debe atender. Incluye los mismos destinos en las routes del Gateway.

Como el endpoint service solo puede consumirlo la cuenta de Cognition y el NLB es interno a tu VPC, no existe ningún listener público. El acceso se autoriza mediante el principal de AWS en el endpoint service y mediante la propia allowlist de denegación predeterminada del Gateway.La configuración del Gateway establece listen en el puerto al que apunta el NLB:

schema_version: 1
admin_listen: 0.0.0.0:9090

# El listener HTTP CONNECT local al que apunta el NLB.
listen: 0.0.0.0:8443

routes:
  - name: devin
    rules:
      - hostname: "git.corp.example"
      - hostname: "api.corp.example"
    ports: [443]

Qué debes proporcionar a Cognition:

• El nombre del VPC Endpoint Service, por ejemplo com.amazonaws.vpce.us-west-2.vpce-svc-0abc123.
• El puerto de escucha que expone el NLB.
• La confirmación de que la cuenta de AWS de Cognition es un principal permitido.
• Si el endpoint service admite la región en la que se ejecuta tu tenant de Devin, en caso de que sea distinta de la región del Gateway.

Elementos adicionales de la lista de verificación para este modo:

• Ejecuta los destinos del NLB en múltiples zonas de disponibilidad.
• Si tus servicios están en una región distinta a la de tu tenant de Devin, habilita la compatibilidad entre regiones en el endpoint service. Los pasos son los mismos que en Redes privadas del despliegue dedicado.

​

Referencia de configuración

schema_version: 1

# Listener de Admin (/healthz, /readyz, /metrics).
admin_listen: 127.0.0.1:9090

# Listener del plano de datos. Solo en modo PrivateLink (direct): obligatorio si no
# hay una sección `tunnel`, y se rechaza si la hay.
# listen: 0.0.0.0:8443

# DNS del cliente para resolver los destinos de las routes (resolver del sistema si se omite).
dns:
  nameservers: ["10.0.0.2:53"]
  timeout: 5s

# Allowlist con denegación predeterminada. Las Rules aceptan nombres de host y CIDR ipv4/ipv6.
# Si se omiten los puertos, se permite cualquier puerto.
routes:
  - name: scm
    rules:
      - hostname: "git.corp.example"
      - hostname: "artifacts.corp.example"
    ports: [443]
  - name: internal-api
    rules:
      - hostname: "api.corp.example"
    ports: [443]
  - name: build-hosts
    rules:
      - ipv4: "10.20.0.0/16"
    ports: [22]

# Túnel saliente hacia el edge del lado de Devin. Omítelo en modo PrivateLink.
tunnel:
  endpoint: acme.gateway.devinenterprise.com:443
  gateway_id: gw-1
  auth_token_file: /etc/devin-gateway/tunnel-token

​

Routes (allowlist)

​

Listeners

​

DNS

​

Ejecutar el gateway

gateway serve --config /etc/devin-gateway/config.yaml
gateway validate-config --config config.yaml   # validación estricta de la config
gateway doctor --config config.yaml            # resumen de diagnóstico en JSON

• /healthz para la actividad del proceso.
• /readyz para la disponibilidad.
• /metrics para las métricas de Prometheus.

• Ejecuta el Gateway en una subred privada.
• Integra /healthz y /readyz en los health checks de tu orquestador.
• Mantén sincronizados los destinos de cada gateway en los Settings de Devin y las routes en su config del Gateway; un destino permitido en solo uno de los lados no es accesible.

​

Registro e integración con SIEM

• conn_open y conn_close, con host y puerto de destino, nombre de la ruta coincidente, dirección del cliente, bytes transferidos en cada dirección y duración.
• deny, con el destino y el motivo (por ejemplo, ninguna ruta de la allowlist coincidente).