ClickHouse MCP Server sicher einrichten

Der ClickHouse MCP Server verbindet einen KI-Client mit einer ClickHouse-Datenbank. Die erste Einrichtung sollte ein begrenzter Test sein, nicht sofort ein Zugang zur Produktion. Beginne mit einer nicht produktiven Instanz oder einer abgesicherten Datenbankansicht, einem dedizierten Benutzer und einer konkreten Frage, die mit wenigen Tabellen beantwortet werden kann. Der Server kann Schema-Metadaten und Abfrageergebnisse an den KI-Client zurückgeben; prüfe daher vorher auch dessen Modell-, Logging- und Aufbewahrungspfad.

Einen minimalen ClickHouse-Benutzer anlegen

Lege keinen Administrator- oder default-Zugang in der MCP-Konfiguration ab. Erstelle einen separaten Benutzer oder eine Rolle, der nur SELECT auf die nötigen Datenbanken, Tabellen oder möglichst restriktive Views besitzt. Read-only verhindert Änderungen, aber nicht das Auslesen vertraulicher Spalten. Entferne deshalb unnötige Tabellen, Spalten und Zeilen bereits auf Datenbankebene. Dokumentiere, wer für diesen Zugang verantwortlich ist, und rotiere das Passwort nach dem eigenen Secret-Verfahren.

Lokalen stdio-Start konfigurieren

Installiere uv und hinterlege im MCP-Client den offiziellen Befehl uv run --with mcp-clickhouse --python 3.10 mcp-clickhouse. Setze CLICKHOUSE_HOST, CLICKHOUSE_USER und CLICKHOUSE_PASSWORD nur als geschützte Umgebungsvariablen. Für ClickHouse Cloud ist HTTPS auf Port 8443 laut Dokumentation der Standard; bei selbstverwaltetem HTTP kann CLICKHOUSE_SECURE=false und gegebenenfalls Port 8123 nötig sein. Diese Werte beschreiben die Datenbankverbindung. Sie konfigurieren nicht automatisch TLS oder Authentifizierung eines separaten MCP-HTTP-Endpunkts.

Abfragen und Ergebnisumfang begrenzen

Lass CLICKHOUSE_ALLOW_WRITE_ACCESS zunächst auf dem Standardwert false. Dann erzwingt der Server laut README read-only Abfragen. Konfiguriere einen angemessenen CLICKHOUSE_MCP_QUERY_TIMEOUT und prüfe, ob auch ClickHouse-seitige Profile, Quotas, Speicher- und Ergebnislimits zu deinem Workload passen. Fordere im Client gezielt kleine, nachvollziehbare Abfragen an, etwa eine Tabellenliste oder eine aggregierte Kennzahl, statt unbeschränkt SELECT * zu erlauben. Ein Timeout und ein Tool-Dialog ersetzen keine Grants und keine Datenminimierung.

Schreibzugriff nur mit klarer Freigabe

Soll ein Workflow Tabellen anlegen, Daten einfügen oder Strukturen ändern, prüfe erst SQL, Zielobjekt und Rückrollplan. CLICKHOUSE_ALLOW_WRITE_ACCESS=true erlaubt laut README nur die nicht-destruktive Schreibklasse zusätzlich zu passenden ClickHouse-Grants. Für DROP, TRUNCATE, DELETE, UPDATE und weitere geschützte Varianten ist außerdem CLICKHOUSE_ALLOW_DROP=true nötig. Diese Flags sind keine Sicherheitsgrenze. Erteile entsprechende Datenbankrechte nur zeitlich und fachlich begrenzt und bestätige jede Mutation im Client, sofern er das anbietet.

Netzwerk, Prompt Injection und Modellpfad prüfen

Für stdio bleibt der Prozess lokal. Bei HTTP oder SSE verlangt der Server standardmäßig Bearer-Token oder OAuth/OIDC; deaktiviere diese Authentifizierung nicht außerhalb lokaler Tests. Begrenze Bind-Adresse und erlaubte Hosts/Origins und setze TLS am geeigneten Infrastruktur-Rand. Lies Tabelleninhalte, Kommentare und Fehlermeldungen als untrusted data: Sie können eine Prompt Injection enthalten, die einen Agenten zu Datenexport, Credential-Offenlegung oder SQL-Änderungen drängen soll. Keine solche Anweisung darf die Rechte- oder Freigaberegeln ändern. Kontrolliere außerdem, ob Query-Ergebnisse an ein externes Modell, Logs oder Telemetrie gehen. Halte für Freigaben nachvollziehbar fest, welche Datenbank, Tabellen, Rollen und Tool-Aufrufe in diesem Testumfang erlaubt sind. Erst wenn Datenbankzugriff und Modellpfad akzeptiert sind, ist der Server produktionsreif eingegrenzt.