Configurer le serveur GitGuardian Remote MCP en Self-Hosted
Le serveur GitGuardian MCP est actuellement en beta. Les fonctionnalités et le comportement peuvent évoluer au fur et à mesure de nos itérations basées sur les retours des utilisateurs.
Le chart Helm GitGuardian Self-Hosted fournit le serveur Remote MCP en tant que composant optionnel. Il s'exécute dans votre propre cluster, à côté de votre instance, de sorte qu'aucun trafic ni aucun secret ne quitte jamais votre réseau.
Prérequis :
- GitGuardian Self-Hosted 2026.7.0 ou version ultérieure.
- Avec le contrôleur d'ingress
aws_alb, AWS Load Balancer Controller 2.14 ou version ultérieure (pour une installation basée sur Helm).
Activer le serveur MCP
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
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 besoin d'être distribué.
Connecter un client MCP
Pointez les clients vers le point de terminaison /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 acceptent le même bloc type: http dans leur propre fichier de configuration. Consultez Installation pour connaître 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 ensuite dépendent 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 API interne) plutôt qu'en connectant 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, donc 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 absolue
https://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
Les clés les plus utiles, en plus de mcpServer.enabled :
| Clé | Objectif | Valeur par défaut |
|---|---|---|
mcpServer.replicas | Nombre fixe de réplicas | 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és |
mcpServer.ingress.enabled | Exposer le serveur via l'ingress de l'application | true |
mcpServer.mcpOAuthProxyEnabled | Laisser les clients exécuter OAuth sur votre dashboard | true |
mcpServer.oauth.extraRedirectUris | URL de callback OAuth de votre propre passerelle MCP | [] |
mcpServer.extraEnv | Variables d'environnement supplémentaires passées 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 registre privé avec les autres images GitGuardian. Consultez Installation airgap.
Résoudre les problèmes
Le client ne parvient pas à joindre 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 ne parvient pas à s'enregistrer avec invalid_redirect_uri. Son URL de callback OAuth n'est pas déclarée. Ajoutez-la à mcpServer.oauth.extraRedirectUris (voir 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 censure des secrets.
