Devin Connect

​

O que o Devin Connect faz

• Túnel reverso: o Gateway abre uma conexão de saída até um endpoint do lado do Devin via TLS, e o Devin envia as requisições de conexão de volta por esse túnel. Nada é aberto para entrada na sua rede, e nenhuma integração com provedor de nuvem é necessária.
• AWS PrivateLink: você coloca um Network Load Balancer e um VPC Endpoint Service na frente do Gateway, e a Cognition o consome com um Interface VPC Endpoint na VPC do seu dedicated tenant. O tráfego permanece no backbone da AWS e o Devin se conecta diretamente ao Gateway por IPs privados.

• VPC single-tenant dedicada. O seu Devin deployment roda na própria VPC (veja o modelo de deployment dedicado ao cliente). As VMs do Devin enviam o tráfego dos destinos roteados em direção ao Gateway por meio do controle de saída configurado pela Cognition.
• Negação por padrão, aplicada duas vezes. As rotas são aplicadas no Gateway e no lado do Devin, de modo que uma alteração apenas de configuração em um dos lados não amplia o acesso. Rotear um destino nunca amplia as permissões de uma sessão: o security profile da sessão ainda precisa permitir o acesso.
• O TLS da sua aplicação é ponta a ponta. O Gateway encaminha fluxos de bytes opacos.
• O DNS permanece dentro da sua rede. Os destinos das rotas são resolvidos pelos seus resolvedores (por padrão, o resolvedor de sistema do host do Gateway, ou nameservers que você configurar).
• Um único deployment cobre todos os destinos roteados. Você adiciona hostnames e intervalos IPv4 nas configurações do Devin, sem precisar montar uma estrutura específica para cada serviço.

​

Escolhendo um modo de conectividade

​

Configurar o Devin Connect

1. Escolha “Add gateway”, dê um nome a ele e selecione uma conexão: “Tunnel” para o túnel reverso ou “Direct” para o AWS PrivateLink. No caso de “Direct”, informe também o nome DNS e a porta do interface endpoint (consulte a aba AWS PrivateLink).
2. No cartão do gateway, escolha “Add destination” para cada destino que o Devin deve acessar por meio dele: um hostname exato ou um endereço IPv4 ou CIDR, como 10.20.0.0/16. Curingas não são suportados. Cada destino pode pertencer a apenas um gateway.
3. Para um gateway de túnel, escolha “Generate token” para inscrevê-lo. O token de inscrição é exibido uma única vez, nunca é armazenado pelo Devin e pode ser rotacionado ou revogado a qualquer momento com “Regenerate token”. Gateways diretos não têm túnel para autenticar, então esta etapa não se aplica a eles.
4. Para um gateway de túnel, copie o trecho de código de deployment da sua plataforma (Docker, Kubernetes, AWS ECS, Terraform em ECS ou EC2, ou um host Linux). O trecho de código contém um config.yaml pronto para execução, gerado a partir dos destinos do gateway; por isso, copie-o novamente sempre que alterar os destinos.

​

Destinos por hostname e IPv4

• Hostnames são correspondidos pelo nome ao qual a sessão se conecta, obtido do TLS SNI ou do header HTTP Host. Por isso, eles roteiam apenas tráfego TLS e HTTP simples. O Gateway resolve o nome usando o seu DNS.
• Endereços IPv4 e CIDRs são correspondidos pelo IP de destino da conexão e, portanto, roteiam qualquer protocolo TCP, incluindo conexões SSH e de banco de dados. O Devin não resolve seus nomes internos para essas rotas: as sessões se conectam por endereço IP, ou você fornece a resolução de nomes no ambiente, por exemplo, com entradas em /etc/hosts configuradas no seu blueprint.

​

Modos de conectividade

• Túnel reverso
• AWS PrivateLink

O Gateway abre N túneis TLS de saída até o endpoint do seu tenant, <customer>.gateway.devinenterprise.com:443. Você nunca abre uma porta de entrada. Um túnel registrado transporta apenas os fluxos que o lado do Devin abre em direção ao seu Gateway; ele não é um caminho de entrada para o Devin.A inscrição funciona assim:

1. O Devin emite para você um token de inscrição para o gateway do túnel na página de configurações “Devin Connect”.
2. Você instala o token no host do Gateway, no caminho indicado por tunnel.auth_token_file.
3. O Gateway se conecta a <customer>.gateway.devinenterprise.com:443, verifica o certificado de servidor da borda do Devin e apresenta o token.
4. A borda valida o token (comparação em tempo constante com um digest armazenado; o token bruto nunca é armazenado no lado do Devin) e registra o túnel. A partir daí, as conexões iniciadas pelo lado do Devin para os destinos do gateway passam por ele.

O túnel é configurado com uma seção tunnel e sem endereço listen, de modo que o host do Gateway não expõe nenhuma porta de proxy:

tunnel:
  endpoint: acme.gateway.devinenterprise.com:443
  gateway_id: gw-1
  # Token de inscrição, em uma única linha; é relido a cada tentativa de conexão,
  # para que possa ser rotacionado sem reiniciar o serviço.
  auth_token_file: /etc/devin-gateway/tunnel-token
  # carrier: websocket   # padrão; use `direct` para desativar o enquadramento WebSocket.
  # ca_file: corp-ca.pem # somente se um proxy corporativo de inspeção TLS reassinar
  #                      # a conexão de borda.
  # egress_proxy:        # proxy HTTP CONNECT de saída do cliente, se necessário.
  #   addr: proxy.corp.example:3128

Campo	Descrição
endpoint	O endpoint do seu tenant, <customer>.gateway.devinenterprise.com:443.
gateway_id	Identificador desta instância do Gateway, usado em logs e métricas.
auth_token_file	Caminho para o arquivo de uma linha com o token de inscrição.
carrier	websocket (padrão) ou direct. Ambos executam o mesmo protocolo dentro da mesma conexão TLS; o websocket adiciona enquadramento HTTP Upgrade para caminhos de saída que não permitem TLS puro.
ca_file	Pacote de CAs em PEM para verificar o certificado da borda do Devin; necessário apenas quando há um corporate TLS-inspection proxy que reassina certificados.
egress_proxy	Seu proxy HTTP CONNECT de saída (addr e, opcionalmente, auth), caso o tráfego de saída precise passar por um.
connection_pool	size (1 a 16 túneis, recarregável) e max_streams_per_connection (2 a 2048).

Itens adicionais de verificação para este modo:

• Libere a saída do Gateway para <customer>.gateway.devinenterprise.com:443 e para os serviços internos da sua lista de permissões. Não é necessário criar regras de entrada.
• Armazene o token de inscrição no seu gerenciador de secrets e monte-o como arquivo. Nunca o embuta em images, em configurações sob version control ou em logs; o Gateway nunca o registra em log.
• Opcionalmente, informe à Cognition suas faixas CIDR de saída para restringir o endpoint público no nível de IP (defesa em profundidade; o token de inscrição continua sendo o mecanismo de autenticação).

O Gateway disponibiliza o proxy de lista de permissões em um listener HTTP CONNECT local, e o Devin alcança esse listener via PrivateLink:

1. Você implanta o Gateway em uma sub-rede privada na sua AWS VPC com um endereço listen.
2. Você coloca um Network Load Balancer na frente dele apontando para a porta do listener e cria um VPC Endpoint Service a partir desse NLB.
3. Você adiciona a AWS account da Cognition como principal permitido e envia à Cognition o nome do endpoint service.
4. A Cognition cria um Interface VPC Endpoint na VPC do seu dedicated tenant e envia para você o nome DNS dele. Isso envia uma requisição de conexão ao seu endpoint service, que você aprova (ou que é aceita automaticamente, caso você tenha ativado essa opção no serviço).
5. Na página de configurações “Devin Connect”, você adiciona um gateway com a conexão “Direct”, informa o nome DNS do interface endpoint e a porta do listener e adiciona os destinos que ele deve atender. Coloque os mesmos destinos nas routes do Gateway.

Como o endpoint service só pode ser consumido pela account da Cognition e o NLB é interno à sua VPC, não existe listener público. O acesso é autorizado pelo principal da AWS no endpoint service e pela própria lista de permissões com negação por padrão do Gateway.A configuração do Gateway define listen com a porta para a qual o NLB direciona o tráfego:

schema_version: 1
admin_listen: 0.0.0.0:9090

# O listener HTTP CONNECT local para o qual o NLB direciona o tráfego.
listen: 0.0.0.0:8443

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

O que fornecer à Cognition:

• O nome do VPC Endpoint Service, por exemplo com.amazonaws.vpce.us-west-2.vpce-svc-0abc123.
• A porta do listener exposta pelo NLB.
• Confirmação de que a AWS account da Cognition é um principal permitido.
• Se o endpoint service oferece suporte à região em que o seu tenant do Devin é executado, caso ela seja diferente da região do Gateway.

Itens adicionais do checklist para esse modo:

• Execute os targets do NLB em várias Zonas de Disponibilidade.
• Se os seus serviços estiverem em uma região diferente da do seu tenant do Devin, ative o suporte entre regiões no endpoint service. As etapas são as mesmas descritas em Rede privada do Dedicated Deployment.

​

Referência de configuração

schema_version: 1

# listener de administração (/healthz, /readyz, /metrics).
admin_listen: 127.0.0.1:9090

# Listener do plano de dados. Somente no modo PrivateLink (direct): obrigatório sem
# uma seção `tunnel`, rejeitado quando há uma.
# listen: 0.0.0.0:8443

# DNS do cliente para resolver os destinos das rotas (resolver do sistema, se omitido).
dns:
  nameservers: ["10.0.0.2:53"]
  timeout: 5s

# Lista de permissões com negação por padrão. As Rules aceitam hostnames e CIDRs ipv4/ipv6.
# Portas omitidas significam qualquer porta.
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 de saída para a borda do lado do Devin. Omita no modo PrivateLink.
tunnel:
  endpoint: acme.gateway.devinenterprise.com:443
  gateway_id: gw-1
  auth_token_file: /etc/devin-gateway/tunnel-token

​

Rotas (lista de permissões)

​

Listeners

​

DNS

​

Executando o Gateway

gateway serve --config /etc/devin-gateway/config.yaml
gateway validate-config --config config.yaml   # validação estrita da config
gateway doctor --config config.yaml            # resumo de diagnóstico em JSON

• /healthz para liveness do processo.
• /readyz para prontidão.
• /metrics para métricas do Prometheus.

• Execute o Gateway em uma sub-rede privada.
• Integre /healthz e /readyz aos health checks do seu orquestrador.
• Mantenha os destinos de cada gateway nas configurações do Devin e as rotas na configuração do respectivo Gateway em sincronia; um destino permitido em apenas um dos lados não fica acessível.

​

Logging e integração com SIEM

• conn_open e conn_close, com host e porta de destino, nome da rota correspondente, endereço do cliente, bytes transferidos em cada direção e duração.
• deny, com o destino e o motivo (por exemplo, nenhuma rota correspondente na lista de permissões).