Os túneis MCP estão em prévia de pesquisa. Solicite acesso para experimentá-los.
O Helm chart da Anthropic instala a stack de túnel como um único Deployment e a anexa ao seu túnel: um que o hook de configuração do chart cria para você, ou um túnel existente que você criou no Console.
Você precisa de:
tnl_...). O provisionamento manual sempre começa a partir de um túnel criado no Console; você também precisará do token do túnel e do domínio do túnel.workspace:manage_tunnels.helm e kubectl. A aba Sem acesso programático também usa openssl (1.1.1 ou posterior).api.anthropic.com (443 TCP) e para o tunnel edge (7844 TCP e UDP). Consulte os requisitos de rede completos.gateway.config.routes. Se você ainda não tiver um, use o servidor de exemplo.Se você não tiver um servidor MCP disponível para testes, use este servidor mínimo:
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 }
EOFAs etapas de instalação a seguir indicam onde adicionar a rota correspondente.
O componente de configuração troca o token de ServiceAccount projetado do cluster por meio da sua regra de federação, busca o token do túnel, gera uma CA e um certificado de servidor e registra a CA na Anthropic. Um CronJob diário renova o certificado de servidor conforme necessário, para que você não manipule nenhum segredo manualmente.
Configure Workload Identity Federation para o cluster
Siga Use WIF com Kubernetes para registrar o emissor OIDC do seu cluster e criar uma regra de federação. O componente de configuração é executado sob seu próprio ServiceAccount no namespace do release; o nome exato segue a convenção fullname do Helm, então, para qualquer nome de release diferente de mcp-tunnel, execute helm template <release> ... | grep -A2 'kind: ServiceAccount' para confirmá-lo antes de criar a regra. O restante deste guia assume o nome de release mcp-tunnel no namespace mcp-tunnel, onde o ServiceAccount é mcp-tunnel-setup.
| Campo | Valor |
|---|---|
| Subject | system:serviceaccount:mcp-tunnel:mcp-tunnel-setup |
| Audience | api.anthropic.com (o padrão do chart; sem esquema) |
| Scope | workspace:manage_tunnels |
O audience padrão do chart é api.anthropic.com sem esquema, mas o formulário de regra de federação do Console sugere https://api.anthropic.com. Os dois devem corresponder byte a byte ou a autenticação falha. Defina o audience da regra como api.anthropic.com, ou defina api.wif.audience no values.yaml como https://api.anthropic.com.
Se o túnel estiver em um workspace diferente do padrão da organização, adicione também a service account da regra como membro desse workspace em Settings > Workspaces (a API de Tunnels autoriza com base nas associações de workspace da service account).
Anote o ID da regra (fdrl_...); você o definirá como api.wif.federationRuleId.
O CronJob diário de renovação de certificado usa um ServiceAccount separado (também derivado do fullname do Helm), mas não chama a API de Tunnels; ele renova o certificado localmente e só precisa do RBAC do Kubernetes, que o chart concede. A regra de federação não precisa cobri-lo.
Busque os valores padrão
helm show values \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 2.0.1 > values.yamlConfigure a anexação do túnel e as rotas
Edite o values.yaml e defina as chaves api.wif.* com o ID da regra de federação e o ID da organização, além de uma entrada em routes para cada servidor MCP upstream:
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:8080Com essas rotas, Claude alcança os servidores em docs.<your-tunnel-domain> e search.<your-tunnel-domain>. Algumas distribuições gerenciadas de Kubernetes alocam o CIDR de Service fora dos intervalos privados padrão; se suas rotas apontarem para Services dentro do cluster, adicione gateway.config.upstream.allowed_ips aqui conforme Validação de IP upstream.
Se você estiver usando o servidor MCP de exemplo, defina routes como echo: http://hello-mcp:9000 em vez disso.
Revise os manifestos renderizados
Renderize o chart e revise a saída de acordo com as práticas de verificação da sua organização:
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.yamlInstale
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.yamlO componente de configuração é executado como um Job de hook pre-install do Helm, então helm install bloqueia até que ele seja concluído. Em caso de sucesso, o Helm exclui o Job automaticamente. Se helm install falhar com um erro de hook, consulte Falhas de autenticação do componente de configuração.
Quando tunnel.id está vazio, o componente de configuração cria o túnel no workspace que sua regra de federação tem como alvo (o workspace padrão da organização, a menos que você defina api.wif.workspaceId) e armazena seu ID e domínio no Secret mcp-tunnel. Encontre o domínio de que você precisará para a verificação na página de detalhes do túnel no Console em Manage > MCP tunnels, ou leia-o a partir do Secret:
kubectl -n mcp-tunnel get secret mcp-tunnel \
-o jsonpath='{.data.tunnel-domain}' | base64 -dExecutar novamente o componente de configuração (durante upgrades ou rotação de token) reutiliza o ID do túnel armazenado neste Secret; ele nunca cria um segundo túnel.
Os valores api.wif.* são identificadores, não segredos, portanto armazená-los nos Secrets de histórico de release do Helm não é um risco. Os dados sensíveis em repouso são o Secret mcp-tunnel que o componente de configuração cria, que contém o token do túnel e as chaves privadas TLS. Aplique as práticas padrão da sua organização para proteger Secrets do Kubernetes a este namespace.
Verifique de ponta a ponta a partir do lado da Anthropic: use https://<route>.<your-tunnel-domain>/<path> em uma sessão de Managed Agent ou em uma requisição da Messages API, onde <route> é uma chave de gateway.config.routes e <path> é o que quer que o servidor MCP upstream sirva. Com o servidor MCP de exemplo, isso é https://echo.<your-tunnel-domain>/mcp. Consulte Use os servidores MCP tunelados para os formatos de requisição.
Se isso falhar, verifique os logs do pod (kubectl -n mcp-tunnel logs deploy/mcp-tunnel -c mcp-proxy e -c cloudflared) e consulte Solução de problemas.
O ingress para o pod do proxy é negado por padrão (networkPolicy.ingress.enabled: true). Para restringir adicionalmente o egress do pod, defina networkPolicy.egress.enabled: true e preencha networkPolicy.egress.mcpServers com seletores de label de pod ou intervalos CIDR que cubram seus servidores MCP upstream. O egress do cloudflared para o tunnel edge é permitido separadamente por meio de networkPolicy.egress.cloudflaredEgressCIDRs.
Os campos em gateway.config.* são repassados para o arquivo de configuração do proxy. Ajustes comuns incluem upstream.allowed_ips, log_level e upstream.tls. Consulte a referência de configuração do proxy para a lista completa de campos. O chart sempre define listen_addr, tls.cert_file e tls.key_file; defini-los em gateway.config não tem efeito.
Por padrão, o chart projeta um token de ServiceAccount do Kubernetes para o componente de configuração. Para usar um token de um provedor de identidade diferente (como SPIFFE, Vault ou um sidecar de SDK de nuvem), monte-o com setup.extraVolumes e setup.extraVolumeMounts. Em seguida, aponte api.wif.tokenFile para o caminho de montagem. O chart define ANTHROPIC_IDENTITY_TOKEN_FILE para esse caminho, e o componente de configuração lê o token a partir dele.
Sempre passe --version para helm upgrade para não baixar um chart mais novo inesperadamente.
O chart 2.0.0 move o ID do túnel de api.wif.tunnelId para tunnel.id. Antes de fazer o upgrade, edite seu values.yaml: mova o valor tnl_... para tunnel.id e remova api.wif.tunnelId. Deixar tunnel.id sem definição é seguro (o componente de configuração reutiliza o ID do túnel já armazenado no Secret mcp-tunnel ao ser executado novamente), mas a mudança explícita mantém seu values.yaml preciso. Atualize também o escopo da sua regra de federação de org:manage_tunnels para workspace:manage_tunnels no Console.
Para alterações de rotina, como rotas, número de réplicas ou 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.yamlMantenha um values.yaml completo em vez de depender de --reuse-values. O comportamento de deep-merge do Helm pode falhar silenciosamente em remover rotas excluídas.
Com acesso programático, incremente tunnel.tokenVersion no values.yaml e faça o upgrade com --set setup.force=true. O componente de configuração só é executado novamente em upgrades quando forçado:
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=trueO componente de configuração se autentica com Workload Identity Federation; não há token de API para revogar.
Sem acesso programático, clique em Rotate token na página de detalhes do túnel no Console e, em seguida, atualize o Secret mcp-tunnel-token:
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-tunnelClicar em Rotate token invalida o token atual imediatamente. Até que o Secret seja atualizado e o rollout seja concluído, qualquer pod que reinicie com o token antigo (eviction, node drain, OOM) não consegue se reconectar. Atualize o Secret prontamente após a rotação; para requisitos de disponibilidade mais rigorosos, use acesso programático para que o chart trate a rotação de forma atômica.
O chart fornece automação, mas você continua responsável por monitorar a expiração e confirmar que a renovação foi concluída.
Com acesso programático, a renovação de certificado é automática. O chart implanta um CronJob (nomeado a partir do fullname do Helm, com o sufixo -cert-renew) que executa setup renew-cert diariamente (em serverCert.cronSchedule, padrão 0 0 * * * UTC). O job não tem efeito a menos que o certificado esteja dentro de serverCert.renewBefore da expiração (padrão 30 dias). A renovação é local: o job assina um novo certificado com a CA já armazenada no Secret, não faz chamadas de API e só precisa do RBAC do Kubernetes que o chart concede. O proxy recarrega o certificado a quente a partir da montagem do Secret, portanto não é necessário reiniciar o Deployment.
Sem acesso programático, não há CronJob. De dentro do diretório mcp-tunnel/ que você manteve após a instalação, assine um novo certificado de servidor com a CA existente (não regenere a 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 -O proxy recarrega o certificado a quente a partir da montagem do Secret.
Anexe um servidor MCP upstream a um Managed Agent ou à Messages API.
Orientações de hardening, rotação de credenciais e resposta a violações.
Diagnostique problemas de conectividade, TLS e roteamento.
Was this page helpful?