serveur MCP

Présentation générale

Le serveur MCP Zabbix est un processus qui permet aux agents IA d'utiliser Zabbix avec le Model Context Protocol (MCP). Le serveur MCP communique avec les clients MCP et l'API Zabbix.

Avec le serveur MCP, un agent IA peut :

  • Récupérer les groupes de hôtes, les groupes de modèles, les hôtes, les modèles, les éléments, les règles LLD, les interfaces, les macros, les déclencheurs, les problèmes, les périodes de maintenance et les données d'historique des éléments (à l'exception des éléments binaires) ;
  • Effectuer des mises à jour des problèmes : ajouter des commentaires, acquitter ou annuler l'acquittement, modifier la gravité, supprimer ou rétablir la suppression, ou fermer les problèmes ;
  • Créer, mettre à jour et supprimer des périodes de maintenance.

Les jetons d'API Zabbix sont utilisés pour l'autorisation ; les jetons sont envoyés avec chaque requête. L'accès est limité par les permissions du propriétaire du jeton : seuls les données des groupes de hôtes accessibles à cet utilisateur sont visibles, et les actions que l'utilisateur n'est pas autorisé à effectuer sont rejetées.

Le serveur MCP est sans état : aucune session n'est conservée entre les requêtes.

Bien que le serveur MCP Zabbix puisse fonctionner avec des versions antérieures ou ultérieures de Zabbix, sa compatibilité est officiellement prise en charge uniquement avec la même version de Zabbix que celle du serveur MCP lui-même.

Voir également :

Installation

Le paquet officiel zabbix-mcp-server est disponible dans le dépôt Zabbix.

Pour installer le serveur MCP Zabbix à partir des sources, compilez-le avec make.

Pour configurer le serveur MCP Zabbix, mettez à jour les paramètres du fichier de configuration du serveur MCP. Les paramètres FrontendURL et AllowedIP doivent au minimum être définis.

Le fichier de configuration par défaut (zabbix_mcp_server.conf) se trouve dans /etc/zabbix/ ; il interdit les outils qui exposent le plus souvent des données sensibles. Pour activer un outil, supprimez la ligne DenyTool correspondante.

Voir également : Bonnes pratiques de sécurité

Exécution

Pour démarrer le serveur MCP, exécutez :

zabbix_mcp_server -c /etc/zabbix/zabbix_mcp_server.conf

Pour vérifier le fichier de configuration et quitter sans démarrer le serveur, utilisez l'option -T :

zabbix_mcp_server -c /etc/zabbix/zabbix_mcp_server.conf -T

Les options de ligne de commande suivantes sont prises en charge :

Option Description
-c <file> Chemin vers le fichier de configuration.
La valeur par défaut est /etc/zabbix/zabbix_mcp_server.conf.
-T Valider le fichier de configuration et quitter.
-h Afficher les informations d'aide.
-V Afficher le numéro de version.

Lorsque le serveur MCP est installé à partir des sources, une unité systemd doit être créée manuellement, par exemple :

[Unit]
Description=Serveur MCP Zabbix
After=network-online.target

[Service]
User=zabbix
ExecStart=/usr/local/sbin/zabbix_mcp_server -c /etc/zabbix/zabbix_mcp_server.conf
Restart=on-failure

[Install]
WantedBy=multi-user.target

Connexion d’un client MCP

Tout client MCP prenant en charge le transport HTTP Streamable peut être connecté au serveur MCP. Les paramètres suivants sont requis :

Paramètre Valeur
Transport HTTP Streamable
URL https://<host>:<ListenPort>/mcp
En-tête Authorization: Bearer <Zabbix API token>, envoyé avec chaque requête

Chaque utilisateur doit configurer son propre token API.

Pour vérifier la configuration, envoyez une seule requête au serveur MCP :

curl -sS https://mcp.example.com:8443/mcp \
  -H "Authorization: Bearer $ZABBIX_API_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Le code d’état HTTP 200 et une liste des outils disponibles dans la réponse confirment que le serveur MCP est accessible et accepte le token ; la liste indique les outils exposés. Les autres codes d’état indiquent les problèmes suivants :

  • 400 - l’en-tête Accept n’inclut pas les deux types de média requis par le transport ;
  • 401 - l’en-tête Authorization contenant le token est manquant ;
  • 403 - l’adresse du client ne figure pas dans le paramètre AllowedIP.

Approbation et accès aux outils

Si le client MCP prend en charge la sollicitation via formulaire, chaque modification doit être approuvée par l’utilisateur avant d’être envoyée au serveur Zabbix. Le client MCP affiche à l’utilisateur les modifications qui seront effectuées, et la modification est appliquée uniquement si l’utilisateur la confirme ; si l’utilisateur rejette ou ignore la demande, aucune modification n’est effectuée dans Zabbix. Une approbation est valide pendant cinq minutes et uniquement pour la modification exacte qui a été affichée ; pendant cette période, l’approbation peut être réutilisée.

Si le client MCP ne prend pas en charge la sollicitation via formulaire (y compris les clients qui prennent uniquement en charge la sollicitation via URL), les modifications sont appliquées immédiatement, sans approbation. Dans ce cas, limitez les outils d’écriture et les autorisations de l’API Zabbix.

L’approbation est particulièrement importante, car la sortie des outils peut contenir du texte non fiable provenant de systèmes surveillés, susceptible d’influencer un agent.

Utilisez AllowTool, DenyTool, AllowToolRegexp et DenyToolRegexp pour contrôler les outils exposés par le serveur MCP. Les outils refusés ne peuvent être ni appelés ni répertoriés, et les ressources qui leur sont associées ne sont pas accessibles.

Les règles AllowTool, DenyTool, AllowToolRegexp et DenyToolRegexp limitent l’accès MCP, mais ne modifient pas les autorisations du jeton Zabbix. Si l’adresse de l’interface est exposée à un agent IA, celui-ci peut tenter d’envoyer des appels directs à l’API. Gardez l’emplacement de l’interface Zabbix et la configuration du serveur MCP inaccessibles à l’agent afin que les requêtes doivent passer par le serveur MCP et ses contrôles de sécurité.

Bonnes pratiques de sécurité

Jetons API

L’authentification et l’autorisation sont entièrement gérées par Zabbix. Le client MCP envoie un jeton API Zabbix avec chaque requête ; le serveur MCP le transmet sans le stocker ni l’enregistrer dans les journaux, tandis que Zabbix valide le jeton, applique les autorisations et consigne les actions dans le journal d’audit.

Utilisez un jeton distinct, avec le moins de privilèges possible et une date d’expiration, pour chaque agent et chaque utilisateur. Stockez les jetons dans un emplacement sécurisé et renouvelez régulièrement les jetons API.

Chiffrement TLS

Pour empêcher l'envoi des jetons en clair, définissez TLSAccept=cert et spécifiez le certificat et la clé (TLSCertFile et TLSKeyFile), ou exécutez le serveur MCP derrière un proxy inverse de terminaison TLS de confiance et définissez TLSAccept=unencrypted. Le protocole HTTP non chiffré n'est acceptable que sur un réseau de confiance.

Restrictions d’accès

Limitez le paramètre AllowedIP aux adresses des clients MCP de confiance et utilisez les permissions Zabbix pour limiter les actions que les jetons d’API peuvent effectuer.

Le serveur MCP ne fournit pas de limitation du débit des requêtes. Chaque requête MCP entraîne normalement un appel à l’API Zabbix, bien qu’un agent exécuté en boucle puisse tout de même générer une charge importante.

Protection des données sensibles

Les clés d'éléments peuvent contenir des identifiants (par exemple, dans les éléments SSH, JMX, ODBC et agent HTTP), les valeurs des macros peuvent contenir des mots de passe et des chaînes de communauté, les interfaces révèlent des adresses internes, et les valeurs des éléments de journal ou de texte peuvent contenir n'importe quelles données. Pour cette raison, les outils item_get, lld_get, interface_get, macro_get et history_get sont refusés par défaut dans le fichier de configuration fourni.

Pour éviter d'exposer les valeurs sensibles des macros au fournisseur LLM de l'agent connecté, utilisez les macros secrètes ; leurs valeurs ne sont jamais renvoyées par l'API.