Le CLI gcloud utilise un état mutable global par défaut — une configuration active, un fichier ADC, partagés entre tous les terminaux et tous les processus. Cela crée des problèmes d’isolation des credentials lors du travail sur plusieurs projets clients. Les agents de codage IA ajoutent une contrainte supplémentaire : ils ne peuvent pas exécuter de flux d’authentification interactifs et ne peuvent pas se remettre d’une expiration de token en milieu de tâche.
Ce hub regroupe les notes sur le problème et ses solutions.
Le problème central
gcloud stocke tout dans ~/.config/gcloud/. Changer le projet actif dans un terminal affecte tous les autres processus lisant depuis ce répertoire. GCP Application Default Credentials explique les deux systèmes d’authentification distincts (credentials CLI vs ADC) et pourquoi exécuter une commande gcloud auth n’affecte pas l’autre — une source de confusion permanente.
La solution à quatre variables
La solution repose sur CLOUDSDK_CONFIG, une variable d’environnement qui redirige l’intégralité de l’état gcloud vers un répertoire différent par projet. Deux sessions utilisant des chemins CLOUDSDK_CONFIG différents ne peuvent pas interférer l’une avec l’autre.
CLOUDSDK_CONFIG for Per-Project gcloud Isolation couvre le fonctionnement de cette variable et pourquoi vous avez besoin de quatre variables au total — deux pour le CLI gcloud et deux pour les bibliothèques clientes — pour atteindre une isolation complète.
direnv Multi-Client GCP Setup couvre l’automatisation avec direnv pour que les credentials se chargent lorsque vous faites cd dans un répertoire client et se déchargent lorsque vous le quittez. Il s’agit du workflow quotidien : cinq minutes de configuration par client, puis c’est transparent.
Intégration dbt
dbt profiles.yml with env_var for Multi-Client GCP couvre comment l’interpolation env_var() dans profiles.yml permet à un seul fichier de configuration de servir tous les clients. dbt récupère le bon projet et les bonnes credentials depuis les variables d’environnement définies par direnv. La méthode service-account plutôt que oauth est le choix clé ici — elle fonctionne dans les environnements non interactifs, y compris les sessions agent.
Contraintes des agents IA
GCP Auth Constraints for AI Coding Agents couvre le comportement spécifique de Claude Code, Codex et Cursor. En résumé : Claude Code hérite des variables d’environnement shell (donc direnv fonctionne), Codex s’exécute dans des conteneurs isolés sans credentials ambiantes, et le terminal agent de Cursor n’hérite pas du tout des variables d’environnement. Les fichiers de clés de compte de service sont la seule méthode d’authentification qui fonctionne de manière fiable avec tous.
Le compromis sur le type de credential
Service Account Key Files vs Impersonation Tokens couvre le calcul de sécurité honnête. Google recommande de ne pas utiliser les fichiers de clés. WIF ne fonctionne pas pour le développement local. Les tokens d’impersonation offrent une meilleure sécurité mais cassent les sessions agent longues quand ils expirent. Pour la plupart des travaux d’analytics engineering en mode conseil, les fichiers de clés de compte de service avec une bonne hygiène (un compte de service par client, rôles minimaux, rotation à 90 jours, chmod 600) constituent le choix pragmatique.
Connexe : configuration IAM et comptes de service
BigQuery IAM Patterns — le modèle de rôle selon le principe du moindre privilège pour BigQuery, incluant la séparation des permissions données vs calcul.
dbt Service Account Setup for Multi-Project GCP Architectures — configuration IAM lorsque les données sources, le calcul de transformation et l’infrastructure s’étendent sur des projets GCP distincts.
Security Posture for AI Agents — sécurité agent plus large, incluant le périmètre des credentials et le principe d’isolation par client.