Deine Cloud SQL Instanz hat keine öffentliche IP.
Erreiche sie über ihren Namen, ohne Bastion-VM.
AgentsRoom startet den Cloud SQL Auth Proxy, wenn du die Verbindung öffnest, und verbindet seinen Datenbank-Client darüber. Du gibst den Verbindungsnamen der Instanz an, project:region:instance, oder wählst sie aus der Liste, die dein eigener gcloud-Login sehen kann.
Der Proxy wird durch deine Application Default Credentials (Standard-Anmeldedaten der Anwendung) autorisiert, AgentsRoom speichert also keinen Service-Account-Schlüssel. Mit IAM-Datenbankauthentifizierung entfällt auch das Datenbankpasswort. Und ein KI-Coding-Agent kann dieselbe Instanz abfragen, schreibgeschützt.
Wie AgentsRoom eine Cloud SQL Instanz über ihre private IP mit dem Cloud SQL Auth Proxy erreicht, ohne dass auf App-Seite etwas gespeichert wird.
Eine Cloud SQL Instanz nur mit privater IP ist das richtige Setup und ein lästiges zugleich. Die Datenbank liegt in deiner VPC, ihre öffentliche IP ist aus, und erreichen können sie nur Maschinen innerhalb dieses Netzwerks. Und dann muss für einen Bug ein Blick auf drei Zeilen her, von einem Laptop aus.
Google liefert die Antwort schon mit: den Cloud SQL Auth Proxy. Er baut eine verschlüsselte Verbindung zur Instanz auf, autorisiert durch deine Google-Identität statt durch eine IP-Freigabeliste, und stellt sie als lokalen Port bereit. Die Reibung liegt in allem drumherum: ihn installieren, sich den Verbindungsnamen der Instanz merken, ihn in einem Terminal starten, bevor man einen Client öffnet, und ihn danach laufend vergessen.
AgentsRoom übernimmt diesen Teil. Du wählst im Feld Erreichen über einer Datenbankverbindung Google Cloud SQL, gibst die Instanz an, setzt bei Bedarf den Haken bei Private IP oder IAM-Datenbankauthentifizierung, und ab dann ist das Öffnen dieser Datenbank ein Klick. Der Proxy startet mit der Verbindung und endet mit ihr.
Die üblichen Umwege kosten alle etwas
Drei Antworten auf dasselbe Problem, und was jede davon dir abverlangt.
Eine Bastion-VM nur dafür
Eine Compute Engine VM mit SSH-Port, die nur deshalb in der VPC bleibt, damit jemand ab und zu einen Tunnel zur Datenbank bauen kann. Sie muss gepatcht werden, sie kostet jede Stunde Geld, und ihre SSH-Schlüssel und Firewall-Regeln veralten mit jedem Zu- und Abgang im Team.
Eine öffentliche IP und eine Freigabeliste
Die öffentliche IP einzuschalten und die eigene Heimadresse zu den autorisierten Netzwerken hinzuzufügen funktioniert, bis sich die Adresse ändert, und bis dahin lauscht die Datenbank im Internet. Es ist die Ausnahme, die nie wieder entfernt wird.
Ein Service-Account-Schlüssel auf einem Laptop
Einen JSON-Schlüssel herunterzuladen, um den Proxy zu starten, ist die Abkürzung, die jeder bereut: eine langlebige Zugangsberechtigung in einem Downloads-Ordner, kopiert in Skripte und Prompts, die niemand rotiert und niemand zurückverfolgen kann.
Von einer privaten Cloud SQL Instanz zum Abfrageergebnis
Vier Schritte, einmal gemacht, danach ist es ein Klick.
Einmal mit gcloud anmelden
Führe gcloud auth application-default login auf deiner Maschine aus. Die dabei erzeugten Application Default Credentials nutzt der Proxy, um die Instanz zu erreichen. AgentsRoom liest nichts davon und speichert nichts davon.
Instanz unter Erreichen über wählen
Lege eine MySQL- oder PostgreSQL-Verbindung an und wähle unter Erreichen über Google Cloud SQL. Tippe den Verbindungsnamen der Instanz ein, project:region:instance, oder klicke auf Meine Instanzen auflisten, um sie aus dem zu wählen, was dein gcloud-Login sehen kann. Host und Port verschwinden: Die Instanz ist die Adresse.
Private IP und IAM-Authentifizierung wählen
Setze den Haken bei Private IP, wenn die Instanz keine öffentliche Adresse hat und deine Maschine ihre VPC über ein VPN oder Interconnect erreicht. Setze den Haken bei IAM-Datenbankauthentifizierung, um dich mit deiner Google-Identität anzumelden: Das Passwortfeld entfällt, und der Benutzer ist dein IAM-Datenbankbenutzer.
Abfragen, oder einen Agenten abfragen lassen
Beim Öffnen der Verbindung wird ein freier Loopback-Port reserviert, cloud-sql-proxy darauf gestartet und gewartet, bis er eine TCP-Verbindung annimmt. Die Konsole verbindet sich wie bei jeder anderen Verbindung mit 127.0.0.1, und ein KI-Agent kann die Instanz per MCP schreibgeschützt abfragen. Beim Schließen der Verbindung wird der Proxy beendet.
Der Befehl, den AgentsRoom startet
Nichts wird nachgebaut. AgentsRoom führt Googles eigene cloud-sql-proxy Binärdatei (Version 2) als Kindprozess aus, mit direkt übergebenen Argumenten statt über eine Shell. Wenn du den Proxy schon mal von Hand gestartet hast, ist das die Zeile, die du kennst.
cloud-sql-proxy acme-prod:europe-west1:orders \
--address 127.0.0.1 --port 54321 \
--private-ip \
--auto-iam-authnDie Instanz und die beiden Optionen stammen aus der gespeicherten Verbindung. Der lokale Port wird beim Öffnen vom Betriebssystem gewählt.
Der Proxy nimmt die lokale Verbindung an, bevor er irgendetwas prüft, und trennt sie dann wieder und protokolliert den Grund, wenn etwas nicht stimmt. AgentsRoom liest dieses Log und nennt dir die eigentliche Ursache: Der Proxy ist nicht installiert, dein gcloud-Login ist abgelaufen (mit dem Befehl, den du ausführen musst), deinem Konto fehlt die Rolle Cloud SQL Client, die Instanz hat keine private IP, oder der Instanzname ist falsch.
Was stimmen muss, damit es funktioniert
AgentsRoom steuert dein Google Cloud Setup, ersetzt es aber nicht. Das sind dieselben Dinge, die der Proxy auch allein braucht.
cloud-sql-proxy auf deiner Maschine
Version 2 des Cloud SQL Auth Proxy, im PATH. gcloud components install cloud-sql-proxy ist der schnellste Weg; Google liefert ihn auch als eigenständigen Download. Fehlt er, sagt AgentsRoom das und nennt den Befehl.
Application Default Credentials
gcloud auth application-default login, einmal ausgeführt. Läuft dieser Login ab, sagt dir die Fehlermeldung, dass du ihn erneut ausführen sollst, statt einen geschlossenen Socket zu zeigen.
Die Rolle Cloud SQL Client
Dein Google-Konto braucht die Rolle Cloud SQL Client im Projekt der Instanz, und die Cloud SQL Admin API muss dort aktiviert sein. Die IAM-Datenbankauthentifizierung braucht zusätzlich die Rolle Cloud SQL Instance User und einen IAM-Benutzer auf der Instanz.
gcloud für die Auswahlliste
Meine Instanzen auflisten führt gcloud sql instances list in deinem aktiven Projekt aus, oder in dem Projekt, das du zu tippen begonnen hast. Ohne gcloud kannst du den Verbindungsnamen trotzdem von Hand eingeben.
Ein Weg in die VPC für die private IP
Private IP bedeutet, dass deine Maschine selbst die VPC der Instanz erreichen muss, über ein VPN, Interconnect oder eine Maschine im Netzwerk. Ohne diesen Weg lass Private IP aus und nutze die öffentliche IP mit der Verschlüsselung des Proxys.
Was der Proxy tut, und was er verweigert
Die Eigenschaften, die entscheiden, ob man das gefahrlos auf einem Laptop konfiguriert lassen kann.
Nur Loopback
Der Proxy lauscht auf 127.0.0.1 und sonst nirgends. Die Datenbank wird nie im lokalen Netzwerk neu veröffentlicht, das Café-WLAN wird also nicht zum Weg in die Produktion.
Ein vom Betriebssystem gewählter Port
AgentsRoom fragt das Betriebssystem nach einem freien Port und übergibt ihn an den Proxy. Kein fester Port, den man sich merken muss, keine Kollision mit einem anderen, von Hand gestarteten Proxy.
Bereit heißt bereit
Die Verbindung wird erst geöffnet, wenn der lokale Port TCP annimmt, und ein Proxy, der sofort beendet, meldet den Grund, den er ausgegeben hat. Kein willkürliches Warten, kein Client, der sich zu früh verbindet.
Kein Schlüssel gespeichert
Der Proxy wird durch deine Application Default Credentials autorisiert. AgentsRoom speichert den Verbindungsnamen der Instanz und zwei Optionen, von denen keine eine Zugangsberechtigung ist, und kein Service-Account-Schlüssel berührt je die App.
Die Datenbank bleibt schreibgeschützt
Eine Datenbankverbindung ist beim Anlegen schreibgeschützt. Ein Schreibzugriff setzt voraus, dass diese Verbindung schreibbar gemacht und ausdrücklich bestätigt wird, bei einer als Produktion markierten Verbindung deutlicher.
Ein Statement pro Aufruf
Jeder Aufruf enthält genau ein Statement, hinter einem Semikolon versteckt sich also nichts, und Ergebnismengen sind begrenzt, damit eine breite Abfrage weder ein Fenster noch den Kontext eines Agenten flutet.
Warum das weniger Zugriff bedeutet, nicht mehr
Auf der Instanzseite wird nichts geöffnet. Die öffentliche IP kann aus bleiben, kein Netzwerk kommt auf die Freigabeliste, und für die gelegentliche Abfrage wird keine VM mit SSH-Port am Leben gehalten. Der Proxy verschlüsselt die Verbindung durchgängig bis zur Instanz.
Die Autorisierung bleibt dort, wo deine Organisation sie verwaltet: bei deiner Google-Identität und ihren IAM-Rollen. Der dieser Identität gewährte Zugriff wird wie jede andere Cloud SQL Verbindung protokolliert und endet an dem Tag, an dem die Rolle entfernt wird. AgentsRoom behält den Instanznamen, die Wahl Private IP und die Wahl IAM, und nichts, was jemand wiederverwenden könnte, der das gelesen hat.
Auf der Datenbankseite gelten dieselben Schutzmechanismen wie für jede AgentsRoom Verbindung: standardmäßig schreibgeschützt, ein Statement pro Aufruf, begrenzte Ergebnismengen und ein Produktions-Flag, das die Schreibbestätigung verschärft. Ein KI-Agent, der per MCP abfragt, bekommt eine Ergebnismenge, nie eine Zugangsberechtigung, und kann nicht schreiben, es sei denn, du hast diese Verbindung schreibbar gemacht und dafür Agenten Schreibzugriff erlauben aktiviert.
MySQL und PostgreSQL, SQL Server noch nicht
Cloud SQL betreibt MySQL, PostgreSQL und SQL Server. AgentsRoom erreicht die ersten beiden über den Proxy und hat heute keinen SQL Server Client. AlloyDB, das einen eigenen Proxy hat, ist ebenfalls nicht abgedeckt.
Welche Engine oder welcher Dienst als Nächstes kommt, entscheidet sich danach, was Leute anfragen. Fehlt deine, nenne sie im öffentlichen Backlog, und sie wird mitgezählt.
Deine Datenbank-Engine anfragenEin Agent kann sie auch abfragen, schreibgeschützt
Sobald die Verbindung existiert, nutzt ein KI-Coding-Agent sie über AgentsRoom MCP, indem er sie beim Namen nennt: db_list, db_schema, um Tabellen und Spalten zu durchlaufen, db_query für ein Statement mit begrenzter Zeilenzahl. Ein Agent kann auch selbst eine Cloud SQL Verbindung mit db_connection_new oder db_connection_save anlegen, indem er den Verbindungsnamen der Instanz angibt.
AgentsRoom startet den Proxy selbst, wenn der Agent ihn anfragt, der Agent hantiert also nie mit einer Google-Zugangsberechtigung, einem Datenbankpasswort oder einer Portnummer. Zurück kommt eine Ergebnismenge. Schreibzugriffe setzen eine schreibbare Verbindung und die Einstellung Agenten Schreibzugriff erlauben voraus, die standardmäßig aus ist.
Ein Agent, der gegen ein Produktions-Replikat debuggt, liest die Zeilen, die den Bug erklären, ohne Zugangsdaten, die in seinen Kontext lecken könnten, und ohne Weg zur Datenbank, sobald die App geschlossen ist.
FAQ
Wie verbinde ich mich mit einer Cloud SQL Instanz, die nur eine private IP hat?
Lege eine MySQL- oder PostgreSQL-Verbindung an, wähle unter Erreichen über Google Cloud SQL, gib den Verbindungsnamen der Instanz an und setze den Haken bei Private IP. AgentsRoom startet den Cloud SQL Auth Proxy mit --private-ip auf einem Loopback-Port und verbindet seinen Client damit. Deine Maschine muss die VPC der Instanz erreichen, zum Beispiel über ein VPN oder Interconnect.
Speichert AgentsRoom einen Service-Account-Schlüssel?
Nein. Der Proxy wird durch die Application Default Credentials autorisiert, die gcloud auth application-default login auf deiner Maschine angelegt hat. AgentsRoom speichert den Verbindungsnamen der Instanz und die beiden Optionen, von denen keine eine Zugangsberechtigung ist.
Kann ich mich ohne Datenbankpasswort verbinden?
Ja, mit IAM-Datenbankauthentifizierung. Aktiviere sie in der Verbindung, und der Proxy läuft mit --auto-iam-authn: Er meldet dich mit deiner Google-Identität an, das Passwortfeld entfällt, und der Benutzer ist dein IAM-Datenbankbenutzer. Auf der Instanz muss die IAM-Authentifizierung aktiviert und dieser Benutzer angelegt sein.
Was muss ich installiert haben?
Den Cloud SQL Auth Proxy in Version 2 (gcloud components install cloud-sql-proxy oder Googles eigenständiger Download) und einen gcloud-Login für die Application Default Credentials. gcloud selbst wird nur für den Button Meine Instanzen auflisten gebraucht.
Was passiert, wenn mein gcloud-Login abläuft?
Der Proxy lehnt die Verbindung ab und protokolliert den Grund. AgentsRoom liest dieses Log und zeigt eine verständliche Meldung, die dir sagt, dass du gcloud auth application-default login ausführen sollst, statt eines nackten Verbindungsfehlers. Dann versuchst du es erneut.
Welcher lokale Port wird verwendet, und wer kann ihn erreichen?
Das Betriebssystem wählt beim Öffnen der Verbindung einen freien Port, und der Proxy lauscht ausschließlich auf 127.0.0.1. Nichts im lokalen Netzwerk kann ihn erreichen, und der Proxy endet, wenn die Verbindung geschlossen oder die App beendet wird.
Welche Cloud SQL Engines werden unterstützt?
Cloud SQL for MySQL und Cloud SQL for PostgreSQL. Cloud SQL for SQL Server wird nicht unterstützt, weil AgentsRoom noch keinen SQL Server Client hat; frage ihn im öffentlichen Backlog an, und er wird mitgezählt.
Funktioniert es unter Windows und Linux?
Ja. cloud-sql-proxy ist eine native Binärdatei für macOS, Windows und Linux, und AgentsRoom startet ihn auf allen dreien gleich. Die Handy-App listet dieselben Verbindungen und fragt sie schreibgeschützt über deinen Desktop ab.
Kann ein KI-Agent die Datenbank über den Proxy abfragen?
Ja, standardmäßig schreibgeschützt. Ein Agent nennt über AgentsRoom MCP eine gespeicherte Verbindung beim Namen, die App startet den Proxy und führt das Statement selbst aus, und nur die Ergebnismenge kommt zurück. Der Agent erhält nie eine Google-Zugangsberechtigung oder ein Datenbankpasswort, und db_query lehnt alles außer Lesezugriffen ab, es sei denn, die Verbindung ist schreibbar und du hast dafür Agenten Schreibzugriff erlauben aktiviert.
Das könnte dir auch gefallen
Datenbankverbindungen
Speichere deine MySQL-, PostgreSQL- und MongoDB-Verbindungen, erreiche eine Datenbank in einem privaten Subnetz über einen SSH-Tunnel oder eine AWS SSM Session und lass deine KI-Agenten sie über MCP abfragen. Standardmäßig schreibgeschützt, ein Statement pro Aufruf, begrenzte Ergebnismengen, und das Passwort erreicht den Agenten nie. Export, Import und Kopie von Datenbank zu Datenbank inklusive.
RDS über AWS SSM
Erreiche eine Amazon RDS Instanz ohne öffentlichen Endpunkt von deiner eigenen Maschine aus, über aws ssm start-session und das Dokument AWS-StartPortForwardingSessionToRemoteHost. Kein Bastion-Host, kein VPN, keine eingehende SSH-Regel. AgentsRoom öffnet die Session auf einem Loopback-Port und verbindet den Datenbank-Client darüber. MySQL, PostgreSQL und MongoDB, also RDS MySQL, RDS PostgreSQL, Aurora und DocumentDB.
Secret Manager
Speichere API-Keys, Tokens und Passwörter im Schlüsselbund deines Betriebssystems, referenziere sie als {{secret:NAME}} in Dev-Befehlen und Agenten-Umgebungen, und lass AgentsRoom sie beim Start auflösen. Agenten sehen die Namen, nie die Werte, und nichts wird je auf einen Server synchronisiert.
SSH-Verbindungen
Speichere deine SSH-Verbindungen, öffne ein integriertes Terminal über SSH und starte Claude Code, Codex oder Antigravity CLI direkt auf deinem Remote-Server oder VPS. Authentifizierung per SSH-Schlüssel oder Passwort, Verbindungsprofile pro Projekt, kein separater SSH-Client nötig.
Frag deine private Cloud SQL Instanz ab
Lade AgentsRoom herunter, wähle deine Cloud SQL Instanz und frage sie über den Cloud SQL Auth Proxy mit deinem eigenen gcloud-Login ab: keine Bastion-VM, keine öffentliche IP, kein Schlüssel auf der Platte.
Companion-App: Agenten auch unterwegs im Blick behalten
Nutzen Sie Claude, Codex, Antigravity CLI oder einen anderen KI-Anbieter.
Bugs und Wünsche direkt in dein öffentliches Backlog schicken.