Votre appli de production appelle Google Cloud, Azure ou un autre fournisseur OIDC sans aucune clé : while signe un jeton de courte durée, que le fournisseur échange.

Vous, à votre agent : Fais lire BigQuery par l’appli, sans clé de compte de service.

Ce que votre agent écrit

Votre agent l’écrit dans while.yaml, à la racine de votre appli :

while.yaml

services:
  - name: web
    port: 3000
    connections: [stockage]

Ce que reçoit votre appli

Votre appli reçoit ces variables d’environnement à chaque mise en ligne :

Variable	Ce qu’elle contient
`<NOM>_URL`	L’adresse de la connexion. Le relais de while ajoute le jeton d’accès.

Quand vous en servir

Servez-vous-en pour appeler un service cloud sans aucune clé, par fédération d’identité OIDC (Workload Identity Federation chez Google, identifiant fédéré chez Azure).

Comment ça marche

Une connexion fédérée joint Google Cloud, Azure ou un fournisseur OIDC sans aucun secret. while signe un jeton de 5 minutes pour une appli de production liée, et le fournisseur l’échange contre un jeton d’accès d’une heure au plus.

Ce qu’il faut savoir

Seule la version en ligne d’une appli de production liée obtient un jeton (set_connection_binding, validation stricte), jamais une prévisualisation, un poste ou un agent. Chaque liaison donne les commandes exactes à poser chez le fournisseur (gcloud, az), avec une condition sur son sub exact : while ne les lance pas.

Une liste noire refuse ce qui fabrique un identifiant, change des droits ou fait tourner du code ailleurs. « Valider chaque appel » accorde un droit à usage unique de 15 minutes. La base de confiance comprend aussi les administrateurs du coffre de while, et la page de la connexion le dit.

Case cochée, valider une version d’une production liée, c’est la laisser agir chez le fournisseur avec ce qui a été accordé à son identité. Une commande lance alors un fichier de l’image (node server.js, sh scripts/demarrer.sh), jamais du code en ligne (sh -c, node -e), et les secrets arrivent en fichier.

Il y a deux chemins vers Google, et le choix revient à une personne. Par clé (connexion jwt, modele google), la clé d’un compte de service est gardée par while, jamais dans l’appli, mais c’est une clé de longue durée, à changer si elle fuit. Par fédération d’identité OIDC (Workload Identity Federation chez Google, identifiant fédéré chez Azure) (connexion federee), c’est la même chose sans aucune clé, et seule la production appelle Google. La fédération a en plus une case sur la liaison, décochée par défaut : cochée, chaque mise en production du projet attend le clic d’une personne approbatrice (une autre que celle qui la demande, s’il y en a une autre), et seul du code validé agit chez Google.

Les outils MCP de votre agent

Votre agent s’en occupe avec les outils declare_connection, list_connections et call_connection.

Connexions fédérées