Devin Connect

​

Was Devin Connect leistet

• Reverse-Tunnel: Das Gateway baut eine ausgehende TLS-Verbindung zu einem Devin-seitigen Endpunkt auf, und Devin sendet Verbindungsanfragen über diesen Tunnel zurück. Es wird nichts eingehend in Ihr Netzwerk geöffnet, und es ist keine Integration mit einem Cloud-Anbieter erforderlich.
• AWS PrivateLink: Sie stellen dem Gateway einen Network Load Balancer und einen VPC Endpoint Service voran, und Cognition nutzt diesen über einen Interface VPC Endpoint in Ihrer dedizierten Tenant-VPC. Der Traffic bleibt im AWS-Backbone, und Devin verbindet sich direkt über private IPs mit dem Gateway.

• Dedizierte Single-Tenant-VPC. Ihr Devin-Deployment läuft in einer eigenen VPC (siehe Customer Dedicated Deployment-Modell). Devin-VMs senden Traffic für Ihre gerouteten Ziele über die von Cognition konfigurierte Egress-Kontrolle an das Gateway.
• Default-Deny, doppelt durchgesetzt. Routen werden sowohl auf dem Gateway als auch auf der Devin-Seite durchgesetzt, sodass eine reine Konfigurationsänderung auf einer Seite den Zugriff nicht ausweiten kann. Das Routing eines Ziels erweitert niemals die Permissions einer Sitzung: Das Security Profile der Sitzung muss den Zugriff weiterhin erlauben.
• Ihr Anwendungs-TLS ist Ende-zu-Ende. Das Gateway leitet Byteströme unverändert weiter.
• DNS bleibt innerhalb Ihres Netzwerks. Route-Ziele werden von Ihren Resolvern aufgelöst (standardmäßig durch den System Resolver des Gateway-Hosts oder durch von Ihnen konfigurierte Nameserver).
• Ein Deployment deckt alle gerouteten Ziele ab. Sie fügen Hostnames und IPv4-Bereiche in den Devin-Settings hinzu, statt für jeden Service eigene Verbindungen zu bauen.

​

Auswahl eines Konnektivitätsmodus

​

Devin Connect konfigurieren

1. Wählen Sie „Add gateway“, vergeben Sie einen Namen und wählen Sie eine Verbindungsart: „Tunnel“ für den Reverse-Tunnel oder „Direct“ für AWS PrivateLink. Geben Sie bei „Direct“ zusätzlich den DNS-Namen und den Port des Interface Endpoints ein (siehe Tab AWS PrivateLink).
2. Wählen Sie auf der Karte des Gateways für jedes Ziel, das Devin darüber erreichen soll, „Add destination“: einen exakten Hostnamen oder eine IPv4-Adresse bzw. einen CIDR-Bereich wie 10.20.0.0/16. Wildcards werden nicht unterstützt. Jedes Ziel kann nur einem Gateway zugeordnet sein.
3. Wählen Sie bei einem Tunnel-Gateway „Generate token“, um es zu registrieren. Das Enrollment-Token wird nur einmal angezeigt, von Devin nie gespeichert und kann jederzeit über „Regenerate token“ rotiert oder widerrufen werden. Direct-Gateways haben keinen Tunnel, der authentifiziert werden muss – dieser Schritt entfällt daher.
4. Kopieren Sie bei einem Tunnel-Gateway das Bereitstellungs-Snippet für Ihre Plattform (Docker, Kubernetes, AWS ECS, Terraform auf ECS oder EC2 oder ein Linux-Host). Das Snippet enthält eine sofort ausführbare config.yaml, die aus den Zielen des Gateways generiert wird. Kopieren Sie es daher erneut, wenn Sie die Ziele ändern.

​

Hostname- und IPv4-Ziele

• Hostnames werden anhand des Namens abgeglichen, zu dem die Sitzung eine Verbindung herstellt. Dieser wird aus der TLS-SNI oder dem HTTP-Host-Header ausgelesen. Daher leiten sie ausschließlich TLS- und unverschlüsselten HTTP-Datenverkehr weiter. Das Gateway löst den Namen über Ihren DNS auf.
• IPv4-Adressen und CIDRs werden anhand der Ziel-IP der Verbindung abgeglichen und leiten daher jedes TCP-Protokoll weiter, einschließlich SSH- und Datenbankverbindungen. Für diese Routen löst Devin Ihre internen Namen nicht auf: Sitzungen verbinden sich direkt per IP-Adresse, oder Sie stellen die Namensauflösung in der Umgebung bereit, zum Beispiel über /etc/hosts-Einträge, die Sie in Ihrem Blueprint einrichten.

​

Konnektivitätsmodi

• Reverse-Tunnel
• AWS PrivateLink

Das Gateway baut N ausgehende TLS-Tunnel zu Ihrem Tenant-Endpunkt <customer>.gateway.devinenterprise.com:443 auf. Sie öffnen dabei niemals einen eingehenden Port. Ein registrierter Tunnel überträgt ausschließlich Streams, die die Devin-Seite in Richtung Ihres Gateways öffnet; er stellt keinen eingehenden Pfad zu Devin dar.Die Registrierung läuft folgendermaßen ab:

1. Devin stellt Ihnen auf der Settings-Seite “Devin Connect” ein Enrollment-Token für das Tunnel-Gateway aus.
2. Sie installieren das Token auf dem Gateway-Host unter dem Pfad, auf den tunnel.auth_token_file verweist.
3. Das Gateway verbindet sich mit <customer>.gateway.devinenterprise.com:443, prüft das Serverzertifikat des Devin-Edge und übermittelt das Token.
4. Der Edge validiert das Token (Vergleich in konstanter Zeit mit einem gespeicherten Digest; das Roh-Token wird auf der Devin-Seite nie gespeichert) und registriert den Tunnel. Verbindungen von der Devin-Seite zu den Zielen des Gateways laufen anschließend darüber.

Der Tunnel wird mit einem tunnel-Block und ohne listen-Adresse konfiguriert, sodass der Gateway-Host überhaupt keinen Proxy-Port bereitstellt:

tunnel:
  endpoint: acme.gateway.devinenterprise.com:443
  gateway_id: gw-1
  # Enrollment-Token, einzeilig; wird bei jedem Verbindungsversuch neu eingelesen
  # und lässt sich so ohne Neustart rotieren.
  auth_token_file: /etc/devin-gateway/tunnel-token
  # carrier: websocket   # Standard; `direct` deaktiviert das WebSocket-Framing.
  # ca_file: corp-ca.pem # nur wenn ein Unternehmens-Proxy mit TLS-Inspektion die
  #                      # Edge-Verbindung neu signiert.
  # egress_proxy:        # HTTP-CONNECT-Egress-Proxy des Kunden, falls erforderlich.
  #   addr: proxy.corp.example:3128

Feld	Beschreibung
endpoint	Ihr Tenant-Endpunkt, <customer>.gateway.devinenterprise.com:443.
gateway_id	Kennung für diese Gateway-Instanz, wird in Logs und Metrics verwendet.
auth_token_file	Pfad zur einzeiligen Datei mit dem Enrollment Token.
carrier	websocket (Standard) oder direct. Beide führen dasselbe Protokoll innerhalb derselben TLS-Verbindung aus; websocket ergänzt HTTP-Upgrade-Framing für Egress-Pfade, die kein rohes TLS durchlassen.
ca_file	PEM-CA-Bundle zur Verifizierung des Devin-Edge-Zertifikats; nur erforderlich hinter einem Unternehmens-Proxy mit TLS-Inspection, der Zertifikate neu signiert.
egress_proxy	Ihr ausgehender HTTP-CONNECT-Proxy (addr, optional auth), falls ausgehender Datenverkehr darüber geleitet werden muss.
connection_pool	size (1–16 Tunnel, neu ladbar) und max_streams_per_connection (2–2048).

Zusätzliche Checklisten-Einträge für diesen Modus:

• Erlauben Sie ausgehenden Datenverkehr vom Gateway zu <customer>.gateway.devinenterprise.com:443 und zu Ihren auf der Allowlist stehenden internen Diensten. Eingehende Regeln sind nicht erforderlich.
• Speichern Sie das Enrollment Token in Ihrem Secret-Manager und binden Sie es als Datei ein. Legen Sie es niemals in Images, in versionskontrollierter Konfiguration oder in Logs ab; das Gateway protokolliert es zu keinem Zeitpunkt.
• Stellen Sie Cognition optional Ihre ausgehenden CIDR-Ranges bereit, um den öffentlichen Endpunkt auf IP-Ebene einzuschränken (gestaffelte Absicherung; das Enrollment Token bleibt die maßgebliche Authentifizierungsinstanz).

Das Gateway stellt den Allowlist-Proxy über einen lokalen HTTP-CONNECT-Listener bereit, und Devin erreicht diesen Listener über PrivateLink:

1. Sie stellen das Gateway in einem privaten Subnetz Ihrer AWS VPC mit einer listen-Adresse bereit.
2. Sie schalten einen Network Load Balancer davor, der auf den Listener-Port zielt, und erstellen aus diesem NLB einen VPC Endpoint Service.
3. Sie fügen den AWS account von Cognition als allowed principal hinzu und senden Cognition den Namen des Endpoint Service.
4. Cognition erstellt einen Interface VPC Endpoint in Ihrer dedizierten Tenant-VPC und sendet Ihnen dessen DNS-Namen. Dadurch wird eine Verbindungsanfrage an Ihren Endpoint Service gesendet, die Sie genehmigen (oder automatisch akzeptieren lassen, sofern Sie das für den Service aktiviert haben).
5. Sie fügen auf der Settings-Seite „Devin Connect“ ein Gateway mit der Verbindung „Direct“ hinzu, geben den DNS-Namen des Interface Endpoint sowie den Listener-Port ein und fügen die Ziele hinzu, die das Gateway bedienen soll. Tragen Sie dieselben Ziele in die routes des Gateways ein.

Da der Endpoint Service ausschließlich vom account von Cognition genutzt werden kann und der NLB VPC-intern ist, gibt es keinen öffentlichen Listener. Der Zugriff wird über den AWS Principal am Endpoint Service sowie über die Default-Deny-Allowlist des Gateways autorisiert.Die Gateway-Konfiguration setzt listen auf den Port, auf den der NLB zielt:

schema_version: 1
admin_listen: 0.0.0.0:9090

# Der lokale HTTP-CONNECT-Listener, auf den der NLB als Ziel zeigt.
listen: 0.0.0.0:8443

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

Was Sie Cognition bereitstellen müssen:

• Den Namen des VPC Endpoint Service, zum Beispiel com.amazonaws.vpce.us-west-2.vpce-svc-0abc123.
• Den Listener-Port, den der NLB bereitstellt.
• Die Bestätigung, dass das AWS Account von Cognition ein Allowed Principal ist.
• Ob der Endpoint Service die Region unterstützt, in der Ihr Devin-Tenant läuft, sofern sie von der Region des Gateways abweicht.

Zusätzliche Checklisten-Einträge für diesen Modus:

• Betreiben Sie die NLB-Ziele in mehreren Availability Zones.
• Wenn sich Ihre Dienste in einer anderen Region als Ihr Devin-Tenant befinden, aktivieren Sie die regionsübergreifende Unterstützung für den Endpoint Service. Die Schritte sind dieselben wie unter Private Netzwerkanbindung für Dedizierte Deployments.

​

Konfigurationsreferenz

schema_version: 1

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

# Datenebene-Listener. Nur im PrivateLink-(direct-)Modus: erforderlich ohne
# `tunnel`-Abschnitt, mit einem solchen wird er abgelehnt.
# listen: 0.0.0.0:8443

# Kunden-DNS zum Beziehen der Routenziele (System-Resolver, falls weggelassen).
dns:
  nameservers: ["10.0.0.2:53"]
  timeout: 5s

# Default-Deny-Allowlist. Rules akzeptieren hostnames sowie IPv4-/IPv6-CIDRs.
# Werden Ports weggelassen, gilt jeder Port.
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]

# Ausgehender Tunnel zum Edge auf Devin-Seite. Im PrivateLink-Modus weglassen.
tunnel:
  endpoint: acme.gateway.devinenterprise.com:443
  gateway_id: gw-1
  auth_token_file: /etc/devin-gateway/tunnel-token

​

Routes (allowlist)

​

Listeners

​

DNS

​

Gateway ausführen

gateway serve --config /etc/devin-gateway/config.yaml
gateway validate-config --config config.yaml   # strikte Config-Validierung
gateway doctor --config config.yaml            # Diagnosezusammenfassung als JSON

• /healthz für Prozess-Liveness.
• /readyz für Readiness.
• /metrics für Prometheus-Metriken.

• Betreiben Sie das Gateway in einem privaten Subnetz.
• Binden Sie /healthz und /readyz in die Integritätsprüfungen Ihres Orchestrators ein.
• Halten Sie die Ziele jedes Gateways in den Devin-Settings und die Routen in dessen Gateway-Config synchron; ein Ziel, das nur auf einer Seite erlaubt ist, ist nicht erreichbar.

​

Logging und SIEM-Integration

• conn_open und conn_close, mit Zielhost und Port, Name der zutreffenden Route, Client-Adresse, in beide Richtungen übertragenen Bytes und Dauer.
• deny, mit Ziel und Grund (zum Beispiel keine passende Allowlist-Route).