MCP 隧道目前处于研究预览阶段。申请访问权限以进行试用。
Anthropic Helm chart 将隧道堆栈作为单个 Deployment 安装,并将其附加到您的隧道:可以是 chart 的 setup hook 为您创建的隧道,也可以是您在 Console 中创建的现有隧道。
您需要:
tnl_...)。手动配置始终从 Console 创建的隧道开始;您还需要其隧道令牌和隧道域名。workspace:manage_tunnels 的联合规则。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后续的安装步骤会说明在何处添加相应的路由。
setup 组件通过您的联合规则交换集群的投射 ServiceAccount 令牌,获取隧道令牌,生成 CA 和服务器证书,并将 CA 注册到 Anthropic。每日 CronJob 会根据需要续订服务器证书,因此您无需手动处理任何机密信息。
为集群设置 Workload Identity Federation
按照将 WIF 与 Kubernetes 配合使用注册集群的 OIDC 颁发者并创建联合规则。setup 组件在发布命名空间中以其自己的 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 的默认值;不带协议前缀) |
| Scope | workspace:manage_tunnels |
chart 的默认 audience 是不带协议前缀的 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.yamlsetup 组件作为 Helm pre-install hook Job 运行,因此 helm install 会阻塞直到其完成。成功后 Helm 会自动删除该 Job。如果 helm install 因 hook 错误而失败,请参阅 setup 组件身份验证失败。
当 tunnel.id 为空时,setup 组件会在您的联合规则所指向的工作区中创建隧道(除非您设置了 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重新运行 setup 组件(在升级或令牌轮换期间)会重用存储在此 Secret 中的隧道 ID;它永远不会创建第二个隧道。
api.wif.* 值是标识符,不是机密信息,因此将它们存储在 Helm 发布历史 Secret 中没有风险。静态存储的敏感数据是 setup 组件创建的 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 会为 setup 组件投射一个 Kubernetes ServiceAccount 令牌。要使用来自其他身份提供者(例如 SPIFFE、Vault 或云 SDK sidecar)的令牌,请使用 setup.extraVolumes 和 setup.extraVolumeMounts 挂载它。然后将 api.wif.tokenFile 指向挂载路径。chart 会将 ANTHROPIC_IDENTITY_TOKEN_FILE 设置为该路径,setup 组件会从那里读取令牌。
始终向 helm upgrade 传递 --version,以免意外拉取更新的 chart。
Chart 2.0.0 将隧道 ID 从 api.wif.tunnelId 移至 tunnel.id。升级前,请编辑您的 values.yaml:将 tnl_... 值移至 tunnel.id 并删除 api.wif.tunnelId。不设置 tunnel.id 是安全的(setup 组件在重新运行时会重用已存储在 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 进行升级。setup 组件仅在强制时才会在升级期间重新运行:
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=truesetup 组件使用 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 更新且滚动更新完成之前,任何使用旧令牌重启的 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?