MCP 通道目前處於研究預覽階段。申請存取權限以進行試用。
Anthropic Helm chart 會將通道堆疊安裝為單一 Deployment,並將其附加到您的通道:可以是 chart 的設定掛鉤(setup hook)為您建立的通道,或是您在 Console 中建立的現有通道。
您需要:
tnl_...)。手動佈建一律從 Console 建立的通道開始;您還需要其通道權杖(tunnel token)和通道網域(tunnel domain)。workspace:manage_tunnels 的聯合規則(federation rule)。helm 和 kubectl 部署到該叢集。不使用程式化存取分頁也會使用 openssl(1.1.1 或更新版本)。api.anthropic.com(443 TCP)和通道邊緣(7844 TCP 和 UDP)的對外網路連線。 請參閱完整的網路需求。gateway.config.routes 下設定的位址存取。如果您還沒有,請使用範例伺服器。如果您沒有可用於測試的 MCP 伺服器,請使用這個最小化的伺服器:
kubectl create namespace mcp-tunnel --dry-run=client -o yaml | kubectl apply -f -
kubectl -n mcp-tunnel apply -f - <<'EOF'
apiVersion: v1
kind: ConfigMap
metadata:
name: hello-mcp-src
data:
hello_server.py: |
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("hello-server", host="0.0.0.0", port=9000)
@mcp.tool()
def hello(name: str = "world") -> str:
"""Say hello to someone."""
return f"Hello, {name}!"
if __name__ == "__main__":
mcp.run(transport="streamable-http")
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-mcp
spec:
replicas: 1
selector:
matchLabels: { app: hello-mcp }
template:
metadata:
labels: { app: hello-mcp }
spec:
containers:
- name: hello-mcp
image: python:3.13-slim
command: ["sh", "-c", "pip install --quiet mcp && python /app/hello_server.py"]
volumeMounts:
- { name: src, mountPath: /app }
ports:
- { containerPort: 9000 }
volumes:
- name: src
configMap: { name: hello-mcp-src }
---
apiVersion: v1
kind: Service
metadata:
name: hello-mcp
spec:
selector: { app: hello-mcp }
ports:
- { port: 9000, targetPort: 9000 }
EOF接下來的安裝步驟會說明在何處新增對應的路由。
設定元件透過您的聯合規則交換叢集的投射 ServiceAccount 權杖、擷取通道權杖、產生 CA 和伺服器憑證,並向 Anthropic 註冊 CA。每日的 CronJob 會視需要更新伺服器憑證,因此您不需要手動處理任何機密資料。
為叢集設定 Workload Identity Federation
依照在 Kubernetes 中使用 WIF 註冊叢集的 OIDC 簽發者並建立聯合規則。設定元件在發行命名空間中以自己的 ServiceAccount 執行;確切名稱遵循 Helm 的 fullname 慣例,因此對於 mcp-tunnel 以外的任何發行名稱,請在建立規則之前執行 helm template <release> ... | grep -A2 'kind: ServiceAccount' 來確認。本指南的其餘部分假設發行名稱為 mcp-tunnel,命名空間為 mcp-tunnel,其中 ServiceAccount 為 mcp-tunnel-setup。
| 欄位 | 值 |
|---|---|
| Subject | system:serviceaccount:mcp-tunnel:mcp-tunnel-setup |
| Audience | api.anthropic.com(chart 的預設值;不含 scheme) |
| Scope | workspace:manage_tunnels |
chart 的預設 audience 是不含 scheme 的 api.anthropic.com,但 Console 的聯合規則表單建議使用 https://api.anthropic.com。兩者必須逐位元組完全相符,否則驗證會失敗。請將規則的 audience 設為 api.anthropic.com,或將 values.yaml 中的 api.wif.audience 設為 https://api.anthropic.com。
如果通道位於組織預設工作區以外的工作區,還需在 Settings > Workspaces 下將規則的服務帳戶新增為該工作區的成員(Tunnels API 會根據服務帳戶的工作區成員資格進行授權)。
記下規則的 ID(fdrl_...);您將把它設為 api.wif.federationRuleId。
每日的憑證更新 CronJob 使用獨立的 ServiceAccount(同樣衍生自 Helm fullname),但不會呼叫 Tunnels API;它在本機更新憑證,只需要 chart 授予的 Kubernetes RBAC。聯合規則不需要涵蓋它。
擷取預設值
helm show values \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 2.0.1 > values.yaml設定通道附加與路由
編輯 values.yaml 並設定 api.wif.* 鍵,填入聯合規則 ID 和組織 ID,並為每個上游 MCP 伺服器新增一個 routes 項目:
api:
wif:
federationRuleId: "fdrl_..."
organizationId: "00000000-0000-0000-0000-000000000000"
# Set when the tunnel is in a non-default workspace and the
# rule's service account is a member of that workspace.
# workspaceId: "wrkspc_..."
tunnel:
# Leave empty to have the setup hook create a tunnel during install.
# Set to attach to an existing tunnel from the Console.
id: ""
# Increment to rotate the tunnel token on the next upgrade.
# See the "Rotate the tunnel token" section.
tokenVersion: "1"
gateway:
config:
routes:
docs: http://docs-mcp.internal:8080
search: http://search-mcp.internal:8080使用這些路由,Claude 可透過 docs.<your-tunnel-domain> 和 search.<your-tunnel-domain> 存取伺服器。某些受管理的 Kubernetes 發行版會將 Service CIDR 配置在標準私有範圍之外;如果您的路由指向叢集內的 Service,請依照上游 IP 驗證在此處新增 gateway.config.upstream.allowed_ips。
如果您使用的是範例 MCP 伺服器,請改將 routes 設為 echo: http://hello-mcp:9000。
檢閱渲染後的資訊清單
渲染 chart 並依照您組織的審查慣例檢閱輸出:
helm template mcp-tunnel \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 2.0.1 \
-n mcp-tunnel \
-f values.yaml > rendered.yaml安裝
helm install mcp-tunnel \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 2.0.1 \
--namespace mcp-tunnel --create-namespace \
-f values.yaml設定元件以 Helm pre-install 掛鉤 Job 的形式執行,因此 helm install 會阻塞直到其完成。成功後 Helm 會自動刪除該 Job。如果 helm install 因掛鉤錯誤而失敗,請參閱設定元件驗證失敗。
當 tunnel.id 為空時,設定元件會在您的聯合規則所指向的工作區中建立通道(除非您設定 api.wif.workspaceId,否則為組織的預設工作區),並將其 ID 和網域儲存在 mcp-tunnel Secret 中。您可以在 Console 的 Manage > MCP tunnels 下的通道詳細資訊頁面找到驗證所需的網域,或從 Secret 中讀取:
kubectl -n mcp-tunnel get secret mcp-tunnel \
-o jsonpath='{.data.tunnel-domain}' | base64 -d重新執行設定元件(在升級或權杖輪替期間)會重複使用儲存在此 Secret 中的通道 ID;它永遠不會建立第二個通道。
api.wif.* 值是識別碼,不是機密資料,因此將它們儲存在 Helm 發行歷史 Secret 中沒有風險。靜態儲存的敏感資料是設定元件建立的 mcp-tunnel Secret,其中包含通道權杖和 TLS 私鑰。請將您組織保護 Kubernetes Secret 的標準做法套用到此命名空間。
從 Anthropic 端進行端對端驗證:在 Managed Agent 工作階段或 Messages API 請求中使用 https://<route>.<your-tunnel-domain>/<path>,其中 <route> 是 gateway.config.routes 中的一個鍵,<path> 是上游 MCP 伺服器提供服務的路徑。使用範例 MCP 伺服器時,即為 https://echo.<your-tunnel-domain>/mcp。請參閱使用通道化的 MCP 伺服器了解請求格式。
如果失敗,請檢查 pod 日誌(kubectl -n mcp-tunnel logs deploy/mcp-tunnel -c mcp-proxy 和 -c cloudflared)並參閱疑難排解。
預設情況下,進入代理 pod 的流量會被拒絕(networkPolicy.ingress.enabled: true)。若要額外限制 pod 的對外流量,請將 networkPolicy.egress.enabled 設為 true,並在 networkPolicy.egress.mcpServers 中填入涵蓋您上游 MCP 伺服器的 pod 標籤選擇器或 CIDR 範圍。從 cloudflared 到通道邊緣的對外流量透過 networkPolicy.egress.cloudflaredEgressCIDRs 另行允許。
gateway.config.* 下的欄位會直接傳遞到代理設定檔。常見的調整包括 upstream.allowed_ips、log_level 和 upstream.tls。請參閱代理設定參考以取得完整的欄位清單。chart 一律會設定 listen_addr、tls.cert_file 和 tls.key_file;在 gateway.config 中設定它們不會有任何效果。
預設情況下,chart 會為設定元件投射一個 Kubernetes ServiceAccount 權杖。若要使用來自不同身分提供者的權杖(例如 SPIFFE、Vault 或雲端 SDK sidecar),請使用 setup.extraVolumes 和 setup.extraVolumeMounts 掛載它。然後將 api.wif.tokenFile 指向掛載路徑。chart 會將 ANTHROPIC_IDENTITY_TOKEN_FILE 設為該路徑,設定元件會從那裡讀取權杖。
一律將 --version 傳遞給 helm upgrade,以免意外拉取較新的 chart。
Chart 2.0.0 將通道 ID 從 api.wif.tunnelId 移至 tunnel.id。升級前,請編輯您的 values.yaml:將 tnl_... 值移至 tunnel.id 並移除 api.wif.tunnelId。不設定 tunnel.id 是安全的(設定元件在重新執行時會重複使用已儲存在 mcp-tunnel Secret 中的通道 ID),但明確移動可讓您的 values.yaml 保持準確。另外,請在 Console 中將聯合規則的範圍從 org:manage_tunnels 更新為 workspace:manage_tunnels。
對於路由、副本數量或 NetworkPolicy 等例行變更:
helm upgrade mcp-tunnel \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 2.0.1 \
-n mcp-tunnel \
-f values.yaml請維護完整的 values.yaml,而不是依賴 --reuse-values。Helm 的深度合併行為可能會在不發出警告的情況下無法移除已刪除的路由。
使用程式化存取時,在 values.yaml 中遞增 tunnel.tokenVersion,並使用 --set setup.force=true 進行升級。設定元件只有在強制時才會在升級時重新執行:
helm upgrade mcp-tunnel \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 2.0.1 \
-n mcp-tunnel \
-f values.yaml \
--set setup.force=true設定元件使用 Workload Identity Federation 進行驗證;沒有需要撤銷的 API 權杖。
不使用程式化存取時,請在 Console 的通道詳細資訊頁面上點擊 Rotate token,然後更新 mcp-tunnel-token Secret:
kubectl -n mcp-tunnel create secret generic mcp-tunnel-token \
--from-literal=tunnel-token='eyJ...' --dry-run=client -o yaml | kubectl apply -f -
kubectl -n mcp-tunnel rollout restart deploy/mcp-tunnel點擊 Rotate token 會立即使目前的權杖失效。在 Secret 更新且推出(rollout)完成之前,任何使用舊權杖重新啟動的 pod(驅逐、節點排空、OOM)都無法重新連線。輪替後請立即更新 Secret;對於更嚴格的可用性需求,請使用程式化存取,讓 chart 以原子方式處理輪替。
chart 提供自動化功能,但您仍需負責監控到期時間並確認更新完成。
使用程式化存取時,憑證更新是自動的。chart 會部署一個 CronJob(以 Helm fullname 命名,後綴為 -cert-renew),每天執行 setup renew-cert(依照 serverCert.cronSchedule,預設為 0 0 * * * UTC)。除非憑證在距離到期 serverCert.renewBefore 的時間內(預設 30 天),否則該作業不會有任何作用。更新是在本機進行的:該作業使用已儲存在 Secret 中的 CA 簽署新憑證,不進行任何 API 呼叫,只需要 chart 授予的 Kubernetes RBAC。代理會從 Secret 掛載熱重載憑證,因此不需要重新啟動 Deployment。
不使用程式化存取時則沒有 CronJob。從您在安裝後保留的 mcp-tunnel/ 目錄內,使用現有的 CA 簽署新的伺服器憑證(不要重新產生 CA):
export TUNNEL_DOMAIN=YOUR_TUNNEL_DOMAIN_HERE
openssl req -new -key data/tls.key -out /tmp/server.csr \
-subj "/CN=${TUNNEL_DOMAIN}"
openssl x509 -req -in /tmp/server.csr \
-CA data/ca.crt -CAkey data/ca.key -CAcreateserial \
-out data/tls.crt -days 90 -extfile data/tls.ext
kubectl -n mcp-tunnel create secret generic mcp-tunnel-cert \
--from-file=tls.crt=data/tls.crt --from-file=tls.key=data/tls.key \
--dry-run=client -o yaml | kubectl apply -f -代理會從 Secret 掛載熱重載憑證。
Was this page helpful?