Qu’est-ce que MCP Server Kubernetes ?
MCP Server Kubernetes, publié sur npm sous mcp-server-kubernetes par l'utilisateur GitHub Flux159, laisse un agent inspecter et changer un cluster via kubectl et Helm. Il expose 23 outils, de kubectl_get, kubectl_describe et kubectl_logs à kubectl_apply, kubectl_delete, exec_in_pod, node_management et un outil kubectl_generic qui lance n'importe quelle commande kubectl, plus un prompt de dépannage k8s-diagnose. La plupart des outils délèguent aux binaires kubectl et helm sur votre PATH, en passant les arguments directement plutôt que via un shell ; le port forwarding et les vérifications de connexion utilisent la bibliothèque client JavaScript officielle.
Il lit ~/.kube/config par défaut et utilise le contexte actuel quel qu'il soit. Il accepte aussi un kubeconfig entier dans KUBECONFIG_YAML ou KUBECONFIG_JSON, un serveur et un jeton bearer dans K8S_SERVER et K8S_TOKEN, un chemin personnalisé, ou le ServiceAccount in-cluster quand il tourne dans un pod, ce que le chart Helm du dépôt prend en charge. Stdio est le défaut ; Streamable HTTP est opt-in derrière ENABLE_UNSAFE_STREAMABLE_HTTP_TRANSPORT, avec un jeton d'en-tête X-MCP-AUTH optionnel.
Le dépôt sous licence MIT a environ 1 600 étoiles GitHub ; v4.2.1 est sortie le 26 octobre 2026, et le paquet npm a été téléchargé environ 34 000 fois sur le mois jusqu'au 26 octobre. Il est listé dans le registre MCP officiel.
Installer MCP Server Kubernetes
npx mcp-server-kubernetesMCP Server Kubernetes vaut-il le coup ?
Les défauts sont le problème, pas la liste de fonctions. Démarré sans variables d'environnement, le serveur offre les 23 outils contre le contexte kubeconfig actuel quel qu'il soit, qui pour la plupart des ingénieurs est une identité admin. Un agent peut alors supprimer des namespaces, drainer des nœuds, désinstaller des releases Helm, lancer des commandes dans les pods avec exec_in_pod et passer n'importe quoi à kubectl_generic. Même l'opération set de kubectl_context réécrit votre kubeconfig, si bien que le contexte que votre propre terminal utilise change aussi.
Trois interrupteurs le restreignent, dans cet ordre de priorité. ALLOWED_TOOLS prend une liste exacte et refuse de démarrer sur un nom mal orthographié. ALLOW_ONLY_READONLY_TOOLS laisse sept outils documentés : get, describe, logs, context (avec le changement bloqué), explain_resource, list_api_resources et ping. ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS est plus faible que son nom : il retire delete, uninstall, cleanup, la gestion de nœuds, exec et kubectl_generic, mais garde kubectl_apply, kubectl_patch, kubectl_scale et les install et upgrade Helm, si bien qu'un agent peut encore scaler un déploiement à zéro ou écraser un manifeste en cours.
Les Secrets sont masqués, en partie. kubectl_get remplace les valeurs de données de tout Secret par *** par défaut, mais la documentation dit clairement que les logs et autres opérations ne sont pas couverts. En mode par défaut, kubectl_generic et exec_in_pod sont tous deux disponibles, si bien qu'une identité avec get sur les Secrets peut les lire en entier. Les specs de pods avec variables d'environnement inline et ConfigMaps reviennent non masquées dans tous les modes. Le masquage est une commodité ; le RBAC est le contrôle.
C'est là qu'un ServiceAccount dédié gagne son utilité. Lié au ClusterRole view intégré de Kubernetes dans un seul namespace, il peut lire la plupart des objets mais pas les Secrets, roles ou role bindings, si bien que ni une ligne de log victime d'injection de prompt ni un bug du serveur ne peuvent atteindre les identifiants ou écrire quoi que ce soit. Les propres conseils de Kubernetes avertissent que list et watch sur les Secrets révèlent leur contenu tout comme get. Ne prenez pas le chart Helm du dépôt comme modèle ici : son ClusterRole, décrit comme au moindre privilège, accorde get, list et watch sur les Secrets à l'échelle du cluster, plus delete sur les pods et déploiements et pods/exec.
Le dossier de sécurité coupe dans les deux sens. Onze avis ont été publiés depuis juillet 2025, huit notés élevés, couvrant l'injection de commandes, l'injection de flags qui pouvait envoyer le jeton bearer de l'opérateur à un autre serveur d'API, des lectures de fichiers locaux arbitraires et, en mai 2026, des modes lecture seule qui ne faisaient que cacher les outils plutôt que de bloquer les appels (corrigé en 3.6.0). Chacun a été corrigé rapidement, et le code bloque désormais les flags comme --server, --token et --as de l'entrée d'outil. C'est beaucoup de conclusions pour un seul serveur, et une raison de rester sur la version actuelle.
Là où il fait la différence
Un SRE d'astreinte dans une entreprise SaaS de 50 ingénieurs qui fait tourner la production sur Kubernetes
Découvrir pourquoi les pods d'un namespace redémarrent en boucle sans risquer d'écriture
Faites tourner avec ALLOW_ONLY_READONLY_TOOLS=true et un kubeconfig pour un ServiceAccount lié au rôle view dans ce namespace, puis invoquez le prompt k8s-diagnose. L'agent lit les événements, la sortie describe et les logs ; il ne peut pas lire les Secrets ni rien changer. Le serveur est gratuit, et l'installation est un seul binding de Role.
Un développeur qui travaille contre un cluster minikube ou kind local
Installer un chart Helm, changer des valeurs et redéployer en itérant sur un service
Le mode par défaut avec le contexte local est raisonnable ici : install_helm_chart, kubectl_apply et kubectl_rollout couvrent la boucle. Pointez-le vers la production avec les mêmes réglages et le même agent peut supprimer des namespaces, alors gardez le contexte actuel du kubeconfig sur le cluster local.
Un responsable d'équipe plateforme dans une fintech qui décide s'il faut autoriser les agents près des clusters partagés
Fixer une politique sur les actions d'agent acceptables
ALLOWED_TOOLS=kubectl_get,kubectl_describe,kubectl_logs fige la surface et échoue au démarrage sur une faute de frappe, et le traçage OpenTelemetry enregistre chaque appel. La décision plus grande est le rôle RBAC derrière, parce que le défaut du chart Helm peut lire chaque Secret du cluster.
Avant de vous engager
- Mise en route
- A besoin de kubectl sur le PATH et d'un kubeconfig fonctionnel (Helm 3 optionnel), puis claude mcp add kubernetes -- npx mcp-server-kubernetes ou la même commande npx dans Claude Desktop, VS Code, Cursor ou Codex ; un bundle mcpb, une image Docker et un chart Helm sont aussi proposés. Si kubectl get pods marche dans votre terminal, le premier appel marche en quelques minutes.
- Intégrations
- 23 outils : outils de lecture (kubectl_get, kubectl_describe, kubectl_logs, explain_resource, list_api_resources, ping), outils d'écriture (kubectl_apply, kubectl_create, kubectl_patch, kubectl_scale, kubectl_rollout, les install, upgrade et uninstall Helm), outils destructeurs (kubectl_delete, cleanup, node_management, exec_in_pod, kubectl_generic), plus le port forwarding et le changement de contexte. Export OpenTelemetry optionnel vers n'importe quel backend OTLP.
- Données et confidentialité
- Il peut faire tout ce que l'identité du kubeconfig peut, et avec les défauts cela inclut lire les Secrets en entier via kubectl_generic ou exec_in_pod. Les logs de pods, événements et annotations sont du texte non fiable qui atteint le modèle, ce qui est la façon dont plusieurs avis décrivent l'exfiltration de jetons. Le mode HTTP se lie à localhost avec la protection DNS rebinding activée par défaut, mais n'exige aucun jeton sauf si MCP_AUTH_TOKEN est défini.
- Coût à grande échelle
- Gratuit ; le cluster facture comme d'habitude. Le coût qui croît est la charge du serveur d'API et le contexte : les appels list sur tous les namespaces dans un grand cluster peuvent dépasser le buffer de sortie par défaut de 1 Mo, que SPAWN_MAX_BUFFER relève.
- Limites
- A besoin des binaires kubectl et helm localement ; pas d'étape d'approbation propre, si bien que la confirmation dépend du client MCP. Le masquage ne couvre que kubectl_get sur les Secrets. Le mode HTTP du chart Helm accepte les requêtes non authentifiées sauf si security.mcpAuthToken est défini.
Les points forts
- 23 outils couvrent kubectl, Helm, les logs, le port forwarding et le travail sur les nœuds
- Modes lecture seule et liste d'autorisation exacte appliqués à l'appel depuis 3.6.0
- Valeurs de Secrets masquées dans la sortie de kubectl_get par défaut
- Nombreuses sources d'identifiants, dont les ServiceAccounts in-cluster
Les points faibles
- Le mode par défaut inclut delete, exec_in_pod et kubectl brut
- Le mode non destructeur autorise encore apply, patch et scale
- Onze avis de sécurité, huit notés élevés
- Le ClusterRole par défaut du chart Helm peut lire chaque Secret
Idéal pour
Les ingénieurs plateforme qui veulent qu'un agent enquête sur les clusters via kubectl, et lui donneront d'abord un ServiceAccount à portée réduite et le mode lecture seule.
Alternatives à MCP Server Kubernetes
MCP Server Kubernetes : questions fréquentes
- MCP Server Kubernetes vaut-il le coup ?
- Large et activement patché, mais par défaut il remet à un agent delete, exec et kubectl brut sur votre contexte actuel, alors faites-le tourner en lecture seule contre un ServiceAccount qui ne peut pas voir les Secrets. Nous lui donnons 3.8 sur 5.
- Combien coûte MCP Server Kubernetes ?
- Gratuit et open source (MIT). Vous payez seulement le cluster auquel il parle.
- Quels sont les inconvénients de MCP Server Kubernetes ?
- Le mode par défaut inclut delete, exec_in_pod et kubectl brut; le mode non destructeur autorise encore apply, patch et scale; onze avis de sécurité, huit notés élevés; le ClusterRole par défaut du chart Helm peut lire chaque Secret.
- À qui s’adresse MCP Server Kubernetes ?
- Les ingénieurs plateforme qui veulent qu'un agent enquête sur les clusters via kubectl, et lui donneront d'abord un ServiceAccount à portée réduite et le mode lecture seule.
- Combien coûte MCP Server Kubernetes pour une équipe ou en production ?
- Gratuit ; le cluster facture comme d'habitude. Le coût qui croît est la charge du serveur d'API et le contexte : les appels list sur tous les namespaces dans un grand cluster peuvent dépasser le buffer de sortie par défaut de 1 Mo, que SPAWN_MAX_BUFFER relève.
- MCP Server Kubernetes est-il sûr pour les données de l’entreprise ?
- Il peut faire tout ce que l'identité du kubeconfig peut, et avec les défauts cela inclut lire les Secrets en entier via kubectl_generic ou exec_in_pod. Les logs de pods, événements et annotations sont du texte non fiable qui atteint le modèle, ce qui est la façon dont plusieurs avis décrivent l'exfiltration de jetons. Le mode HTTP se lie à localhost avec la protection DNS rebinding activée par défaut, mais n'exige aucun jeton sauf si MCP_AUTH_TOKEN est défini.
- Quelles sont les meilleures alternatives à MCP Server Kubernetes ?
- Les alternatives les plus proches que nous avons testées sont AWS MCP Server, Azure MCP Server, Terraform MCP Server et Grafana MCP Server.
Réponses vérifiées le 28 oct. 2026.