Référence des tunnels MCP

Configuration du proxy

Le proxy lit sa configuration depuis /etc/mcp-gateway/config.yaml (Compose) ou depuis le ConfigMap rendu (Helm, alimenté à partir de gateway.config.*).

Pour les routes en amont https://, définissez au moins l'un des paramètres upstream.tls.ca_file ou upstream.tls.include_system_cas ; sinon, le proxy ne dispose d'aucune ancre de confiance pour le certificat en amont.

Correspondance des routes

routes est une table de correspondance de chaînes plate (map[string]string), et non une liste. Le proxy recherche d'abord le nom d'hôte entrant par correspondance exacte, puis en supprimant le suffixe tunnel_domain et en faisant correspondre le sous-domaine restant. La correspondance ne prend en compte que le nom d'hôte ; le chemin de la requête et la chaîne de requête sont transmis tels quels au serveur MCP en amont.

Chaque valeur en amont doit être exactement scheme://host:port. Le port est obligatoire. L'inclusion d'un chemin est rejetée au chargement de la configuration avec le message invalid upstream (must be scheme://host:port).

API Tunnels

Consultez la référence de l'API d'administration des tunnels MCP pour tous les points de terminaison, les schémas de requête et de réponse, ainsi que des exemples par langage.

En-têtes requis pour chaque requête :

Exigences relatives aux certificats

Le composant de configuration génère automatiquement des certificats conformes. Ces exigences ne s'appliquent que si vous émettez des certificats via votre propre PKI.

Certificat d'autorité de certification

Téléversez-le avec POST /v1/organizations/tunnels/{tunnel_id}/certificates. Un tunnel peut contenir jusqu'à deux certificats d'autorité de certification actifs à la fois, ce qui permet une rotation sans interruption de service.

• Encodé en PEM, certificat unique, jusqu'à 8 ko.
• Extension BasicConstraints présente avec CA:TRUE, marquée comme critique.
• Extension SubjectKeyIdentifier présente.
• KeyUsage inclut keyCertSign.
• Dans sa période de validité.
• RSA 2048 bits ou plus, ou ECDSA P-256 ou plus, avec une signature SHA-256 ou plus robuste.

Certificat serveur

Présenté par le proxy lors du TLS interne.

• Signé directement par une autorité de certification enregistrée (sans intermédiaires).
• Extension AuthorityKeyIdentifier présente et correspondant au SubjectKeyIdentifier de l'autorité de certification.
• Le Subject Alternative Name inclut un nom DNS correspondant à <route>.<tunnel-domain>. Un caractère générique *.<tunnel-domain> couvre toutes les routes.
• Si l'extension ExtendedKeyUsage est présente, elle inclut serverAuth.
• Dans sa période de validité.
• RSA 2048 bits ou plus, ou ECDSA P-256 ou plus, avec une signature SHA-256 ou plus robuste.

Le composant de configuration génère une autorité de certification ECDSA P-256 avec une validité de cinq ans et un certificat serveur RSA 4096 bits avec un SAN générique et une validité de 90 jours.

Composant de configuration

Le composant de configuration est livré dans l'image mcp-proxy sous la forme du binaire setup. Exécutez-le avec docker compose run --rm setup <subcommand> (Compose) ou appuyez-vous sur les hooks et CronJobs du chart (Helm).

setup init

S'attache au tunnel que vous avez créé dans la Console, génère une autorité de certification et un certificat serveur, enregistre l'autorité de certification, récupère le jeton du tunnel et écrit toutes les sorties vers la destination.

La commande s'authentifie via Workload Identity Federation. Elle lit ANTHROPIC_FEDERATION_RULE_ID, ANTHROPIC_ORGANIZATION_ID, ANTHROPIC_WORKSPACE_ID (facultatif), et exactement l'une des variables ANTHROPIC_IDENTITY_TOKEN_FILE ou ANTHROPIC_IDENTITY_TOKEN. Consultez la référence WIF pour la sémantique actuelle de ces variables ; le composant de configuration dérive le compte de service à partir de la règle de fédération, il ne nécessite donc pas ANTHROPIC_SERVICE_ACCOUNT_ID séparément.

setup renew-cert

Émet un nouveau certificat serveur signé par l'autorité de certification stockée. N'effectue aucun appel d'API.

Définir --renew-before=720h fait de la commande une opération sans effet lorsqu'il reste plus de 30 jours de validité, ce qui permet de l'exécuter en toute sécurité selon un calendrier fixe.