Was ist MCP Server Kubernetes?
MCP Server Kubernetes, auf npm als mcp-server-kubernetes vom GitHub-Nutzer Flux159 veröffentlicht, lässt einen Agenten einen Cluster über kubectl und Helm untersuchen und verändern. Er stellt 23 Tools bereit, von kubectl_get, kubectl_describe und kubectl_logs bis zu kubectl_apply, kubectl_delete, exec_in_pod, node_management und einem Tool kubectl_generic, das jeden beliebigen kubectl-Befehl ausführt, dazu einen Prompt k8s-diagnose zur Fehlersuche. Die meisten Tools rufen die Binaries kubectl und helm aus deinem PATH auf und übergeben die Argumente direkt statt über eine Shell; Port Forwarding und Verbindungsprüfungen nutzen die offizielle JavaScript-Client-Bibliothek.
Standardmäßig liest er ~/.kube/config und nutzt den jeweils aktuellen Kontext. Er akzeptiert außerdem eine ganze kubeconfig in KUBECONFIG_YAML oder KUBECONFIG_JSON, einen Server und ein Bearer Token in K8S_SERVER und K8S_TOKEN, einen eigenen Pfad oder den ServiceAccount im Cluster, wenn er in einem Pod läuft, was das Helm-Chart des Repositorys unterstützt. Stdio ist der Standard; Streamable HTTP muss über ENABLE_UNSAFE_STREAMABLE_HTTP_TRANSPORT eingeschaltet werden, mit einem optionalen Token im Header X-MCP-AUTH.
Das MIT-lizenzierte Repository hat rund 1.600 GitHub-Sterne; v4.2.1 erschien am 26. Oktober 2026, und das npm-Paket wurde im Monat bis zum 26. Oktober rund 34.000 Mal heruntergeladen. Es ist im offiziellen MCP-Registry gelistet.
MCP Server Kubernetes installieren
npx mcp-server-kubernetesLohnt sich MCP Server Kubernetes?
Das Problem sind die Voreinstellungen, nicht die Funktionsliste. Ohne Umgebungsvariablen gestartet, bietet der Server alle 23 Tools für den gerade aktuellen kubeconfig-Kontext an, und das ist bei den meisten Engineers eine Admin-Identität. Ein Agent kann dann Namespaces löschen, Nodes leeren, Helm-Releases deinstallieren, mit exec_in_pod Befehle in Pods ausführen und kubectl_generic beliebige Eingaben übergeben. Selbst die set-Operation von kubectl_context schreibt deine kubeconfig um, sodass sich auch der Kontext deines eigenen Terminals ändert.
Drei Schalter grenzen ihn ein, in dieser Rangfolge. ALLOWED_TOOLS nimmt eine exakte Liste und verweigert bei einem falsch geschriebenen Namen den Start. ALLOW_ONLY_READONLY_TOOLS lässt sieben dokumentierte Tools übrig: get, describe, logs, context (mit gesperrtem Wechsel), explain_resource, list_api_resources und ping. ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS ist schwächer, als der Name vermuten lässt: Es entfernt delete, uninstall, cleanup, Node-Verwaltung, exec und kubectl_generic, behält aber kubectl_apply, kubectl_patch, kubectl_scale sowie Helm install und upgrade. Ein Agent kann also weiterhin ein Deployment auf null skalieren oder ein laufendes Manifest überschreiben.
Secrets werden maskiert, teilweise. kubectl_get ersetzt die Datenwerte jedes Secrets standardmäßig durch ***, aber die Doku sagt klar, dass Logs und andere Operationen nicht abgedeckt sind. Im Standardmodus sind kubectl_generic und exec_in_pod beide verfügbar, eine Identität mit get auf Secrets kann sie also vollständig lesen. Pod-Specs mit eingebetteten Umgebungsvariablen und ConfigMaps kommen in jedem Modus unmaskiert zurück. Maskierung ist eine Bequemlichkeit; die Kontrolle ist RBAC.
Genau hier lohnt sich ein eigener ServiceAccount. An die eingebaute ClusterRole view von Kubernetes in einem einzigen Namespace gebunden, kann er die meisten Objekte lesen, aber keine Secrets, Roles oder Role Bindings. Weder eine per Prompt Injection manipulierte Logzeile noch ein Server-Bug erreicht dann Zugangsdaten oder schreibt irgendetwas. Kubernetes warnt in seinen eigenen Empfehlungen, dass list und watch auf Secrets deren Inhalt genauso offenlegen wie get. Nimm das Helm-Chart des Repositorys hier nicht zum Vorbild: Seine als Least Privilege beschriebene ClusterRole gewährt clusterweit get, list und watch auf Secrets, dazu delete auf Pods und Deployments und pods/exec.
Die Sicherheitsbilanz hat zwei Seiten. Seit Juli 2025 wurden elf Advisories veröffentlicht, acht davon als hoch eingestuft. Sie betrafen Command Injection, Flag Injection, die das Bearer Token des Betreibers an einen anderen API-Server schicken konnte, beliebiges Lesen lokaler Dateien und im Mai 2026 Read-only-Modi, die Tools nur versteckten, statt Aufrufe zu blockieren (behoben in 3.6.0). Jede Lücke wurde schnell geschlossen, und der Code blockiert inzwischen Flags wie --server, --token und --as in Tool-Eingaben. Das sind viele Befunde für einen Server und ein Grund, auf dem aktuellen Release zu bleiben.
Wo es sich lohnt
On-Call-SRE in einem SaaS-Unternehmen mit 50 Engineers und Produktion auf Kubernetes
Herausfinden, warum Pods in einem Namespace im Crash-Loop hängen, ohne einen Schreibzugriff zu riskieren
Mit ALLOW_ONLY_READONLY_TOOLS=true und einer kubeconfig für einen ServiceAccount betreiben, der in diesem Namespace an die Rolle view gebunden ist, und dann den Prompt k8s-diagnose aufrufen. Der Agent liest Events, describe-Ausgaben und Logs; er kann keine Secrets lesen und nichts ändern. Der Server ist kostenlos, und die Einrichtung ist ein einziges Role Binding.
Entwicklerin, die gegen einen lokalen minikube- oder kind-Cluster arbeitet
Beim Iterieren an einem Service ein Helm-Chart installieren, Werte ändern und neu deployen
Der Standardmodus mit dem lokalen Kontext ist hier vertretbar: install_helm_chart, kubectl_apply und kubectl_rollout decken die Schleife ab. Mit denselben Einstellungen auf Produktion gerichtet, kann derselbe Agent Namespaces löschen, halte den aktuellen Kontext der kubeconfig also auf dem lokalen Cluster.
Leiter eines Plattform-Teams bei einem Fintech, der entscheidet, ob Agenten an gemeinsame Cluster dürfen
Eine Richtlinie festlegen, welche Agent-Aktionen akzeptabel sind
ALLOWED_TOOLS=kubectl_get,kubectl_describe,kubectl_logs legt die Oberfläche fest und scheitert bei einem Tippfehler schon beim Start, und OpenTelemetry-Tracing protokolliert jeden Aufruf. Die größere Entscheidung ist die RBAC-Rolle dahinter, denn die Standardrolle des Helm-Charts kann jedes Secret im Cluster lesen.
Bevor du dich festlegst
- Einrichtung
- Braucht kubectl im PATH und eine funktionierende kubeconfig (Helm 3 optional), dann claude mcp add kubernetes -- npx mcp-server-kubernetes oder derselbe npx-Befehl in Claude Desktop, VS Code, Cursor oder Codex; ein mcpb-Bundle, ein Docker-Image und ein Helm-Chart werden ebenfalls angeboten. Wenn kubectl get pods in deinem Terminal funktioniert, klappt der erste Aufruf in Minuten.
- Integrationen
- 23 Tools: Lese-Tools (kubectl_get, kubectl_describe, kubectl_logs, explain_resource, list_api_resources, ping), Schreib-Tools (kubectl_apply, kubectl_create, kubectl_patch, kubectl_scale, kubectl_rollout, Helm install, upgrade und uninstall), destruktive Tools (kubectl_delete, cleanup, node_management, exec_in_pod, kubectl_generic), dazu Port Forwarding und Kontextwechsel. Optionaler OpenTelemetry-Export an jedes OTLP-Backend.
- Daten und Datenschutz
- Er kann alles, was die Identität der kubeconfig kann, und mit den Voreinstellungen gehört dazu, Secrets über kubectl_generic oder exec_in_pod vollständig zu lesen. Pod-Logs, Events und Annotations sind nicht vertrauenswürdiger Text, der das Modell erreicht, und genau so beschreiben mehrere Advisories die Exfiltration von Tokens. Der HTTP-Modus bindet standardmäßig an localhost mit aktivem Schutz gegen DNS Rebinding, verlangt aber kein Token, solange MCP_AUTH_TOKEN nicht gesetzt ist.
- Kosten im großen Maßstab
- Kostenlos; der Cluster wird wie gewohnt abgerechnet. Was wächst, sind die Last auf dem API-Server und der Kontext: list-Aufrufe über alle Namespaces in einem großen Cluster können den Standard-Ausgabepuffer von 1 MB sprengen, den SPAWN_MAX_BUFFER anhebt.
- Grenzen
- Braucht lokal die Binaries kubectl und helm; hat keinen eigenen Bestätigungsschritt, die Bestätigung hängt also vom MCP-Client ab. Die Maskierung gilt nur für kubectl_get auf Secrets. Der HTTP-Modus des Helm-Charts akzeptiert unauthentifizierte Anfragen, solange security.mcpAuthToken nicht gesetzt ist.
Was gut ist
- 23 Tools für kubectl, Helm, Logs, Port Forwarding und Arbeit an Nodes
- Read-only- und exakte Allowlist-Modi werden seit 3.6.0 beim Aufruf durchgesetzt
- Secret-Werte in der Ausgabe von kubectl_get standardmäßig maskiert
- Viele Quellen für Zugangsdaten, darunter ServiceAccounts im Cluster
Was nicht
- Der Standardmodus enthält delete, exec_in_pod und rohes kubectl
- Der nicht destruktive Modus erlaubt weiterhin apply, patch und scale
- Elf Sicherheits-Advisories, acht davon als hoch eingestuft
- Die Standard-ClusterRole des Helm-Charts kann jedes Secret lesen
Am besten für
Platform Engineers, die einen Agenten Cluster über kubectl untersuchen lassen wollen und ihm vorher einen eingeschränkten ServiceAccount und den Read-only-Modus geben.
Alternativen zu MCP Server Kubernetes
MCP Server Kubernetes: häufige Fragen
- Lohnt sich MCP Server Kubernetes?
- Breit aufgestellt und aktiv gepatcht, aber ab Werk gibt er einem Agenten delete, exec und rohes kubectl auf deinem aktuellen Kontext. Betreib ihn also read-only mit einem ServiceAccount, der keine Secrets sehen kann. Wir bewerten es mit 3.8 von 5.
- Was kostet MCP Server Kubernetes?
- Kostenlos und Open Source (MIT). Du bezahlst nur den Cluster, mit dem er spricht.
- Welche Nachteile hat MCP Server Kubernetes?
- Der Standardmodus enthält delete, exec_in_pod und rohes kubectl; Der nicht destruktive Modus erlaubt weiterhin apply, patch und scale; Elf Sicherheits-Advisories, acht davon als hoch eingestuft; Die Standard-ClusterRole des Helm-Charts kann jedes Secret lesen.
- Für wen eignet sich MCP Server Kubernetes?
- Platform Engineers, die einen Agenten Cluster über kubectl untersuchen lassen wollen und ihm vorher einen eingeschränkten ServiceAccount und den Read-only-Modus geben.
- Was kostet MCP Server Kubernetes für ein Team oder im Produktivbetrieb?
- Kostenlos; der Cluster wird wie gewohnt abgerechnet. Was wächst, sind die Last auf dem API-Server und der Kontext: list-Aufrufe über alle Namespaces in einem großen Cluster können den Standard-Ausgabepuffer von 1 MB sprengen, den SPAWN_MAX_BUFFER anhebt.
- Ist MCP Server Kubernetes sicher für Firmendaten?
- Er kann alles, was die Identität der kubeconfig kann, und mit den Voreinstellungen gehört dazu, Secrets über kubectl_generic oder exec_in_pod vollständig zu lesen. Pod-Logs, Events und Annotations sind nicht vertrauenswürdiger Text, der das Modell erreicht, und genau so beschreiben mehrere Advisories die Exfiltration von Tokens. Der HTTP-Modus bindet standardmäßig an localhost mit aktivem Schutz gegen DNS Rebinding, verlangt aber kein Token, solange MCP_AUTH_TOKEN nicht gesetzt ist.
- Was sind die besten Alternativen zu MCP Server Kubernetes?
- Die nächsten Alternativen, die wir getestet haben, sind AWS MCP Server, Azure MCP Server, Terraform MCP Server und Grafana MCP Server.
Antworten geprüft am 28. Okt. 2026.