Referência de túneis MCP
Campos de configuração do proxy, a API REST de Tunnels, requisitos de certificado e o componente de setup.
Configuração do proxy
O proxy lê sua configuração de /etc/mcp-gateway/config.yaml (Compose) ou do ConfigMap renderizado (Helm, preenchido a partir de gateway.config.*).
| Campo | Descrição | Padrão |
|---|---|---|
listen_addr | Endereço e porta em que escutar. | Obrigatório |
log_level | Verbosidade de log: debug, info, warn ou error. | info |
shutdown_timeout | Quanto tempo aguardar por requisições em andamento durante o desligamento gracioso. | 30s |
tunnel_domain | Domínio base atribuído ao túnel. Quando definido, a busca de rotas remove esse sufixo dos hostnames recebidos para que as chaves de routes possam ser subdomínios simples (wiki). Quando vazio, as chaves de routes devem ser hostnames completos exatos. | Obrigatório quando as chaves de routes são subdomínios simples |
tls.cert_file | Caminho para o certificado TLS do servidor. | Obrigatório |
tls.key_file | Caminho para a chave privada TLS do servidor. | Obrigatório |
routes | Mapa de subdomínio ou hostname completo para URL upstream. Consulte Correspondência de rotas. | Obrigatório |
upstream.allowed_ips | Faixas CIDR IPv4 ou endereços únicos aos quais o proxy tem permissão para se conectar. Mutuamente exclusivo com disable_ip_validation. | Faixas privadas RFC1918 |
upstream.disable_ip_validation | Desativa totalmente a validação de IP upstream. Mutuamente exclusivo com allowed_ips. | false |
upstream.tls.ca_file | Bundle de CA para validar o TLS upstream. | Nenhum |
upstream.tls.include_system_cas | Confiar também no bundle de CA do sistema para o TLS upstream. | false |
Para rotas upstream https://, defina pelo menos um entre upstream.tls.ca_file ou upstream.tls.include_system_cas; caso contrário, o proxy não terá âncora de confiança para o certificado upstream.
Correspondência de rotas
routes é um mapa plano de strings (map[string]string), não uma lista. O proxy busca o hostname recebido primeiro por correspondência exata e, em seguida, removendo o sufixo tunnel_domain e correspondendo o subdomínio restante. A correspondência considera apenas o hostname; o caminho da requisição e a query string são encaminhados ao servidor MCP upstream sem alterações.
Cada valor upstream deve ser exatamente scheme://host:port. A porta é obrigatória. Incluir um caminho é rejeitado no carregamento da configuração com invalid upstream (must be scheme://host:port).
API de Tunnels
A API REST de Tunnels fica em /v1/tunnels e suporta criar, listar e arquivar túneis, registrar certificados de CA e revelar ou rotacionar o token do túnel. Consulte a referência da API de Tunnels para todos os endpoints, esquemas de requisição e resposta, e exemplos.
Cabeçalhos obrigatórios em toda requisição:
| Cabeçalho | Valor |
|---|---|
Authorization | Bearer <token> (o token obtido via troca WIF) |
anthropic-version | 2023-06-01 |
anthropic-beta | mcp-tunnels-2026-06-22 |
Requisitos de certificado
O componente de setup gera certificados em conformidade automaticamente. Estes requisitos se aplicam apenas se você emitir certificados por meio da sua própria PKI.
Certificado de CA
Faça o upload com POST /v1/tunnels/{tunnel_id}/certificates. Um túnel pode manter até dois certificados de CA ativos ao mesmo tempo, o que permite rotação sem tempo de inatividade.
- Codificado em PEM, certificado único, até 8 kB.
- Extensão
BasicConstraintspresente comCA:TRUE, marcada como crítica. - Extensão
SubjectKeyIdentifierpresente. KeyUsageincluikeyCertSign.- Dentro do seu período de validade.
- RSA de 2048 bits ou maior, ou ECDSA P-256 ou maior, com assinatura SHA-256 ou mais forte.
Certificado do servidor
Apresentado pelo proxy durante o TLS interno.
- Assinado diretamente por uma CA registrada (sem intermediárias).
- Extensão
AuthorityKeyIdentifierpresente e correspondente aoSubjectKeyIdentifierda CA. - O Subject Alternative Name inclui um nome DNS correspondente a
<route>.<tunnel-domain>. Um wildcard*.<tunnel-domain>cobre todas as rotas. - Se a extensão
ExtendedKeyUsageestiver presente, ela incluiserverAuth. - Dentro do seu período de validade.
- RSA de 2048 bits ou maior, ou ECDSA P-256 ou maior, com assinatura SHA-256 ou mais forte.
O componente de setup gera uma CA ECDSA P-256 com validade de cinco anos e um certificado de servidor RSA de 4096 bits com um SAN wildcard e validade de 90 dias.
Componente de setup
O componente de setup é distribuído dentro da imagem mcp-proxy como o binário setup. Execute-o com docker compose run --rm setup <subcommand> (Compose) ou conte com os hooks e CronJobs do chart (Helm).
setup init
Conecta-se a um túnel existente (ou cria um quando nenhum ID de túnel é fornecido), depois gera uma CA e um certificado de servidor, registra a CA, obtém o token do túnel e grava todas as saídas no destino.
| Flag | Descrição | Padrão |
|---|---|---|
--api-url | URL base da Claude API. Também lida de API_URL. | Obrigatório |
--tunnel-id | ID do túnel ao qual se conectar (tnl_...). Também lido de TUNNEL_ID. Quando omitido, um novo túnel é criado; um ID de túnel já armazenado na saída é reutilizado em novas execuções. | Nenhum (cria um túnel) |
--output | Destino de saída: dir:/path ou k8s-secret:NAME. O chart Helm passa k8s-secret:<release>. | k8s-secret:mcp-tunnel (detectado automaticamente ao executar em um pod Kubernetes; obrigatório caso contrário) |
--cert-duration | Período de validade do certificado do servidor. | 2160h (90 dias) |
--token-version | String de detecção de mudança. Um novo valor aciona a rotação do token em uma nova execução. O chart Helm e o exemplo Compose passam ambos 1 como valor inicial. | Nenhum |
O comando se autentica por meio de Workload Identity Federation. Ele lê ANTHROPIC_FEDERATION_RULE_ID, ANTHROPIC_ORGANIZATION_ID, ANTHROPIC_WORKSPACE_ID (opcional) e exatamente um entre ANTHROPIC_IDENTITY_TOKEN_FILE ou ANTHROPIC_IDENTITY_TOKEN. Consulte a referência de WIF para a semântica atual dessas variáveis; o componente de setup deriva a conta de serviço a partir da regra de federação, portanto não requer ANTHROPIC_SERVICE_ACCOUNT_ID separadamente.
setup renew-cert
Emite um novo certificado de servidor assinado pela CA armazenada. Não faz chamadas à API.
| Flag | Descrição | Padrão |
|---|---|---|
--output | Destino de saída: dir:/path ou k8s-secret:NAME. O chart Helm passa k8s-secret:<release>. | k8s-secret:mcp-tunnel (detectado automaticamente ao executar em um pod Kubernetes; obrigatório caso contrário) |
--cert-duration | Período de validade do novo certificado. | 2160h (90 dias) |
--renew-before | Ignora a renovação se o certificado existente tiver mais do que essa duração restante. | 0 (sempre renovar) |
Definir --renew-before=720h torna o comando uma operação nula quando restam mais de 30 dias de validade, portanto é seguro executá-lo em um agendamento fixo.
Was this page helpful?