Connecter une IA à VMware avec MCP : commencer en lecture seule

Ce qu’une connexion MCP à vCenter apporte vraiment

Un administrateur peut demander un inventaire lisible, comparer des VM ou préparer des questions pour une migration sans copier manuellement chaque écran. Le modèle formule une demande; le serveur MCP appelle l’API autorisée; le modèle résume les résultats. La qualité du résumé dépend des données retournées et de leur portée.

Commencez avec un objectif limité : comprendre les VM d’un environnement de laboratoire. Gardez l’exécution des changements dans votre procédure habituelle. Les exemples utilisent des noms fictifs et ne nécessitent aucun accès aux systèmes invités.

1. Choisir un serveur précis plutôt qu’un nom générique

MCP est un protocole, pas une API VMware universelle. Un serveur pour VMware Workstation ne couvre pas nécessairement vCenter ou ESXi. Examinez le dépôt primaire, son propriétaire, les dépendances, la licence, les tests et les outils avant installation.

Ce guide prend michaelrice/vcenter-mcp comme cas d’étude communautaire. Son manifeste annonce Python ≥3.10, la version 0.1.0, Apache-2.0 et des dépendances mcp/pyVmomi. Ces éléments ne constituent ni une certification Broadcom ni une matrice de compatibilité. Inscrivez votre build vCenter/ESXi, version Python, version du client et SHA du serveur dans la fiche du pilote.

Le dépôt ne fournit pas ici une garantie générale de compatibilité pour toutes les versions vSphere. Validez votre cible avec le propriétaire de la plateforme; conservez les licences et droits API nécessaires. Le client IA a ses propres conditions d’abonnement et de traitement des données, à évaluer séparément.

• Dépôt primaire vcenter-mcp ↗
• Manifeste et dépendances ↗

2. Définir la frontière de lecture

Le projet documente list_vms, mais aussi create_vm, power_on_vm, power_off_vm et delete_vm. Son inventaire est donc exploitable pour un pilote de lecture; le serveur complet doit être traité comme capable d’écriture.

Deux contrôles se complètent. D’abord, une variante revue ou une passerelle de confiance doit n’exposer et n’accepter que l’outil retenu. Ensuite, le compte vSphere doit refuser toute opération d’écriture. Un outil masqué dans l’interface mais encore appelable ne constitue pas une restriction serveur.

Ne supposez pas qu’un paramètre READ_ONLY existe. Si le projet ne propose pas le filtrage voulu, faites une modification versionnée et testée ou choisissez une autre implémentation. Vérifiez tools/list et le chemin tools/call : les deux doivent appliquer la même liste d’autorisation.

3. Créer une identité vSphere limitée et vérifier les droits effectifs

Créez un compte dédié, par exemple svc-ai-inventory, selon votre fournisseur d’identité approuvé. Affectez le rôle Read-only à la portée minimale permettant la collecte retenue; vérifiez les objets parents nécessaires et la propagation. Un filtre datacenter dans une requête ne remplace pas une permission vSphere.

Broadcom distingue privilèges, rôles et permissions par objet. Examinez les affectations directes, héritées et de groupe : une autre appartenance peut élargir les droits. Ne donnez ni rôle Administrateur global, ni identifiants ESXi root, ni mot de passe invité.

Testez positivement la visibilité des objets du pilote et négativement les objets hors périmètre. Contrôlez les privilèges effectifs avec un administrateur autorisé. Les essais d’écriture refusée doivent rester dans un laboratoire jetable; ne lancez pas une suppression en production simplement pour démontrer qu’elle échoue.

• Broadcom : AuthorizationManager, rôles et permissions ↗

4. Préparer un hôte de gestion et une installation reproductible

Installez sur un poste de gestion protégé ou une VM dédiée qui joint vCenter par son nom DNS et HTTPS. Évitez les comptes locaux privilégiés pour exécuter le processus. Limitez l’accès aux dossiers, les destinations réseau et les autres outils accessibles à l’agent.

Les commandes suivantes installent des dépendances et changent l’hôte : elles ne sont pas une collecte en lecture seule. Remplacez le SHA fictif avant exécution. Conservez une liste verrouillée des dépendances approuvées; pip freeze est un relevé, pas un audit de vulnérabilité. Ne copiez pas l’exemple avec le placeholder tel quel.

Avant connexion au client, préparez et testez la restriction des outils et la validation TLS décrites ci-dessous. Une installation réussie ne vaut pas approbation pour la production.

# CHANGE: isolated lab installation after source review.
git clone https://github.com/michaelrice/vcenter-mcp.git /opt/lab/vcenter-mcp
cd /opt/lab/vcenter-mcp
# Pin the reviewed source; replace the placeholder with a full approved SHA.
git switch --detach <APPROVED_COMMIT_SHA>
python3 -m venv .venv
.venv/bin/python -m pip install -e .
.venv/bin/python -m pip freeze
# Configure only the dedicated read-only identity:
.venv/bin/python -m vcenter_mcp setup

5. Protéger TLS et les secrets avant le premier inventaire

Le README signale un contexte SSL non vérifié par défaut et un fichier de configuration contenant le mot de passe. Ces choix exigent une adaptation pour l’entreprise. Un réseau interne ne garantit pas l’identité du serveur.

Faites valider le certificat et le nom DNS de la cible par le SDK. Le fragment suivant illustre le contexte Python attendu; il doit être intégré au véritable appel de connexion dans la version revue. Testez une CA non approuvée et un nom incorrect : les deux doivent échouer avant authentification.

Le fichier de CA contient des certificats publics de confiance, pas de clé privée. Protégez le secret du compte dans votre mécanisme approuvé, ou limitez strictement le fichier de configuration si l’implémentation l’exige. N’exposez ni fichier, ni variables de secrets, ni traces d’authentification à un outil de lecture de fichiers de l’agent.

• Ne placez pas le mot de passe dans une ligne de commande, un dépôt ou un prompt.
• Restreignez le compte OS du processus et les permissions du fichier.
• Préparez rotation, révocation et contrôle des sessions existantes.
• Conservez des journaux sans secrets et une rétention définie.

# Design example: integrate into the reviewed connection helper.
# Does NOT patch the project automatically.
import ssl
context = ssl.create_default_context(
    cafile="/etc/company-pki/vcenter-trust.pem"
)
# Pass this context to the actual SDK connection.
# Keep hostname verification enabled and connect with the certificate DNS name.

6. Connecter un client local avec le bon transport

L’exemple utilise Claude Code et un processus stdio local. Le client lance Python avec un chemin absolu; ce processus utilise ensuite le réseau vers vCenter. Aucun port MCP public n’est nécessaire pour ce scénario.

Anthropic documente les connexions stdio et les portées de configuration. Choisissez une portée locale pour le pilote. Une inscription MCP ne limite pas automatiquement les droits du SDK; validez les contrôles précédents avant de la lancer.

Un client cloud ne peut pas simplement exécuter un Python de votre réseau local. Un scénario distant demande un serveur qui prend réellement en charge le transport compatible, une authentification, HTTPS et des règles d’accès. Ce guide ne transforme pas ce projet en connecteur HTTP/OAuth et ne promet pas une configuration identique pour tous les clients.

# CHANGE: register only the hardened, reviewed lab build.
claude mcp add --transport stdio --scope local vcenter-lab -- \
  /opt/lab/vcenter-mcp/.venv/bin/python -m vcenter_mcp
# Read local connector status:
claude mcp list
claude mcp get vcenter-lab

• Anthropic : connexions MCP dans Claude Code ↗

7. Valider outils, données et erreurs avant les prompts

Lancez d’abord la découverte des outils dans le client. Comparez noms et schémas à votre build approuvé. Refusez toute différence inexpliquée après une mise à jour. La spécification MCP définit les échanges tools/list et tools/call; les annotations de sécurité ne sont pas une preuve d’autorisation.

Comparez un petit inventaire au vSphere Client avec le même périmètre. Une réponse vide peut provenir d’un manque de visibilité, d’une cible erronée ou d’un échec; ne la traduisez pas automatiquement en « aucune VM ». Gardez les erreurs visibles.

Le cas d’étude sert à l’inventaire des VM. Ne demandez pas un historique de performance, un état des sauvegardes ou une liste de snapshots si votre outil ne les fournit pas. Une IP absente ou un état invité incomplet nécessite de vérifier la source avant de conclure.

• Spécification MCP : outils, schémas et annotations ↗

8. Trois prompts utiles pour un pilote

Ces demandes structurent un rapport, sans créer une preuve de sécurité, de capacité ou de conformité. Relisez le résultat avec l’administrateur responsable. Limitez la taille des retours et la fréquence des requêtes pour éviter de surcharger vCenter ou le contexte du modèle.

• « Avec l’inventaire autorisé de lab-vcenter, prépare un tableau des VM visibles et de leur état. Indique la cible, la portée, l’heure de collecte et les champs manquants. »
• « Compare APP-LAB-01 et APP-LAB-02 uniquement avec les valeurs retournées. Distingue différence observée et hypothèse. Ne propose aucune exécution de changement. »
• « Prépare des questions de validation pour une migration à partir de cet inventaire. Pour chaque question, indique les informations supplémentaires nécessaires; ne déduis pas la compatibilité de l’application depuis le nom de la VM. »

9. Traiter l’inventaire comme une entrée non fiable

Un nom de VM, une annotation ou un texte retourné peut contenir une instruction malveillante. Le modèle doit traiter ces valeurs comme des données, jamais comme une autorisation de lancer une commande, lire un secret ou appeler un autre connecteur.

Une consigne « lecture seule » dans le prompt aide le comportement, mais la protection vient des permissions, du filtrage et de l’isolation. Ne partagez pas avec cette session des connecteurs de messagerie, un shell privilégié ou des identifiants invités sans besoin précis.

Même un inventaire en lecture peut révéler topologie, noms et adresses. Décidez quels champs peuvent quitter votre environnement, quels modèles sont autorisés et quelle rétention s’applique. Un serveur MCP local n’implique pas un modèle IA local; les résultats peuvent être envoyés au fournisseur du client.

10. Pilote, journalisation et retour arrière

Documentez propriétaire, objectif, build, SHA, identité et objets visibles. Mesurez la charge, les erreurs et la fidélité du rapport. Journalisez outil, cible, statut, durée et utilisateur du client sans enregistrer les secrets.

En laboratoire, vérifiez que la lecture fonctionne, qu’un outil non autorisé est rejeté, qu’un certificat incorrect échoue et qu’un objet hors périmètre est inaccessible. Testez une donnée contenant une instruction trompeuse et confirmez qu’aucune action additionnelle n’est exécutée.

Pour revenir en arrière, retirez la configuration MCP du client, arrêtez le processus et révoquez le compte ou ses permissions selon le plan. Vérifiez la fermeture des sessions côté plateforme; une rotation de mot de passe seule ne doit pas être présumée suffisante. Restaurez uniquement une version revue des fichiers et des dépendances.

Un accompagnement en infrastructure et en intégration IA peut préparer ce pilote et ses contrôles, puis évaluer les usages utiles à l’équipe. Il reste distinct d’un audit complet vSphere ou d’un projet d’automatisation des changements.