Standardmäßig sichere MCP-Server für Kubernetes, Kafka und Cloud-Betrieb
Acht MCP-Server lassen Agenten mit Kubernetes, Kafka, ClickHouse und Azure arbeiten: mit Nur-Lese-Standard, Allowlists, Lösch-Flags, Audit-Logs und Annotationen.
Einen KI-Agenten an die Produktionsinfrastruktur zu lassen, ist ein einfacher Weg, schnell voranzukommen. Es ist aber auch ein einfacher Weg, eine Datenbank zu verlieren, weil ein Prompt etwas zu vage war. Mit dem Model Context Protocol (MCP) ist es trivial, einem Agenten Werkzeuge wie "Pods auflisten", "Deployment neu starten" und "diese Abfrage ausführen" zu geben. Bei Infrastruktur kann derselbe Mechanismus aber genauso leicht delete_topic, DROP TABLE oder delete_resource_group aus der Hand geben. Der übliche Rat lautet, die gefährlichen Werkzeuge wegzulassen, doch dann wird der Server genau in dem Moment nutzlos, in dem man diese Operationen braucht.
Eine Antwort darauf ist eine Familie von acht MCP-Servern, die alle auf einem einzigen Prinzip beruhen. Jeder ist standardmäßig sicher, und seine Befugnisse erweiterst du bewusst. So funktioniert das Design, und das deckt die Suite ab.
Die Policy-Engine
Alle acht Server teilen sich eine Policy-Engine, die auf vier Ideen aufbaut.
Zugriffsmodi in Stufen. Ein Server startet im Nur-Lese-Modus. Für Lesen und Schreiben und danach für den Admin-Modus muss man eine Umgebungsvariable bewusst ändern. Das Entscheidende ist, dass Werkzeuge oberhalb des aktuellen Modus gar nicht erst registriert werden. Im Nur-Lese-Modus sieht der Agent kein Löschwerkzeug, das er höflich nicht aufruft. Das Werkzeug steht einfach nicht in seiner Liste, und was es nicht gibt, kann man nicht missbrauchen.
Allowlists und geschützte Ressourcen. Ein Server lässt sich auf benannte Namespaces, Topics, Datenbanken, Projekte oder Subscriptions beschränken. Bestimmte Ressourcen kann man außerdem als geschützt markieren, etwa den Namespace kube-system, ein internes Kafka-Topic oder den Master-Realm in Keycloak. Geschützte Ressourcen bleiben lesbar, sind aber nie änderbar, auch nicht im Admin-Modus.
Destruktive Aktionen hinter einem zweiten Schalter. Löschvorgänge und andere unumkehrbare Operationen erfordern den Admin-Modus und zusätzlich eine eigene Freigabe, zum Beispiel KAFKA_ALLOW_DELETE=true. Eine frische Installation kann selbst im höchsten Modus nichts zerstören, bis du zweimal bestätigt hast.
Eine sichtbare Audit-Spur. Jede Aktion schreibt eine strukturierte JSON-Zeile mit geschwärzten Secrets nach stderr, sodass man hinterher leicht sieht, was der Agent getan hat.
Am Ende hast du einen Drehregler und keinen Kippschalter. Vertrauen wird in Schritten übergeben, die du steuerst, statt dass du zwischen einem nutzlosen und einem beängstigenden Server wählen musst.
Das Sicherheitsmodell maschinenlesbar machen
Bis Version 0.1.1 stand das Sicherheitsmodell nur im README. Menschen konnten es lesen, die Anwendung, in der der Agent läuft (Claude Desktop, Cursor, Copilot), aber nicht.
MCP hat dafür bereits eine Funktion: Tool-Annotationen. Ein Werkzeug kann strukturierte Hinweise angeben, nämlich readOnlyHint, destructiveHint, idempotentHint und openWorldHint, anhand derer der Host entscheidet, was er automatisch genehmigt und wo er anhält und nachfragt.
Diese Hinweise sind jetzt bei jedem Werkzeug aller acht Server gesetzt und werden automatisch aus der Zugriffsstufe des jeweiligen Werkzeugs abgeleitet. Ein Lesewerkzeug erklärt sich als nur lesend und nicht destruktiv. Ein Löschwerkzeug erklärt sich als destruktiv. So kann der Host den möglichen Schaden eines Werkzeugs vor der Ausführung einschätzen, und zwar anhand strukturierter Metadaten, statt eine englische Beschreibung zu parsen und auf das Beste zu hoffen. Ein Test prüft, dass jeder Hinweis zu dem Werkzeug passt, das er beschreibt. Das ist der Unterschied zwischen "Vertrau uns, das ist sicher" und einer Aussage, die eine Maschine überprüfen kann.
Die acht Server
Jeder Server steht unter der MIT-Lizenz, ist in TypeScript geschrieben und lässt sich mit einem einzigen npx-Befehl installieren.
- mcp-kubernetes deckt Pods, Logs, Deployments, Skalierung und Neustarts sowie apply und exec ab.
- mcp-kafka kümmert sich um Topics, Consumer Groups und Lag, dazu um Operationen zum Anlegen, Ändern und Zurücksetzen.
- mcp-clickhouse stellt Schemas und Abfragen bereit und stuft SQL als lesend, schreibend oder destruktiv ein, um jede Anweisung abzusichern.
- mcp-debezium verwaltet Change-Data-Capture-Konnektoren, einschließlich Status, Konfiguration und Lebenszyklus.
- mcp-oci erkennt Ressourcen in der Oracle Cloud und erzeugt Terraform.
- mcp-azure arbeitet mit dem Azure Resource Manager für Inventar, Tags, den Energiezustand von VMs und den Lebenszyklus.
- mcp-azure-devops greift auf Boards, Repos, Pipelines und Projekte zu.
- mcp-keycloak deckt Realms, Benutzer, Clients, Rollen und Gruppen ab.
Einen ausprobieren
Einen Server zu Claude Code hinzuzufügen, braucht nur eine Zeile, und er startet im Nur-Lese-Modus:
claude mcp add kubernetes -e K8S_MODE=read-only -- npx -y @dockndevai/mcp-kubernetes
Jedes Repository dokumentiert die Einrichtung für Claude, Cursor, Codex, VS Code und Windsurf. Der Quellcode liegt auf GitHub, die Pakete sind auf npm veröffentlicht.
Die offene Frage
Eine Designentscheidung lädt zur Diskussion ein: Bevor eine destruktive Aktion läuft, werden sowohl der Admin-Modus als auch ein Freigabe-Flag pro Operation verlangt. Ist das für echte Arbeitsabläufe zu streng, oder genau der richtige Standard, wenn Infrastruktur an einen Agenten geht? Teams landen an unterschiedlichen Punkten, von dauerhaft nur lesend bis zu abgestuftem Vertrauen, das mit wachsender Sicherheit zunimmt. Welche Haltung auch passt, der Kern des Designs trägt: Mach das sicherste Verhalten zum Standard und verlange klare, bewusste Schritte, um es zu lockern.