Devin Connect

​

Devin Connect の機能

• リバーストンネル: Gateway が TLS 経由で Devin 側のエンドポイントへアウトバウンド接続し、Devin はそのトンネルを通じて接続リクエストを送り返します。お客様のネットワークへのインバウンドは一切開放されず、クラウドプロバイダーとの統合も不要です。
• AWS PrivateLink: Gateway の前面に Network Load Balancer と VPC Endpoint Service を配置し、Cognition が専用テナント VPC 内の Interface VPC Endpoint からこれを利用します。トラフィックは AWS バックボーン内に留まり、Devin は非公開 IP 経由で Gateway へ直接接続します。

• 専用のシングルテナント VPC。 Devin デプロイメントは独自の VPC 内で動作します (Customer Dedicated Deployment モデル を参照) 。Devin VM は、ルーティング対象の宛先向けトラフィックを、Cognition が設定した egress 制御を介して Gateway へ送信します。
• デフォルト拒否を二重に適用。 ルートは Gateway 側と Devin 側の両方で適用されるため、片側の設定変更だけではアクセス範囲を広げられません。宛先をルーティングしても、セッションの権限が広がることはありません。あくまでセッションの セキュリティプロファイル が許可している必要があります。
• アプリケーションの TLS はエンドツーエンド。 Gateway は不透明なバイトストリームを転送するだけです。
• DNS はネットワーク内に留まる。 ルートの宛先はお客様のリゾルバー (デフォルトでは Gateway ホストのシステムリゾルバー、または設定したネームサーバー) で解決されます。
• 1 つのデプロイメントですべてのルーティング対象の宛先をカバー。 サービスごとに個別の仕組みを構築する必要はなく、Devin の設定でホスト名と IPv4 範囲を追加するだけです。

​

接続モードの選択

​

Devin Connect を設定する

1. 「Add gateway」を選択して名前を付け、接続方式を選びます。リバーストンネルの場合は「Tunnel」、AWS PrivateLink の場合は「Direct」を選択します。「Direct」の場合は、Interface Endpoint の DNS 名とポートも入力します (AWS PrivateLink タブを参照) 。
2. gateway のカードで、Devin がその gateway 経由でアクセスする宛先ごとに「Add destination」を選択します。宛先には、完全一致のホスト名、または IPv4 アドレスや 10.20.0.0/16 のような CIDR を指定します。ワイルドカードはサポートされていません。1 つの宛先が所属できる gateway は 1 つだけです。
3. トンネル gateway の場合は、「Generate token」を選択して登録します。エンロールメントトークンは一度だけ表示され、Devin に保存されることはありません。「Regenerate token」を使えば、いつでもローテーションまたは失効できます。Direct gateway には認証対象となるトンネルがないため、この手順は不要です。
4. トンネル gateway の場合は、利用するプラットフォーム (Docker、Kubernetes、AWS ECS、ECS または EC2 上の Terraform、Linux ホスト) 向けのデプロイ用スニペットをコピーします。スニペットには、gateway の宛先から生成された、そのまま実行できる config.yaml が含まれています。宛先を変更した後は、スニペットを再度コピーしてください。

​

ホスト名と IPv4 の宛先

• ホスト名は、セッションの接続先の名前で照合されます。この名前は TLS SNI または HTTP の Host ヘッダーから取得されます。そのため、ホスト名でルーティングできるのは TLS とプレーンな HTTP のトラフィックのみです。名前解決には、Gateway がお使いの DNS を使用します。
• IPv4 アドレスと CIDR は接続の宛先 IP で照合されるため、SSH やデータベース接続を含むあらゆる TCP プロトコルをルーティングできます。これらのルートでは、Devin は社内のホスト名を解決しません。セッションから IP アドレスで接続するか、環境内で名前解決の手段を用意してください。たとえば、ブループリントで /etc/hosts の項目を設定する方法があります。

​

接続モード

• リバーストンネル
• AWS PrivateLink

Gateway は、テナントのエンドポイント <customer>.gateway.devinenterprise.com:443 へ N 本の TLS トンネルを外向きに張ります。インバウンドポートを開放する必要は一切ありません。登録済みのトンネルが転送するのは Devin 側から Gateway へ向けて開かれたストリームのみで、Devin へのインバウンド経路にはなりません。エンロールメントの流れは次のとおりです。

1. Devin が「Devin Connect」設定ページから、トンネル gateway 用のエンロールメントトークンを発行します。
2. tunnel.auth_token_file が指すパスに、そのトークンを Gateway ホスト上へ配置します。
3. Gateway が <customer>.gateway.devinenterprise.com:443 へ接続し、Devin エッジのサーバー証明書を検証してトークンを提示します。
4. エッジがトークンを検証し (保存済みのダイジェストとの定数時間比較。生のトークンが Devin 側に保存されることはありません) 、トンネルを登録します。以降、gateway の接続先に対する Devin 側からの接続は、このトンネルを経由します。

トンネルは tunnel スタンザで設定し、listen アドレスを指定しないため、Gateway ホストはプロキシポートを一切公開しません。

tunnel:
  endpoint: acme.gateway.devinenterprise.com:443
  gateway_id: gw-1
  # エンロールメントトークン（1行）。接続試行のたびに再読み込みされるため、
  # 再起動せずにローテーションできます。
  auth_token_file: /etc/devin-gateway/tunnel-token
  # carrier: websocket   # 既定値。WebSocketフレーミングを無効にする場合は `direct` を利用します。
  # ca_file: corp-ca.pem # 社内TLSインスペクションプロキシがエッジ接続を
  #                      # 再署名する場合のみ指定します。
  # egress_proxy:        # 必要な場合のみ、顧客側の送信HTTP CONNECTプロキシを指定します。
  #   addr: proxy.corp.example:3128

フィールド	説明
endpoint	テナントのエンドポイント (<customer>.gateway.devinenterprise.com:443) 。
gateway_id	この Gateway インスタンスの識別子。ログとメトリクスで使用されます。
auth_token_file	1行のエンロールメントトークンファイルへのパス。
carrier	websocket (デフォルト) または direct。いずれも同一のTLS接続内で同じプロトコルを実行します。websocket は、生のTLSを通せないエグレス経路向けにHTTP Upgradeフレーミングを付加します。
ca_file	Devin エッジ証明書を検証するためのPEM形式のCAバンドル。証明書を再署名する社内TLSインスペクションプロキシの背後にある場合にのみ必要です。
egress_proxy	送信トラフィックがプロキシを経由する必要がある場合の、エグレスHTTP CONNECTプロキシ (addr、任意で auth) 。
connection_pool	size (1〜16トンネル、リロード可能) および max_streams_per_connection (2〜2048) 。

このモードで追加で確認すべき項目:

• Gateway から <customer>.gateway.devinenterprise.com:443 および許可リストに登録した内部サービスへのエグレスを許可してください。インバウンドのルールは不要です。
• エンロールメントトークンはシークレットマネージャーに保存し、ファイルとしてマウントしてください。イメージ、バージョン管理下の設定ファイル、ログには決して埋め込まないでください。Gateway がトークンをログに出力することはありません。
• 必要に応じて、エグレスのCIDRレンジをCognitionに連携すれば、公開エンドポイントをIPレベルで制限できます (多層防御。認証のゲートはあくまでエンロールメントトークンです) 。

Gateway はローカルの HTTP CONNECT リスナー上で allowlist proxy を提供し、Devin は PrivateLink 経由でそのリスナーに接続します。

1. listen アドレスを指定した Gateway を、AWS VPC 内の非公開サブネットにデプロイします。
2. その前段にリスナーポートを宛先とする Network Load Balancer を配置し、その NLB から VPC Endpoint Service を作成します。
3. Cognition の AWS account を allowed principal として追加し、endpoint service 名を Cognition に送付します。
4. Cognition が dedicated tenant VPC 内に Interface VPC Endpoint を作成し、その DNS 名をお客様に連絡します。これにより endpoint service へ接続リクエストが送信されるので、これを承認します (サービス側で自動承認を有効にしている場合は自動的に承認されます) 。
5. 「Devin Connect」設定ページで「Direct」接続の gateway を追加し、Interface Endpoint の DNS 名とリスナーポートを入力したうえで、Gateway が処理する宛先を追加します。同じ宛先を Gateway の routes にも設定してください。

endpoint service は Cognition の account からのみ利用でき、NLB は VPC 内部に閉じているため、公開リスナーは存在しません。アクセスは endpoint service 上の AWS principal と、Gateway 自身の default-deny の allowlist によって認可されます。Gateway の configuration では、NLB が宛先とするポートを listen に設定します。

schema_version: 1
admin_listen: 0.0.0.0:9090

# NLB のターゲットとなるローカルの HTTP CONNECT リスナー。
listen: 0.0.0.0:8443

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

Cognition に提供する情報:

• VPC Endpoint Service 名 (例: com.amazonaws.vpce.us-west-2.vpce-svc-0abc123)
• NLB が公開するリスナーポート
• Cognition の AWS account が Allowed principal として許可されていることの確認
• Gateway のリージョンと異なる場合、Devin の tenant が稼働するリージョンを endpoint service がサポートしているかどうか

このモードでの追加のチェックリスト項目:

• NLB のターゲットを複数のアベイラビリティーゾーンで実行してください。
• サービスが Devin の tenant とは別のリージョンにある場合は、endpoint service でクロスリージョンサポートを有効にしてください。手順は Dedicated Deployment のプライベートネットワーキングと同じです。

​

Configuration リファレンス

schema_version: 1

# 管理リスナー (/healthz, /readyz, /metrics)。
admin_listen: 127.0.0.1:9090

# データプレーンリスナー。PrivateLink（direct）モード専用: `tunnel` セクションが
# ない場合は必須、ある場合は拒否されます。
# listen: 0.0.0.0:8443

# ルートの宛先を解決するための顧客側 DNS（省略時はシステムリゾルバーを使用）。
dns:
  nameservers: ["10.0.0.2:53"]
  timeout: 5s

# デフォルト拒否の 許可リスト。ルールには hostname と ipv4/ipv6 CIDR を指定できます。
# ports を省略した場合は任意のポートが対象になります。
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]

# Devin 側エッジへのアウトバウンドトンネル。PrivateLink モードでは省略します。
tunnel:
  endpoint: acme.gateway.devinenterprise.com:443
  gateway_id: gw-1
  auth_token_file: /etc/devin-gateway/tunnel-token

​

Routes (許可リスト)

​

リスナー

​

DNS

​

Gateway の実行

gateway serve --config /etc/devin-gateway/config.yaml
gateway validate-config --config config.yaml   # 設定の厳密な検証
gateway doctor --config config.yaml            # JSON形式の診断サマリー

• /healthz — プロセスの死活確認。
• /readyz — 準備状態。
• /metrics — Prometheus メトリクス。

• Gateway はプライベートサブネットで実行してください。
• /healthz と /readyz をオーケストレーターのヘルスチェックに組み込んでください。
• Devin の設定にある各 gateway の接続先と、その Gateway の設定にあるルートを常に同期させてください。片方だけで許可されている接続先には到達できません。

​

ログ記録とSIEM統合

• conn_open と conn_close。宛先ホストとポート、マッチしたルート名、クライアントアドレス、各方向の転送バイト数、継続時間を含みます。
• deny。宛先および理由 (例: マッチする許可リストルートがない) を含みます。