Devin Connect

​

Rôle de Devin Connect

• Tunnel inverse : le Gateway ouvre une connexion sortante vers un endpoint côté Devin via TLS, et Devin renvoie les demandes de connexion par ce tunnel. Aucun flux entrant n’est ouvert vers votre réseau, et aucune intégration avec un fournisseur cloud n’est nécessaire.
• AWS PrivateLink : vous placez un Network Load Balancer et un VPC Endpoint Service devant le Gateway, et Cognition le consomme au moyen d’un Interface VPC Endpoint dans le VPC de votre dedicated tenant. Le trafic reste sur le backbone AWS et Devin se connecte directement au Gateway via des IP privées.

• VPC mono-locataire dédié. Votre Devin déploiement s’exécute dans son propre VPC (voir le modèle Customer Dedicated Deployment). Les VM Devin acheminent le trafic destiné à vos destinations routées vers le Gateway via un contrôle de sortie configuré par Cognition.
• Refus par défaut, appliqué à deux niveaux. Les routes sont appliquées sur le Gateway et côté Devin : une modification de configuration d’un seul côté ne peut donc pas élargir les accès. Router une destination n’élargit jamais les autorisations d’une session : le security profile de la session doit toujours l’autoriser.
• Le TLS de votre application est de bout en bout. Le Gateway se contente de transmettre des flux d’octets opaques.
• Le DNS reste dans votre réseau. Les cibles des routes sont résolues par vos resolvers (par défaut le résolveur système de l’hôte du Gateway, ou les nameservers que vous configurez).
• Un seul déploiement couvre toutes les destinations routées. Vous ajoutez les hostnames et les plages IPv4 dans les Settings de Devin plutôt que de mettre en place une tuyauterie propre à chaque service.

​

Choisir un mode de connectivité

​

Configurer Devin Connect

1. Choisissez « Add gateway », donnez-lui un nom et sélectionnez un type de connexion : « Tunnel » pour le tunnel inverse, ou « Direct » pour AWS PrivateLink. Pour « Direct », saisissez également le nom DNS et le port de l’Interface Endpoint (voir l’onglet AWS PrivateLink).
2. Sur la carte de la gateway, choisissez « Add destination » pour chaque destination que Devin doit joindre par son intermédiaire : un hostname exact, ou bien une adresse IPv4 ou un bloc CIDR tel que 10.20.0.0/16. Les caractères génériques ne sont pas pris en charge. Une destination ne peut appartenir qu’à une seule gateway.
3. Pour une gateway à tunnel, choisissez « Generate token » pour l’enrôler. Le token d’enrôlement ne s’affiche qu’une seule fois, n’est jamais stocké par Devin et peut être renouvelé ou révoqué à tout moment via « Regenerate token ». Les gateways directes n’ont pas de tunnel à authentifier : cette étape ne les concerne donc pas.
4. Pour une gateway à tunnel, copiez l’extrait de déploiement correspondant à votre plateforme (Docker, Kubernetes, AWS ECS, Terraform sur ECS ou EC2, ou un hôte Linux). L’extrait contient un fichier config.yaml prêt à l’emploi, généré à partir des destinations de la gateway : pensez à le copier de nouveau après toute modification de celles-ci.

​

Destinations par hostname et IPv4

• Les hostnames sont mis en correspondance avec le nom auquel la session se connecte, lu dans le SNI TLS ou dans l’en-tête HTTP Host. Ils n’acheminent donc que le trafic TLS et HTTP en clair. Le Gateway résout le nom à l’aide de votre DNS.
• Les adresses IPv4 et les CIDR sont mis en correspondance avec l’adresse IP de destination de la connexion ; ils acheminent donc tout protocole TCP, y compris les connexions SSH et les connexions aux bases de données. Devin ne résout pas vos noms internes pour ces routes : les sessions se connectent par adresse IP, ou bien vous fournissez la résolution de noms dans l’environnement, par exemple au moyen d’entrées /etc/hosts définies dans votre blueprint.

​

Modes de connectivité

• Tunnel inverse
• AWS PrivateLink

Le Gateway ouvre N tunnels TLS sortants vers votre tenant endpoint, <customer>.gateway.devinenterprise.com:443. Vous n’ouvrez jamais de port entrant. Un tunnel enregistré ne transporte que les flux ouverts par le côté Devin en direction de votre Gateway ; il ne constitue pas une voie d’accès entrante vers Devin.L’enrôlement se déroule ainsi :

1. Devin vous délivre un token d’enrôlement pour le gateway du tunnel depuis la settings page “Devin Connect”.
2. Vous installez le token sur l’hôte du Gateway, à l’emplacement indiqué par tunnel.auth_token_file.
3. Le Gateway se connecte à <customer>.gateway.devinenterprise.com:443, vérifie le certificat serveur de l’edge Devin et présente le token.
4. L’edge valide le token (comparaison à temps constant avec une empreinte stockée ; le token brut n’est jamais conservé côté Devin) et enregistre le tunnel. Les connexions initiées côté Devin vers les destinations du gateway transitent alors par ce tunnel.

Le tunnel se configure avec une section tunnel et sans adresse listen : l’hôte du Gateway n’expose ainsi aucun port de proxy :

tunnel:
  endpoint: acme.gateway.devinenterprise.com:443
  gateway_id: gw-1
  # Token d'enrôlement, sur une seule ligne ; relu à chaque tentative de
  # connexion, ce qui permet de le renouveler sans redémarrage.
  auth_token_file: /etc/devin-gateway/tunnel-token
  # carrier: websocket   # valeur par défaut ; utilisez `direct` pour désactiver l'encapsulation WebSocket.
  # ca_file: corp-ca.pem # uniquement si un proxy d'inspection TLS d'entreprise
  #                      # re-signe la connexion vers l'edge.
  # egress_proxy:        # proxy HTTP CONNECT de sortie du client, si nécessaire.
  #   addr: proxy.corp.example:3128

Champ	Description
endpoint	Votre tenant endpoint, <customer>.gateway.devinenterprise.com:443.
gateway_id	Identifiant de cette instance de Gateway, utilisé dans les logs et les métriques.
auth_token_file	Chemin vers le fichier du token d’enrôlement sur une seule ligne.
carrier	websocket (par défaut) ou direct. Les deux exécutent le même protocole au sein de la même connexion TLS ; websocket ajoute un encapsulage HTTP Upgrade pour les chemins de sortie qui ne laissent pas passer le TLS brut.
ca_file	Bundle d’autorités de certification au format PEM permettant de vérifier le certificat edge de Devin, nécessaire uniquement derrière un proxy d’inspection TLS d’entreprise qui resigne les certificats.
egress_proxy	Votre proxy HTTP CONNECT de sortie (addr, auth facultatif), si le trafic sortant doit obligatoirement passer par un proxy.
connection_pool	size (1 à 16 tunnels, rechargeable) et max_streams_per_connection (2 à 2048).

Points supplémentaires à vérifier pour ce mode :

• Autorisez le trafic sortant de la Gateway vers <customer>.gateway.devinenterprise.com:443 et vers vos services internes figurant dans la liste d’autorisation. Aucune règle entrante n’est nécessaire.
• Stockez le token d’enrôlement dans votre gestionnaire de secrets et montez-le sous forme de fichier. Ne l’inscrivez jamais en dur dans des images, dans une configuration versionnée ou dans des logs ; la Gateway ne le consigne jamais.
• Vous pouvez également fournir à Cognition vos plages CIDR de sortie afin de restreindre l’endpoint public au niveau IP (défense en profondeur ; le token d’enrôlement reste le point de contrôle de l’authentification).

Le Gateway expose le proxy de liste d’autorisation sur un listener HTTP CONNECT local, et Devin atteint ce listener via PrivateLink :

1. Vous déployez le Gateway dans un sous-réseau privé de votre AWS VPC avec une adresse listen.
2. Vous placez un Network Load Balancer devant lui, ciblant le port du listener, puis vous créez un VPC Endpoint Service à partir de ce NLB.
3. Vous ajoutez l’AWS account de Cognition comme principal autorisé et vous communiquez à Cognition le nom de l’endpoint service.
4. Cognition crée un Interface VPC Endpoint dans le VPC de votre tenant dédié et vous communique son nom DNS. Une demande de connexion est alors envoyée à votre endpoint service, que vous approuvez (ou qui est acceptée automatiquement, si vous avez activé cette option sur le service).
5. Sur la page de paramètres « Devin Connect », vous ajoutez un gateway avec la connexion « Direct », saisissez le nom DNS de l’interface endpoint et le port du listener, puis ajoutez les destinations qu’il doit servir. Reportez ces mêmes destinations dans les routes du Gateway.

Comme l’endpoint service n’est consommable que par le compte de Cognition et que le NLB reste interne à votre VPC, il n’y a aucun listener public. L’accès est autorisé par le principal AWS défini sur l’endpoint service ainsi que par la liste d’autorisation en default-deny propre au Gateway.La configuration du Gateway définit listen sur le port ciblé par le NLB :

schema_version: 1
admin_listen: 0.0.0.0:9090

# Le listener HTTP CONNECT local ciblé par le NLB.
listen: 0.0.0.0:8443

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

Ce que vous devez fournir à Cognition :

• Le nom du VPC Endpoint Service, par exemple com.amazonaws.vpce.us-west-2.vpce-svc-0abc123.
• Le port d’écoute exposé par le NLB.
• La confirmation que l’AWS account de Cognition est un principal autorisé.
• Si l’endpoint service prend en charge la région dans laquelle s’exécute votre tenant Devin, lorsqu’elle diffère de celle du Gateway.

Points de contrôle supplémentaires pour ce mode :

• Déployez les cibles du NLB dans plusieurs zones de disponibilité.
• Si vos services se trouvent dans une région différente de celle de votre tenant Devin, activez la prise en charge inter-régions sur l’endpoint service. Les étapes sont identiques à celles décrites dans Réseau privé pour Dedicated Deployment.

​

Référence de configuration

schema_version: 1

# Écouteur d'administration (/healthz, /readyz, /metrics).
admin_listen: 127.0.0.1:9090

# Écouteur du plan de données. Mode PrivateLink (direct) uniquement : requis en l'absence
# de section `tunnel`, rejeté si celle-ci est présente.
# listen: 0.0.0.0:8443

# DNS du client pour résoudre les cibles des routes (résolveur système si omis).
dns:
  nameservers: ["10.0.0.2:53"]
  timeout: 5s

# Liste d'autorisation avec refus par défaut. Les règles acceptent des hostnames et des CIDR ipv4/ipv6.
# Si les ports sont omis, tous les ports sont autorisés.
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 sortant vers l'edge côté Devin. À omettre en mode PrivateLink.
tunnel:
  endpoint: acme.gateway.devinenterprise.com:443
  gateway_id: gw-1
  auth_token_file: /etc/devin-gateway/tunnel-token

​

Routes (liste d’autorisation)

​

Écouteurs

​

DNS

​

Exécution du Gateway

gateway serve --config /etc/devin-gateway/config.yaml
gateway validate-config --config config.yaml   # validation stricte de la config
gateway doctor --config config.yaml            # résumé de diagnostic au format JSON

• /healthz pour l’état d’activité du processus.
• /readyz pour la disponibilité.
• /metrics pour les métriques Prometheus.

• Exécutez le Gateway dans un sous-réseau privé.
• Raccordez /healthz et /readyz aux health checks de votre orchestrator.
• Maintenez la synchronisation entre les destinations de chaque gateway dans les Settings de Devin et les routes de la config de son Gateway ; une destination autorisée d’un seul côté n’est pas joignable.

​

Journalisation et intégration SIEM

• conn_open et conn_close, avec l’hôte et le port de destination, le nom de la route correspondante, l’adresse du client, les octets transférés dans chaque direction et la durée.
• deny, avec la destination et le motif (par exemple, aucune route de liste d’autorisation correspondante).