Devin Connect

​

Cosa fa Devin Connect

• Tunnel inverso: il Gateway apre una connessione in uscita verso un endpoint sul lato Devin tramite TLS e Devin invia le richieste di connessione attraverso quel tunnel. Non viene aperto nulla in ingresso verso la tua rete e non è necessaria alcuna integrazione con il provider cloud.
• AWS PrivateLink: metti davanti al Gateway un Network Load Balancer e un VPC Endpoint Service, e Cognition lo utilizza tramite un Interface VPC Endpoint nella VPC del tuo dedicated tenant. Il traffico resta sulla backbone AWS e Devin contatta il Gateway direttamente tramite IP privati.

• VPC single-tenant dedicata. La tua distribuzione di Devin viene eseguita in una VPC dedicata (vedi il modello Customer Dedicated Deployment). Le VM di Devin inviano il traffico destinato alle tue destinazioni instradate verso il Gateway tramite il controllo dell’egress configurato da Cognition.
• Default-deny, applicato due volte. I percorsi vengono applicati sul Gateway e sul lato Devin, quindi una modifica alla sola configurazione su un lato non può ampliare l’accesso. Instradare una destinazione non amplia mai le autorizzazioni di una sessione: il security profile della sessione deve comunque consentirlo.
• Il TLS della tua applicazione è end-to-end. Il Gateway inoltra flussi di byte opachi.
• Il DNS resta all’interno della tua rete. Le destinazioni dei percorsi vengono risolte dai tuoi resolver (per default il resolver di sistema dell’host del Gateway, oppure i nameserver che configuri).
• Una sola distribuzione copre tutte le destinazioni instradate. Aggiungi hostname e intervalli IPv4 nei Settings di Devin invece di predisporre collegamenti dedicati per ogni servizio.

​

Scegliere una modalità di connettività

​

Configurare Devin Connect

1. Scegli “Add gateway”, assegnagli un nome e seleziona una connessione: “Tunnel” per il tunnel inverso oppure “Direct” per AWS PrivateLink. Per “Direct”, inserisci anche il nome DNS e la porta dell’interface endpoint (vedi la scheda AWS PrivateLink).
2. Nella card del gateway, scegli “Add destination” per ogni destinazione che Devin deve raggiungere tramite quel gateway: un hostname esatto, oppure un indirizzo IPv4 o un CIDR come 10.20.0.0/16. I caratteri jolly non sono supportati. Una destinazione può appartenere a un solo gateway.
3. Per un gateway a tunnel, scegli “Generate token” per registrarlo. L’enrollment token viene mostrato una sola volta, non viene mai memorizzato da Devin e può essere ruotato o revocato in qualsiasi momento con “Regenerate token”. I gateway diretti non hanno un tunnel da autenticare, quindi questo passaggio non è necessario.
4. Per un gateway a tunnel, copia lo snippet di distribuzione per la tua piattaforma (Docker, Kubernetes, AWS ECS, Terraform su ECS o EC2, oppure un host Linux). Lo snippet contiene un file config.yaml pronto per l’esecuzione, generato a partire dalle destinazioni del gateway: se le modifichi, copialo di nuovo.

​

Destinazioni hostname e IPv4

• Gli hostname vengono confrontati con il nome a cui si connette la sessione, ricavato dallo SNI TLS o dall’header HTTP Host. Per questo instradano solo traffico TLS e HTTP in chiaro. Il Gateway risolve il nome tramite il tuo DNS.
• Gli indirizzi IPv4 e i CIDR vengono confrontati con l’IP di destinazione della connessione, quindi instradano qualsiasi protocollo TCP, incluse le connessioni SSH e ai database. Per questi percorsi, Devin non risolve i tuoi nomi interni: le sessioni si connettono tramite indirizzo IP, oppure sei tu a fornire la risoluzione dei nomi nell’ambiente, ad esempio con voci in /etc/hosts configurate nel tuo blueprint.

​

Modalità di connettività

• Tunnel inverso
• AWS PrivateLink

Il Gateway apre N tunnel TLS in uscita verso il tuo tenant endpoint, <customer>.gateway.devinenterprise.com:443. Non devi mai aprire una porta in ingresso. Un tunnel registrato trasporta soltanto gli stream che il lato Devin apre verso il tuo Gateway; non costituisce un percorso in ingresso verso Devin.L’enrollment funziona così:

1. Devin ti rilascia un enrollment token per il gateway del tunnel dalla settings page “Devin Connect”.
2. Installi il token sull’host del Gateway nel percorso indicato da tunnel.auth_token_file.
3. Il Gateway contatta <customer>.gateway.devinenterprise.com:443, verifica il certificato server dell’edge di Devin e presenta il token.
4. L’edge convalida il token (confronto a tempo costante con un digest memorizzato; il token in chiaro non viene mai memorizzato sul lato Devin) e registra il tunnel. Le connessioni avviate dal lato Devin verso le destinazioni del gateway passano quindi attraverso di esso.

Il tunnel viene configurato con una sezione tunnel e senza indirizzo listen, in modo che l’host del Gateway non esponga alcuna porta proxy:

tunnel:
  endpoint: acme.gateway.devinenterprise.com:443
  gateway_id: gw-1
  # Enrollment token, su una sola riga; viene riletto a ogni tentativo di
  # connessione, così può essere ruotato senza riavviare.
  auth_token_file: /etc/devin-gateway/tunnel-token
  # carrier: websocket   # default; usa `direct` per disattivare il framing WebSocket.
  # ca_file: corp-ca.pem # solo se un proxy aziendale di ispezione TLS rifirma
  #                      # la connessione verso l'edge.
  # egress_proxy:        # proxy HTTP CONNECT in uscita del cliente, se necessario.
  #   addr: proxy.corp.example:3128

Campo	Descrizione
endpoint	Il tuo tenant endpoint, <customer>.gateway.devinenterprise.com:443.
gateway_id	Identificatore di questa istanza del Gateway, usato nei log e nelle metriche.
auth_token_file	Percorso del file contenente l’enrollment token su una sola riga.
carrier	websocket (default) o direct. Entrambi eseguono lo stesso identico protocollo all’interno della medesima connessione TLS; websocket aggiunge il framing HTTP Upgrade per i percorsi di egress che non lasciano passare il TLS raw.
ca_file	Bundle CA in formato PEM per verificare il certificato edge di Devin, necessario solo dietro un corporate TLS-inspection proxy che ri-firma i certificati.
egress_proxy	Il tuo proxy HTTP CONNECT di egress (addr, auth facoltativo), se il traffico in uscita deve necessariamente passare per un proxy.
connection_pool	size (1-16 tunnel, ricaricabile a caldo) e max_streams_per_connection (2-2048).

Voci aggiuntive della checklist per questa modalità:

• Consenti l’egress dal Gateway verso <customer>.gateway.devinenterprise.com:443 e verso i tuoi servizi interni in allowlist. Non è necessaria alcuna regola in ingresso.
• Conserva l’enrollment token nel tuo gestore di secret e montalo come file. Non includerlo mai nelle image, nella configurazione sotto controllo versione o nei log; il Gateway non lo registra mai.
• Facoltativamente, fornisci a Cognition i tuoi CIDR ranges di egress per limitare l’endpoint pubblico a livello di IP (difesa in profondità; l’enrollment token resta il punto di controllo dell’autenticazione).

Il Gateway espone il proxy con allowlist su un listener HTTP CONNECT locale e Devin raggiunge quel listener tramite PrivateLink:

1. Distribuisci il Gateway in una subnet privata della tua AWS VPC con un indirizzo listen.
2. Posizioni un Network Load Balancer davanti al Gateway, puntandolo alla porta del listener, e crei un VPC Endpoint Service a partire da quell’NLB.
3. Aggiungi l’AWS account di Cognition come allowed principal e invii a Cognition il nome dell’endpoint service.
4. Cognition crea un Interface VPC Endpoint nella VPC del tuo dedicated tenant e ti invia il relativo nome DNS. Questo invia una richiesta di connessione al tuo endpoint service, che approvi (oppure che viene accettata automaticamente, se hai abilitato tale opzione sul servizio).
5. Nella pagina Settings “Devin Connect”, aggiungi un gateway con la connessione “Direct”, inserisci il nome DNS dell’interface endpoint e la porta del listener, quindi aggiungi le destinazioni che il gateway deve gestire. Inserisci le stesse destinazioni nelle routes del Gateway.

Poiché l’endpoint service è utilizzabile soltanto dall’account di Cognition e l’NLB è interno alla tua VPC, non esiste alcun listener pubblico. L’accesso è autorizzato dal principal AWS sull’endpoint service e dall’allowlist default-deny del Gateway stesso.La configurazione del Gateway imposta listen sulla porta a cui punta l’NLB:

schema_version: 1
admin_listen: 0.0.0.0:9090

# Il listener HTTP CONNECT locale a cui punta l'NLB.
listen: 0.0.0.0:8443

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

Cosa fornire a Cognition:

• Il nome del VPC Endpoint Service, ad esempio com.amazonaws.vpce.us-west-2.vpce-svc-0abc123.
• La porta del listener esposta dall’NLB.
• La conferma che l’AWS account di Cognition sia un allowed principal.
• Se l’endpoint service supporta la regione in cui viene eseguito il tuo tenant Devin, nel caso differisca dalla regione del Gateway.

Voci aggiuntive della checklist per questa modalità:

• Esegui i target dell’NLB in più zone di disponibilità.
• Se i tuoi servizi si trovano in una regione diversa da quella del tuo tenant Devin, abilita il supporto cross-region sull’endpoint service. I passaggi sono gli stessi descritti in Rete privata per la distribuzione dedicata.

​

Riferimento della configurazione

schema_version: 1

# Listener di amministrazione (/healthz, /readyz, /metrics).
admin_listen: 127.0.0.1:9090

# Listener del piano dati. Solo in modalità PrivateLink (direct): obbligatorio
# in assenza di una sezione `tunnel`, rifiutato se presente.
# listen: 0.0.0.0:8443

# DNS del cliente per risolvere le destinazioni dei percorsi (se omesso, si usa il resolver di sistema).
dns:
  nameservers: ["10.0.0.2:53"]
  timeout: 5s

# Allowlist con deny predefinito. Le regole accettano hostname e CIDR ipv4/ipv6.
# Se le porte sono omesse, vale qualsiasi 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]

# Tunnel in uscita verso l'edge lato Devin. Da omettere in modalità PrivateLink.
tunnel:
  endpoint: acme.gateway.devinenterprise.com:443
  gateway_id: gw-1
  auth_token_file: /etc/devin-gateway/tunnel-token

​

Percorsi (allowlist)

​

Listeners

​

DNS

​

Esecuzione del Gateway

gateway serve --config /etc/devin-gateway/config.yaml
gateway validate-config --config config.yaml   # convalida rigorosa della configurazione
gateway doctor --config config.yaml            # riepilogo diagnostico in JSON

• /healthz per la liveness del processo.
• /readyz per la readiness.
• /metrics per le metriche Prometheus.

• Esegui il Gateway in una subnet privata.
• Collega /healthz e /readyz agli health check del tuo orchestrator.
• Mantieni sincronizzate le destinazioni di ciascun gateway nelle impostazioni di Devin e i percorsi nella relativa configurazione del Gateway; una destinazione consentita su un solo lato non è raggiungibile.

​

Logging e integrazione SIEM

• conn_open e conn_close, con host e porta di destinazione, nome della route corrispondente, indirizzo del client, byte trasferiti in ciascuna direzione e durata.
• deny, con destinazione e motivo (ad esempio, nessuna route dell’allowlist corrispondente).