Configurer le serveur MCP Remote GitGuardian en self-hosted
Le serveur MCP GitGuardian est actuellement en bêta. Les fonctionnalités et le comportement peuvent évoluer au fur et à mesure de nos itérations basées sur les retours des utilisateurs.
GitGuardian Self-Hosted fournit le serveur MCP Remote comme composant optionnel, sur les installations existing cluster (Helm) et embedded cluster (KOTS). Il s'exécute dans votre propre cluster, à côté de votre instance, de sorte qu'aucun trafic et aucun secret ne quitte jamais votre réseau.
Prérequis :
- GitGuardian Self-Hosted 2026.7.0 ou ultérieur.
- Avec le contrôleur d'ingress
aws_alb, AWS Load Balancer Controller 2.14 ou ultérieur (pour une installation basée sur Helm).
Activer le serveur MCP
Installation basée sur Helm
Ajoutez ce qui suit à votre fichier de valeurs Helm :
mcpServer:
enabled: true
Exécutez ensuite helm upgrade avec la version actuellement installée, afin d'éviter une mise à niveau non souhaitée de votre instance. Utilisez helm ls pour trouver le nom de la release et cette version :
helm upgrade <release-name> -n <namespace> oci://registry.replicated.com/gitguardian/gitguardian --version <installed-version> -f local-values.yaml
Installation basée sur KOTS
Dans la KOTS Admin Console, ouvrez Config, activez l'option MCP server, enregistrez la configuration et déployez la nouvelle version.
Vérifier le déploiement
Une fois le pod en cours d'exécution, le serveur MCP est servi sous le chemin /mcp-server de l'hôte de votre application, sur le même ingress et le même certificat TLS que votre dashboard. Le proxy OAuth est activé par défaut, de sorte que vos développeurs se connectent sur votre propre domaine et qu'aucun token n'a à être distribué.
Connecter un client MCP
Pointez les clients vers l'endpoint /mcp du serveur MCP. Pour Cursor, modifiez ~/.cursor/mcp.json :
{
"mcpServers": {
"GitGuardian": {
"type": "http",
"url": "https://dashboard.gitguardian.mycorp.local/mcp-server/mcp"
}
}
}
Remplacez l'hôte par l'URL de votre propre instance. Claude Desktop, Windsurf et Zed utilisent le même bloc type: http dans leur propre fichier de configuration. Consultez Installation pour les emplacements des fichiers.
Le client ouvre un onglet de navigateur vers votre dashboard lors de sa première connexion. Les outils qu'il expose dépendent alors des permissions du compte qui se connecte, de sorte qu'un développeur et un manager n'obtiennent pas le même ensemble. Consultez la référence des outils.
Connecter via votre propre passerelle MCP
Disponible à partir de GitGuardian Self-Hosted 2026.9.0.
Si vos développeurs accèdent aux serveurs MCP via une passerelle MCP interne (LiteLLM, Kong, une passerelle d'API interne) plutôt que de connecter leurs clients directement, la passerelle exécute elle-même le flux OAuth et enregistre sa propre URL de callback. Le serveur MCP n'accepte que les URL de callback qu'il connaît, de sorte que par défaut cet enregistrement échoue avec invalid_redirect_uri.
Déclarez l'URL de callback de votre passerelle dans vos valeurs Helm :
mcpServer:
oauth:
extraRedirectUris:
- https://mcp-gateway.mycorp.local/oauth/callback
Exécutez ensuite la même commande helm upgrade que dans Activer le serveur MCP. Les connexions directes des clients continuent de fonctionner ; la valeur ne fait qu'ajouter des URL de callback, elle ne remplace jamais celles intégrées.
Deux règles s'appliquent à chaque entrée :
- Il doit s'agir d'une URL
https://absolue sans fragment, sinon le pod du serveur MCP refuse de démarrer plutôt que d'échouer à la première connexion. - Ne listez que des URL sur des hôtes que vous contrôlez. Quiconque reçoit le callback OAuth peut échanger le code d'autorisation contre un token au nom de l'utilisateur qui s'est connecté, alors traitez cette valeur avec le même soin qu'un identifiant.
Ajuster le déploiement
Sur les installations basées sur Helm, les clés les plus utiles en plus de mcpServer.enabled :
| Clé | Objectif | Valeur par défaut |
|---|---|---|
mcpServer.replicas | Nombre fixe de replicas | 1 |
mcpServer.autoscaling.hpa.enabled | Mise à l'échelle avec le HPA Kubernetes | false |
mcpServer.autoscaling.metrics.targetLatency | Latence cible en millisecondes pilotant l'autoscaling | 1000 |
mcpServer.resources | Requêtes et limites de CPU et de mémoire | 250m / 1Gi demandé |
mcpServer.ingress.enabled | Exposer le serveur via l'ingress de l'application | true |
mcpServer.mcpOAuthProxyEnabled | Laisser les clients exécuter OAuth contre votre dashboard | true |
mcpServer.oauth.extraRedirectUris | URL de callback OAuth de votre propre passerelle MCP | [] |
mcpServer.extraEnv | Variables d'environnement supplémentaires transmises au serveur | [] |
La liste complète se trouve dans la référence des valeurs Helm. Pour les variables d'environnement que vous pouvez injecter via mcpServer.extraEnv, consultez la référence de configuration du dépôt du serveur MCP.
Dans un environnement airgapped, mettez en miroir ghcr.io/gitguardian/mcp-server vers votre registry privé avec les autres images GitGuardian. Consultez Installation airgap.
Dépanner
Le client ne peut pas atteindre le serveur. Vérifiez que mcpServer.ingress.enabled est à true et que votre contrôleur d'ingress route le chemin /mcp-server. Sur AWS ALB, confirmez que le Load Balancer Controller est en version 2.14 ou ultérieure.
Le flux OAuth échoue ou redirige vers le mauvais hôte. Le serveur MCP dérive son URL publique de l'hôte de votre application. Assurez-vous que les clients utilisent le même hôte que votre dashboard, et non une adresse de service interne.
Une passerelle échoue à s'enregistrer avec invalid_redirect_uri. Son URL de callback OAuth n'est pas déclarée. Ajoutez-la à mcpServer.oauth.extraRedirectUris (consultez Connecter via votre propre passerelle MCP).
Certains outils sont manquants. Les outils exposés suivent les permissions du compte qui s'est connecté. Vérifiez le rôle et les périmètres d'équipe de ce membre.
Et ensuite
- Référence des outils : les outils que le serveur expose.
- Sécurité : le modèle de permissions et la rédaction des secrets.
