Constantin Budin, Azure und Kubernetes bei Pexon Consulting | 9 Min. Lesezeit | 08.09.2026
TL;DR: MCP Kubernetes kurz erklärt
MCP Kubernetes verbindet einen KI-Agenten über JSON-RPC mit dem Cluster: der Host fragt, der Server spricht mit der API. Pexon Consulting (80 MA, Microsoft Partner in Deutschland) setzt das nicht als Desktop-Demo, sondern mit RBAC, Audit und Freigabe. Ohne Least Privilege wird aus „Deploy nginx“ schnell ein Delete in Produktion.
| Setup | Was läuft | Was fehlt |
|---|---|---|
| Claude Desktop plus lokaler Server | Sprache zu kubectl oder API | Rechte, Protokoll, Freigabe |
| Enterprise-MCP am Cluster | derselbe Satz, begrenzter Scope | ServiceAccount, Audit, Approval |
Warum ein lokaler MCP-Server den Cluster nicht sicher macht
Die kurze Antwort: Ja, der Agent steuert den Cluster. Nein, die Demo ist kein Betrieb.
MCP ist das Model Context Protocol. Seit der Spec 2026-07-28 ist der Kern zustandslos: Version und Fähigkeiten stehen in _meta pro Request, nicht mehr in einer Session nach initialize. Der Host (Claude Desktop, Cursor, Copilot) schickt JSON-RPC. Der Server übersetzt in Cluster-Aufrufe. Restaurant-Bild: der Agent bestellt, der Transport ist der Kellner, der Server die Küche.
Das Tutorial endet oft bei bun, einem geklonten Repo und „Deploy nginx“. Das funktioniert. Es beweist nur, dass der Server die kubeconfig lesen kann. Es beweist nicht, welcher Namespace erlaubt ist, wer den Delete sieht und wer ihn stoppen darf.
Wir raten aktuell davon ab, denselben lokalen Prozess mit Cluster-Admin „zum Ausprobieren“ gegen Staging oder Produktion zu hängen. Das ist kein vorsichtiger Start. Das ist ein zweiter kubectl mit Sprachsteuerung und ohne Ticket.
So steuert MCP Kubernetes den Cluster
Es gibt nicht den einen Server. Es gibt ein Konzept: ein MCP-Server mit Kubernetes-Werkzeugen, angebunden an kubeconfig oder ServiceAccount.
Unter der containers-Organisation (dieselbe Community hinter Podman) liegt kubernetes-mcp-server. Das ist eine Go-Implementierung gegen die API, kein kubectl-Wrapper. Release v0.0.66 vom 31.07.2026 bringt die Spec 2026-07-28. Am 08.09.2026 stand das Repo bei 2.068 Stars. Flux159/mcp-server-kubernetes (TypeScript, MIT) lag am selben Tag bei 1.577 Stars. Microsoft beschreibt parallel den AKS-MCP-Server: lokal über die AKS-VS-Code-Erweiterung, remote im Cluster mit Workload Identity. Red Hat hat den nativen Server am 19.08.2026 als Betriebsbaustein eingeordnet, nicht als Spielzeug.
Unsere klare Empfehlung: Server als Konzept wählen, nicht als Religion. Teams mit kubectl und Helm im Pfad landen oft bei einem Wrapper. Eine Binary ohne Node spricht für den Go-Server. AKS plus Entra gehört zuerst auf den AKS-Weg. Keiner dieser Wege ersetzt RBAC.
Ein erster, ehrlicher Start ist Nur-Lesen. Der containers-Server kennt --read-only und --disable-destructive. In Claude Desktop reicht das als Host-Config, solange die kubeconfig wirklich nur den vorgesehenen Kontext trifft:
{
"mcpServers": {
"kubernetes": {
"command": "npx",
"args": [
"-y",
"kubernetes-mcp-server@latest",
"--read-only"
]
}
}
}Der Agent (bei uns oft claude-sonnet-4-6 im Desktop-Host) sagt dann „Gibt es laufende Pods?“ und bekommt eine Liste. „Deploy nginx“ muss in diesem Modus scheitern. Wenn es nicht scheitert, ist die Flag-Doku nicht der laufende Prozess.
Wer schreiben will, schneidet vorher: ein Namespace, ein ServiceAccount, keine cluster-admin. Der Satz „Deploy nginx“ wird zu create oder apply. „Destroy nginx“ wird zu delete. Genau dieser zweite Satz ist der Grund, warum wir Approval-Gates vor Produktiv-Deletes setzen und nicht nach dem ersten Vorfall.
Die kubeconfig ist der unsichtbare Hebel. Der Server nimmt den aktuellen Kontext. Wer lokal Docker Desktop und remote AKS in derselben Datei hat, steuert im Zweifel den falschen Cluster. Das ist kein MCP-Bug. Das ist ein Identitätsfehler, den Sprache nur schneller macht.
Was Demo und Enterprise wirklich trennt
Im Red Hat State of Kubernetes Security Report 2024 meldeten 90 Prozent der befragten Organisationen mindestens einen Sicherheitsvorfall im Vorjahr. 45 Prozent der Vorfälle lagen an Fehlkonfiguration, nicht an Zero-Days. CNCF Annual Survey 2025: 56 Prozent betreiben Container produktiv. MCP ändert daran nichts. Es legt einen zweiten Eingang auf dieselbe Fläche.
| Kriterium | Demo-MCP | Enterprise-MCP |
|---|---|---|
| Identität | persönliche kubeconfig | ServiceAccount, oft Workload Identity |
| Rechte | oft zu breit, „damit es läuft“ | Role plus RoleBinding, Namespace-Schnitt |
| Schreiben | an, sobald die Demo cool wirkt | erst nach Nur-Lesen, Deletes hinter Gate |
| Nachweis | Chatverlauf | wer hat wann welches Tool mit welchem Objekt gerufen |
| Host | ein Laptop | zentraler Server, mehrere Clients, kein Secret auf der Platte |
Wir sehen denselben Sprung wie bei anderen MCP-Anbindungen: der POC läuft in Minuten, der Produktivfall scheitert an Scope. MCP gegen klassische APIs ist die Einordnung des Protokolls. Vergiftete MCP-Tools in Agent-Pipelines ist die Angriffsseite. Beides gilt hier, nur mit kubectl-Wirkung.
Der allgemeine Einstieg sitzt bei der MCP-Integration für KI-Agenten. Das ist Mutterthema, nicht dieser Cluster-Schnitt. Wer Agenten und Inferenz im selben Pool mischt, landet bei KI-Lasten auf demselben Cluster. Wieder Nachbar, nicht Ersatz.
Worauf wir bei der Auswahl achten
Fünf Punkte, mehr nicht. Wer alle fünf beantworten kann, hat keinen Tutorial-Rest, sondern eine Entscheidung.
- Welcher Host darf den Server sehen? Desktop auf dem Laptop ist ein anderer Vertrauenskreis als ein HTTP-Server im Cluster für mehrere Agents.
- Welche Verben braucht der Anwendungsfall wirklich? Lesen von Pods und Events reicht oft. Create in einem Freigabe-Namespace ist der zweite Schritt. Delete in Produktion ist der dritte, und der braucht einen Menschen.
- Welcher Namespace ist die Grenze? Cluster-weit „weil der Agent sonst nichts findet“ ist die teuerste Abkürzung.
- Wo liegt das Protokoll? Chat-Logs sind kein Audit. Wir wollen Tool-Name, Principal, Objekt, Zeitpunkt.
- Was passiert bei Kontextwechsel? Ein zweiter kube-context ohne Freigabe ist ein zweiter Cluster. Den darf der Server nicht still mitnehmen.
Der Kubernetes-Security-Leitfaden bleibt der Sibling für Netz, Image und Policy. MCP ist dort ein neuer Client, kein Ersatz für NetworkPolicy.
Das ist Geldverschwendung, wenn Sie zuerst den schreibenden Server bauen und hinterher die Rolle suchen. Andersherum dauert die Demo einen Nachmittag länger und spart den Incident.
Häufig gestellte Fragen
Was ist MCP Kubernetes?
MCP Kubernetes ist die Verbindung aus Model Context Protocol und einem Kubernetes-MCP-Server. Der Agent spricht natürlich, der Server setzt JSON-RPC in API-Aufrufe um. Host und Server sind zwei Rollen, nicht ein Prozess.
Was kostet MCP Kubernetes im Betrieb?
Der quelloffene Server selbst ist ohne Lizenzgebühr nutzbar (Apache-2.0 oder MIT, je nach Repo). Kosten entstehen durch Cluster-Rechte, Audit-Strecke, Host-Anbindung und die Zeit, bis Deletes hinter einem Gate liegen. Einen Festpreis ohne Scope gibt es bei uns nicht, der Schnitt entscheidet.
MCP Kubernetes Server oder kubectl-Skripte: was ist besser?
Kommt drauf an, aber für Agenten ist MCP der sauberere Vertrag: Werkzeugliste, Schema, ein Transport. Ein Bash-Alias „der Agent soll kubectl aufrufen“ umgeht genau die Stelle, an der Sie Rechte und Logs schneiden wollen. Für Menschen bleibt kubectl. Für Agents wollen wir den Server.
Kann der Agent meinen Produktionscluster löschen?
Ja, sobald der Server write und delete darf und der Kontext auf Produktion zeigt. --read-only und ein Namespace-RoleBinding sind der Mindestschutz. Ohne Freigabe vor Delete würden wir das nicht produktiv schalten.
Reicht Claude Desktop als Host für den Alltag?
Für den ersten Test ja. Für mehrere Personen, gemeinsame Rechte und nachvollziehbare Aufrufe nein. Dann gehört der Server in den Cluster oder hinter ein Gateway, nicht in die Config-Datei auf dem Laptop.
Nächster Schritt
Wenn der Agent Pods listen kann, ist die Demo fertig. Der nächste Schritt ist der Schnitt: welche Rolle, welches Log, welches Gate.
Verwandte Themen
