> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Devin Connect
> Devin Connect donne à Devin un accès privé aux systèmes internes : déployez un gateway faisant office de proxy de politique, joignable via un tunnel sortant uniquement ou AWS PrivateLink.
Devin Connect est actuellement en **accès anticipé**. Les fonctionnalités et la configuration peuvent évoluer. Contactez l'équipe en charge de votre compte Cognition si l'accès anticipé vous intéresse.
Devin Connect donne aux sessions Devin accès à vos systèmes internes (gestion de code source, registries d'artefacts, API internes) sans avoir à créer un chemin réseau pour chaque ressource. Vous déployez un gateway léger au sein de votre propre réseau, et Devin s'y connecte via une liaison privée.
**Version actuelle du gateway : v0.0.2**
Rôle de Devin Connect
Devin Connect comporte deux parties, configurées indépendamment l’une de l’autre.
**Un proxy de politique au sein de votre réseau.** Le Gateway est un proxy HTTP CONNECT doté d’une liste d’autorisation en mode refus par défaut. Il reçoit une demande de connexion vers `host:port`, la confronte à vos routes, résout le nom avec votre propre DNS, ouvre la connexion vers la destination et relaie des octets opaques. Ni le Gateway ni l’infrastructure Devin ne terminent ni n’inspectent le TLS entre la VM Devin et votre service, et chaque connexion est consignée dans le journal d’audit.
**Un chemin privé entre Devin et ce proxy.** Devin doit atteindre le proxy sans qu’aucune des deux parties n’expose quoi que ce soit sur l’internet public. Deux approches sont possibles, et le proxy se comporte de façon identique dans les deux cas :
* **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.
Choisissez-en une dans les onglets [Modes de connectivité](#connectivity-modes) ci-dessous ; tout le reste de cette page s’applique aux deux.
Propriétés valables dans les deux cas :
* **VPC mono-locataire dédié.** Votre Devin déploiement s’exécute dans son propre VPC (voir le [modèle Customer Dedicated Deployment](/fr/enterprise/deployment/overview#customer-dedicated-deployment-architecture)). 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](/fr/product-guides/security-profiles) 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é
| | Tunnel inverse | AWS PrivateLink |
| - | - | - |
| Exposition entrante | Aucune ; c'est le Gateway qui initie la connexion | Aucune sur internet ; l'endpoint service n'est accessible que par le compte de Cognition |
| Prérequis cloud | Tout réseau disposant d'une sortie vers `:443` | Le Gateway doit s'exécuter dans AWS, avec un NLB et un VPC Endpoint Service |
| Authentification de la connexion | Token d'enrôlement émis par Devin | Principal de compte AWS sur l'endpoint service |
| Chemin du trafic | Internet public (TLS), ou votre rattachement VPN/Transit Gateway | Backbone AWS |
| Interrégional | Sans objet | Pris en charge si vous l'activez sur l'endpoint service |
Dans les deux modes, la configuration s’effectue dans la webapp Devin, sur la page « Devin Connect » des paramètres Enterprise, accessible aux utilisateurs disposant du rôle d’administrateur approprié. Un compte peut disposer de plusieurs gateways, chacune acheminant son propre groupe de destinations : une gateway à tunnel inverse au maximum, et autant de gateways PrivateLink que nécessaire.
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](#connectivity-modes)).
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.
La carte de chaque gateway à tunnel indique également si elle est actuellement connectée, ainsi que la date de sa dernière activité.
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](/fr/onboard-devin/environment/blueprints).
Dans le fichier `config.yaml` du Gateway lui-même, autorisez les destinations IPv4 à l'aide de règles `ipv4` ; le snippet généré les inclut.
Modes de connectivité
Le Gateway ouvre N tunnels TLS sortants vers votre tenant endpoint, `.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 à `.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 :
```yaml theme={null}
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, `.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 `.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 :
```yaml theme={null}
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](/fr/enterprise/deployment/dedicated_saas_private_networking#cross-region-privatelink-if-your-services-are-in-a-different-region).
Référence de configuration
Le Gateway se configure à l'aide d'un seul fichier YAML, strictement validé et en mode fail-closed : une configuration qui ne passe pas la validation est rejetée dans son intégralité et la configuration précédente reste active. Le fichier est interrogé périodiquement toutes les 5 secondes et rechargé à chaud.
```yaml theme={null}
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)
Tout ce qui ne correspond à aucune route est refusé ; une liste de routes vide refuse tout. Les routes sont évaluées dans l'ordre et la première correspondance l'emporte.
| Champ | Description |
| - | - |
| `name` | Nom unique de la route ; apparaît dans les logs d'audit de connexion. |
| `rules` | Règles de correspondance de destination ; la route correspond dès qu'une règle correspond. La correspondance `hostname` est insensible à la casse. Les règles CIDR `ipv4`/`ipv6` ne s'appliquent qu'aux connexions vers des IP littérales. |
| `ports` | Ports de destination autorisés. En l'absence de valeur, tous les ports sont autorisés. |
| `upstream_proxy` | Proxy HTTP CONNECT amont facultatif à chaîner pour cette route (`addr`, `auth` facultatif). |
Les hostnames sont mis en correspondance tels qu'ils ont été demandés, avant la résolution DNS : la politique s'applique donc au nom lui-même, et non à l'IP vers laquelle il se résout.
Écouteurs
| Champ | Description |
| - | - |
| `admin_listen` | Écouteur d'administration pour `/healthz`, `/readyz` et `/metrics`. |
| `listen` | Écouteur HTTP CONNECT du plan de données. À définir en mode PrivateLink ; à omettre en mode tunnel, où les requêtes de connexion arrivent uniquement via le tunnel authentifié. |
| `dial_timeout` | Délai d'expiration de la connexion aux cibles en amont (10 s par défaut). |
DNS
| Champ | Description |
| - | - |
| `nameservers` | Serveurs DNS (`ip:port`) utilisés pour résoudre les cibles de route. En cas d'omission, le résolveur système de l'hôte du Gateway est utilisé, ce qui est le cas le plus courant puisque le Gateway s'exécute au sein de votre réseau. |
| `timeout` | Délai d'expiration par requête (5 s par défaut). |
Les routes par nom d'hôte sont refusées si votre DNS les résout vers des adresses de bouclage, link-local ou non spécifiées : un nom figurant dans la liste d'autorisation ne peut donc pas être redirigé vers l'hôte du Gateway lui-même ni vers un endpoint de métadonnées.
Exécution du Gateway
Le Gateway est distribué sous forme d'image de container contenant un unique binary statique (l'image est construite `FROM scratch` et s'exécute avec un user non-root). Montez la config à l'emplacement `/etc/devin-gateway/config.yaml` et, en mode tunnel, le fichier de token à l'emplacement indiqué par `tunnel.auth_token_file`.
```bash theme={null}
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
```
Endpoints opérationnels sur `admin_listen` :
* `/healthz` pour l'état d'activité du processus.
* `/readyz` pour la disponibilité.
* `/metrics` pour les métriques Prometheus.
Liste de vérification pour le déploiement dans les deux modes :
* 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
Le Gateway écrit ses logs sur stdout. Lorsque stdout n'est pas un terminal (le cas normal dans un container), les logs sont émis sous forme de lignes JSON, directement exploitables par une machine. Pour les acheminer vers votre SIEM, utilisez le pipeline de logs standard de votre plateforme : le pilote de logs du container ou l'agent (CloudWatch Logs, Fluent Bit, Vector, agent Datadog, etc.) collecte stdout et le transmet comme les logs de n'importe quelle autre charge de travail. Le Gateway ne nécessite aucune configuration spécifique au SIEM.
Les événements d'audit de connexion comprennent :
* `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).
Le token d'enrôlement n'est jamais journalisé, pas plus que le contenu des charges utiles.
Pour une connectivité privée par service sans Gateway, consultez [Réseau privé en Dedicated Deployment](/fr/enterprise/deployment/dedicated_saas_private_networking). Pour une vue d'ensemble des modèles de déploiement, consultez la [Vue d'ensemble du déploiement](/fr/enterprise/deployment/overview).
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.