Ton instance Cloud SQL n'a pas d'IP publique.
Atteins-la par son nom, sans VM bastion.
AgentsRoom lance le Cloud SQL Auth Proxy à l'ouverture de la connexion et y branche son client de base de données. Tu donnes le nom de connexion de l'instance, project:region:instance, ou tu la choisis dans la liste que ta propre connexion gcloud peut voir.
Le proxy est autorisé par tes Application Default Credentials (identifiants par défaut de l'application), donc AgentsRoom ne stocke aucune clé de compte de service. Avec l'authentification IAM à la base, il n'y a même plus de mot de passe. Et un agent IA de code peut interroger la même instance, en lecture seule.
Comment AgentsRoom atteint une instance Cloud SQL sur son IP privée via le Cloud SQL Auth Proxy, sans rien stocker côté app.
Une instance Cloud SQL avec seulement une IP privée, c'est la bonne configuration, mais aussi une configuration pénible. La base vit dans ton VPC, son IP publique est coupée, et les seules machines qui peuvent l'atteindre sont celles qui sont dans ce réseau. Et puis un bug oblige à regarder trois lignes, depuis un portable.
Google fournit déjà la réponse : le Cloud SQL Auth Proxy. Il ouvre une connexion chiffrée vers l'instance, autorisée par ton identité Google plutôt que par une liste d'IP, et l'expose sur un port local. La vraie friction, c'est tout ce qu'il y a autour : l'installer, retenir le nom de connexion de l'instance, le lancer dans un terminal avant d'ouvrir un client, et l'oublier en train de tourner ensuite.
AgentsRoom s'occupe de cette partie. Tu choisis Google Cloud SQL dans le champ « Passer par » d'une connexion de base de données, tu indiques l'instance, tu coches IP privée ou Authentification IAM à la base si tu en as besoin, et ensuite ouvrir cette base se fait en un clic. Le proxy démarre avec la connexion et s'arrête avec elle.
Les contournements habituels coûtent tous quelque chose
Trois réponses au même problème, et ce que chacune te fait payer.
Une VM bastion rien que pour ça
Une VM Compute Engine avec un port SSH, gardée dans le VPC uniquement pour qu'on puisse de temps en temps ouvrir un tunnel vers la base. Elle demande des mises à jour, elle coûte de l'argent à chaque heure, et ses clés SSH et ses règles de pare-feu dérivent au rythme des arrivées et des départs dans l'équipe.
Une IP publique et une liste d'autorisations
Activer l'IP publique et ajouter ton adresse perso aux réseaux autorisés marche jusqu'à ce que ton adresse change, et entre-temps la base écoute sur internet. C'est l'exception qu'on ne retire jamais.
Une clé de compte de service sur un portable
Télécharger une clé JSON pour lancer le proxy, c'est le raccourci que tout le monde finit par regretter : un identifiant à longue durée de vie dans un dossier Téléchargements, copié dans des scripts et des prompts, que personne ne renouvelle et que personne ne sait tracer.
D'une instance Cloud SQL privée à un résultat de requête
Quatre étapes, faites une seule fois, puis c'est un clic.
Connecte-toi avec gcloud, une fois
Lance gcloud auth application-default login sur ta machine. Les Application Default Credentials qu'il crée sont ce que le proxy utilise pour atteindre l'instance. AgentsRoom n'en lit rien et n'en stocke rien.
Choisis l'instance dans « Passer par »
Crée une connexion MySQL ou PostgreSQL et choisis Google Cloud SQL dans « Passer par ». Saisis le nom de connexion de l'instance, project:region:instance, ou clique sur « Lister mes instances » pour la choisir parmi celles que ta connexion gcloud peut voir. L'hôte et le port disparaissent : l'instance est l'adresse.
Choisis IP privée et authentification IAM
Coche « IP privée » quand l'instance n'a pas d'adresse publique et que ta machine rejoint son VPC par un VPN ou une Interconnect. Coche « Authentification IAM à la base » pour te connecter avec ton identité Google : le champ mot de passe disparaît, et l'utilisateur est ton utilisateur de base IAM.
Requête-la, ou laisse un agent la requêter
Ouvrir la connexion réserve un port loopback libre, y lance cloud-sql-proxy et attend qu'il accepte une connexion TCP. La console se connecte à 127.0.0.1 comme pour n'importe quelle autre connexion, et un agent IA peut l'interroger en MCP, en lecture seule. Fermer la connexion arrête le proxy.
La commande qu'AgentsRoom lance
Rien n'est réimplémenté. AgentsRoom lance le binaire cloud-sql-proxy de Google (version 2) comme processus enfant, avec ses arguments passés directement plutôt qu'à travers un shell. Si tu as déjà lancé le proxy à la main, c'est la ligne que tu connais déjà.
cloud-sql-proxy acme-prod:europe-west1:orders \
--address 127.0.0.1 --port 54321 \
--private-ip \
--auto-iam-authnL'instance et les deux options viennent de la connexion que tu as enregistrée. Le port local est choisi par le système d'exploitation à l'ouverture.
Le proxy accepte la connexion locale avant de vérifier quoi que ce soit, puis la coupe et note la raison dans ses logs quand quelque chose ne va pas. AgentsRoom lit ces logs et te donne la vraie cause : le proxy n'est pas installé, ta connexion gcloud a expiré (avec la commande à lancer), ton compte n'a pas le rôle Cloud SQL Client, l'instance n'a pas d'IP privée, ou le nom de l'instance est faux.
Ce qui doit être vrai avant que ça marche
AgentsRoom pilote ta configuration Google Cloud, il ne la remplace pas. Ce sont les mêmes choses dont le proxy a besoin tout seul.
cloud-sql-proxy sur ta machine
La version 2 du Cloud SQL Auth Proxy, dans ton PATH. gcloud components install cloud-sql-proxy est le moyen le plus rapide ; Google le fournit aussi en téléchargement autonome. S'il manque, AgentsRoom le dit et te donne la commande.
Application Default Credentials
gcloud auth application-default login, lancé une fois. Quand cette connexion expire, l'erreur te dit de la relancer au lieu d'afficher un socket fermé.
Le rôle Cloud SQL Client
Ton compte Google doit avoir le rôle Cloud SQL Client sur le projet de l'instance, et l'API Cloud SQL Admin doit y être activée. L'authentification IAM à la base demande aussi le rôle Cloud SQL Instance User et un utilisateur IAM sur l'instance.
gcloud pour la liste de choix
« Lister mes instances » lance gcloud sql instances list dans ton projet actif, ou dans le projet que tu as commencé à saisir. Sans gcloud, tu peux quand même saisir le nom de connexion à la main.
Un chemin vers le VPC pour l'IP privée
IP privée veut dire que ta machine elle-même doit atteindre le VPC de l'instance, par un VPN, une Interconnect ou une machine dans le réseau. Sans ce chemin, laisse « IP privée » décochée et passe par l'IP publique avec le chiffrement du proxy.
Ce que fait le proxy, et ce qu'il refuse de faire
Les propriétés qui décident si on peut laisser ça configuré sur un portable.
Loopback uniquement
Le proxy écoute sur 127.0.0.1 et nulle part ailleurs. La base n'est jamais republiée sur le réseau local : le Wi-Fi d'un café ne devient pas un chemin vers la production.
Un port choisi par l'OS
AgentsRoom demande un port libre au système d'exploitation et le donne au proxy. Pas de port fixe à retenir, aucune collision avec un autre proxy lancé à la main.
Prêt veut dire prêt
La connexion ne s'ouvre qu'une fois que le port local accepte le TCP, et un proxy qui s'arrête aussitôt remonte la raison qu'il a affichée. Pas d'attente arbitraire, pas de client qui se connecte trop tôt.
Aucune clé stockée
Le proxy est autorisé par tes Application Default Credentials. AgentsRoom stocke le nom de connexion de l'instance et deux options, dont aucune n'est un identifiant, et aucune clé de compte de service ne passe jamais par l'app.
La base reste en lecture seule
Une connexion de base de données est en lecture seule à sa création. Une écriture demande que cette connexion soit rendue accessible en écriture et une confirmation explicite, plus insistante sur une connexion marquée production.
Une instruction par appel
Chaque appel porte exactement une instruction, donc rien ne se cache derrière un point-virgule, et les résultats sont plafonnés pour qu'une requête large ne noie ni une fenêtre ni le contexte d'un agent.
Pourquoi c'est moins d'accès, pas plus
Rien n'est ouvert côté instance. L'IP publique peut rester coupée, aucun réseau n'est ajouté à la liste autorisée, et aucune VM avec un port SSH n'est gardée en vie pour la requête occasionnelle. Le proxy chiffre la connexion de bout en bout jusqu'à l'instance.
L'autorisation reste là où ton organisation la gère : ton identité Google et ses rôles IAM. L'accès accordé à cette identité est journalisé comme n'importe quelle autre connexion Cloud SQL et s'arrête le jour où le rôle est retiré. AgentsRoom garde le nom de l'instance, le choix IP privée et le choix IAM, et rien qui puisse être rejoué par quelqu'un qui les aurait lus.
Côté base, les garde-fous sont ceux de toute connexion AgentsRoom : lecture seule par défaut, une instruction par appel, résultats plafonnés, et un indicateur production qui durcit la confirmation d'écriture. Un agent IA qui interroge en MCP reçoit un résultat, jamais un identifiant, et ne peut pas écrire à moins que tu aies rendu cette connexion accessible en écriture et activé « Autoriser les agents à écrire » pour elle.
MySQL et PostgreSQL, pas encore SQL Server
Cloud SQL fait tourner MySQL, PostgreSQL et SQL Server. AgentsRoom atteint les deux premiers via le proxy, et n'a pas de client SQL Server aujourd'hui. AlloyDB, qui a son propre proxy, n'est pas couvert non plus.
Le prochain moteur ou service est décidé par ce que les gens demandent. Si le tien manque, dis lequel sur le backlog public et il est compté.
Demande ton moteur de base de donnéesUn agent peut aussi l'interroger, en lecture seule
Une fois la connexion créée, un agent IA de code l'utilise via le MCP d'AgentsRoom en la nommant : db_list, db_schema pour parcourir tables et colonnes, db_query pour une instruction avec un nombre de lignes plafonné. Un agent peut aussi enregistrer lui-même une connexion Cloud SQL avec db_connection_new ou db_connection_save, en donnant le nom de connexion de l'instance.
AgentsRoom lance lui-même le proxy quand l'agent le demande, donc l'agent ne manipule jamais un identifiant Google, un mot de passe de base ou un numéro de port. Ce qui revient, c'est un résultat de requête. Les écritures exigent une connexion accessible en écriture et le réglage « Autoriser les agents à écrire », désactivé par défaut.
Un agent qui débogue sur une réplique de production lit les lignes qui expliquent le bug, sans identifiant à laisser fuiter dans son contexte et sans chemin vers la base une fois l'app fermée.
FAQ
Comment me connecter à une instance Cloud SQL qui n'a qu'une IP privée ?
Crée une connexion MySQL ou PostgreSQL, choisis Google Cloud SQL dans « Passer par », donne le nom de connexion de l'instance et coche « IP privée ». AgentsRoom lance le Cloud SQL Auth Proxy avec --private-ip sur un port loopback et y branche son client. Ta machine doit atteindre le VPC de l'instance, par un VPN ou une Interconnect par exemple.
AgentsRoom stocke-t-il une clé de compte de service ?
Non. Le proxy est autorisé par les Application Default Credentials que gcloud auth application-default login a créés sur ta machine. AgentsRoom stocke le nom de connexion de l'instance et les deux options, dont aucune n'est un identifiant.
Puis-je me connecter sans mot de passe de base de données ?
Oui, avec l'authentification IAM à la base. Coche-la dans la connexion et le proxy tourne avec --auto-iam-authn : il te connecte avec ton identité Google, le champ mot de passe disparaît, et l'utilisateur est ton utilisateur de base IAM. L'authentification IAM doit être activée sur l'instance et cet utilisateur créé.
Qu'est-ce que je dois avoir d'installé ?
Le Cloud SQL Auth Proxy, version 2 (gcloud components install cloud-sql-proxy, ou le téléchargement autonome de Google), et une connexion gcloud pour les Application Default Credentials. gcloud lui-même n'est nécessaire que pour le bouton « Lister mes instances ».
Que se passe-t-il quand ma connexion gcloud expire ?
Le proxy refuse la connexion et note la raison dans ses logs. AgentsRoom lit ces logs et affiche un message clair qui te dit de lancer gcloud auth application-default login, au lieu d'une erreur de connexion brute. Ensuite tu réessaies.
Quel port local est utilisé, et qui peut l'atteindre ?
Le système d'exploitation choisit un port libre à l'ouverture de la connexion, et le proxy n'écoute que sur 127.0.0.1. Rien sur le réseau local ne peut l'atteindre, et le proxy s'arrête quand la connexion se ferme ou que l'app se quitte.
Quels moteurs Cloud SQL sont supportés ?
Cloud SQL for MySQL et Cloud SQL for PostgreSQL. Cloud SQL for SQL Server n'est pas supporté car AgentsRoom n'a pas encore de client SQL Server ; demande-le sur le backlog public et il est compté.
Est-ce que ça marche sur Windows et Linux ?
Oui. cloud-sql-proxy est un binaire natif sur macOS, Windows et Linux, et AgentsRoom le lance de la même façon sur les trois. L'app mobile liste les mêmes connexions et les interroge en lecture seule via ton desktop.
Un agent IA peut-il interroger la base via le proxy ?
Oui, en lecture seule par défaut. Un agent nomme une connexion enregistrée via le MCP d'AgentsRoom, l'app lance le proxy et exécute l'instruction elle-même, et seul le résultat revient. L'agent ne reçoit jamais d'identifiant Google ni de mot de passe de base, et db_query refuse tout sauf une lecture, à moins que la connexion soit accessible en écriture et que tu aies activé « Autoriser les agents à écrire » pour elle.
Tu pourrais aussi aimer
Connexions bases de données
Enregistre tes connexions MySQL, PostgreSQL et MongoDB, atteins une base dans un sous-réseau privé via un tunnel SSH ou une session AWS SSM, et laisse tes agents IA l'interroger en MCP. Lecture seule par défaut, une instruction par appel, résultats plafonnés, et le mot de passe n'atteint jamais l'agent. Export, import et copie de base à base inclus.
RDS via AWS SSM
Atteins une instance Amazon RDS sans endpoint public, depuis ta propre machine, via aws ssm start-session et le document AWS-StartPortForwardingSessionToRemoteHost. Pas de bastion à maintenir, pas de VPN, pas de règle SSH entrante. AgentsRoom ouvre la session sur un port loopback et y branche son client de base de données. MySQL, PostgreSQL et MongoDB, donc RDS MySQL, RDS PostgreSQL, Aurora et DocumentDB.
Gestionnaire de secrets
Range tes clés d'API, tes tokens et tes mots de passe dans le trousseau de ton système, référence-les avec {{secret:NAME}} dans tes commandes de dev et les environnements de tes agents, et laisse AgentsRoom les résoudre au lancement. Les agents voient les noms, jamais les valeurs, et rien n'est jamais synchronisé vers un serveur.
Connexions SSH
Enregistre tes connexions SSH, ouvre un terminal SSH intégré et lance Claude Code, Codex ou Antigravity CLI directement sur ton serveur distant ou ton VPS. Authentification par clé ou mot de passe, profils de connexion par projet, sans client SSH séparé.
Interroge ton instance Cloud SQL privée
Télécharge AgentsRoom, choisis ton instance Cloud SQL et interroge-la via le Cloud SQL Auth Proxy avec ta propre connexion gcloud : pas de VM bastion, pas d'IP publique, pas de clé sur le disque.
App companion : suivez vos agents en déplacement
Utilisez Claude, Codex, Antigravity CLI ou un autre fournisseur IA.
Remontez bugs et demandes directement dans votre backlog public.