MCPトンネルはリサーチプレビュー段階です。お試しいただくにはアクセスをリクエストしてください。
プロキシは、/etc/mcp-gateway/config.yaml(Compose)またはレンダリングされたConfigMap(Helm、gateway.config.*から設定)から設定を読み込みます。
| フィールド | 説明 | デフォルト |
|---|---|---|
listen_addr | リッスンするアドレスとポート。 | 必須 |
log_level | ログの詳細度:debug、info、warn、またはerror。 | info |
shutdown_timeout | グレースフルシャットダウン中に処理中のリクエストを待機する時間。 | 30s |
tunnel_domain | トンネルに割り当てられたベースドメイン。設定されている場合、ルート検索は受信ホスト名からこのサフィックスを削除するため、routesのキーはベアサブドメイン(wiki)にできます。空の場合、routesのキーは完全なホスト名と正確に一致する必要があります。 | routesのキーがベアサブドメインの場合は必須 |
tls.cert_file | サーバーTLS証明書へのパス。 | 必須 |
tls.key_file | サーバーTLS秘密鍵へのパス。 | 必須 |
routes | サブドメインまたは完全なホスト名からアップストリームURLへのマップ。ルートマッチングを参照してください。 | 必須 |
upstream.allowed_ips | プロキシが接続を許可されているIPv4 CIDR範囲または単一アドレス。disable_ip_validationと相互排他的です。 | RFC1918プライベート範囲 |
upstream.disable_ip_validation | アップストリームIP検証を完全に無効にします。allowed_ipsと相互排他的です。 | false |
upstream.tls.ca_file | アップストリームTLSを検証するためのCAバンドル。 | なし |
upstream.tls.include_system_cas | アップストリームTLSに対してシステムCAバンドルも信頼します。 | false |
https://アップストリームルートの場合、upstream.tls.ca_fileまたはupstream.tls.include_system_casの少なくとも一方を設定してください。そうしないと、プロキシにはアップストリーム証明書のトラストアンカーがありません。
routesはリストではなく、フラットな文字列マップ(map[string]string)です。プロキシは、まず受信ホスト名を完全一致で検索し、次にtunnel_domainサフィックスを削除して残りのサブドメインでマッチングします。マッチングはホスト名のみを考慮し、リクエストパスとクエリ文字列は変更されずにアップストリームMCPサーバーに転送されます。
各アップストリーム値は正確にscheme://host:portである必要があります。ポートは必須です。パスを含めると、設定読み込み時にinvalid upstream (must be scheme://host:port)として拒否されます。
すべてのエンドポイント、リクエストおよびレスポンススキーマ、言語別の例については、MCPトンネルAdmin APIリファレンスを参照してください。
すべてのMCPトンネルエンドポイントには、Workload Identity Federationを通じて取得したorg:manage_tunnelsスコープを持つベアラートークンが必要です。Admin APIキーは受け付けられません。
すべてのリクエストに必要なヘッダー:
| ヘッダー | 値 |
|---|---|
Authorization | Bearer <token>(WIFで交換されたトークン) |
anthropic-version | 2023-06-01 |
anthropic-beta | mcp-tunnels-2026-05-19 |
セットアップコンポーネントは、準拠した証明書を自動的に生成します。これらの要件は、独自のPKIを通じて証明書を発行する場合にのみ適用されます。
POST /v1/organizations/tunnels/{tunnel_id}/certificatesでアップロードします。トンネルは同時に最大2つのアクティブなCA証明書を保持でき、これによりダウンタイムなしのローテーションが可能になります。
BasicConstraints拡張が存在し、CA:TRUEでクリティカルとしてマークされている。SubjectKeyIdentifier拡張が存在する。KeyUsageにkeyCertSignが含まれている。内部TLS中にプロキシによって提示されます。
AuthorityKeyIdentifier拡張が存在し、CAのSubjectKeyIdentifierと一致している。<route>.<tunnel-domain>と一致するDNS名が含まれている。ワイルドカード*.<tunnel-domain>はすべてのルートをカバーします。ExtendedKeyUsage拡張が存在する場合、serverAuthが含まれている。セットアップコンポーネントは、有効期間5年のECDSA P-256 CAと、ワイルドカードSANおよび有効期間90日のRSA 4096ビットサーバー証明書を生成します。
セットアップコンポーネントは、mcp-proxyイメージ内にsetupバイナリとして含まれています。docker compose run --rm setup <subcommand>で実行するか(Compose)、チャートのフックとCronJobに依存します(Helm)。
setup initConsoleで作成したトンネルにアタッチし、CAとサーバー証明書を生成し、CAを登録し、トンネルトークンを取得し、すべての出力を宛先に書き込みます。
| フラグ | 説明 | デフォルト |
|---|---|---|
--api-url | Claude APIのベースURL。API_URLからも読み込まれます。 | 必須 |
--tunnel-id | アタッチするトンネルID(tnl_...)。TUNNEL_IDからも読み込まれます。 | 必須 |
--output | 出力先:dir:/pathまたはk8s-secret:NAME。Helmチャートはk8s-secret:<release>を渡します。 | k8s-secret:mcp-tunnel(Kubernetesポッド内で実行している場合は自動検出、それ以外の場合は必須) |
--cert-duration | サーバー証明書の有効期間。 | 2160h(90日) |
--token-version | 変更検出用の文字列。新しい値を指定すると、再実行時にトークンローテーションがトリガーされます。HelmチャートとComposeの例はどちらも初期値として1を渡します。 | なし |
このコマンドはWorkload Identity Federationを通じて認証します。ANTHROPIC_FEDERATION_RULE_ID、ANTHROPIC_ORGANIZATION_ID、ANTHROPIC_WORKSPACE_ID(オプション)、およびANTHROPIC_IDENTITY_TOKEN_FILEまたはANTHROPIC_IDENTITY_TOKENのいずれか一方を読み込みます。これらの変数の現在のセマンティクスについては、WIFリファレンスを参照してください。セットアップコンポーネントはフェデレーションルールからサービスアカウントを導出するため、ANTHROPIC_SERVICE_ACCOUNT_IDを別途必要としません。
setup renew-cert保存されたCAによって署名された新しいサーバー証明書を発行します。API呼び出しは行いません。
| フラグ | 説明 | デフォルト |
|---|---|---|
--output | 出力先:dir:/pathまたはk8s-secret:NAME。Helmチャートはk8s-secret:<release>を渡します。 | k8s-secret:mcp-tunnel(Kubernetesポッド内で実行している場合は自動検出、それ以外の場合は必須) |
--cert-duration | 新しい証明書の有効期間。 | 2160h(90日) |
--renew-before | 既存の証明書の残り有効期間がこの期間を超える場合、更新をスキップします。 | 0(常に更新) |
--renew-before=720hを設定すると、有効期間が30日以上残っている場合にコマンドが何も実行しなくなるため、固定スケジュールで安全に実行できます。
Was this page helpful?