6 min de lecture

Gestion des secrets - 03 - Google Secret Manager : le guide pratique

Utiliser Google Secret Manager pour stocker et acceder a tes secrets. Setup, API, rotation et intégration avec Docker.

sécurité secrets Google Cloud vault DevOps
Gestion des secrets et vaults 4 / 10
  1. 01 Gestion des secrets - 00 - Pourquoi ton .env finira par te trahir
  2. 02 Gestion des secrets - 01 - Les 7 problèmes des secrets en .env
  3. 03 Gestion des secrets - 02 - Les solutions : du .env au vault manager
  4. 04 Gestion des secrets - 03 - Google Secret Manager : le guide pratique
  5. 05 Gestion des secrets - 04 - AWS Secrets Manager et ses alternatives
  6. 06 Gestion des secrets - 05 - HashiCorp Vault : le couteau suisse du secret management
  7. 07 Gestion des secrets - 06 - SOPS + age : chiffrer ses secrets dans git
  8. 08 Gestion des secrets - 07 - Secrets dans CI/CD : GitLab, GitHub et les bonnes pratiques
  9. 09 Gestion des secrets - 08 - Rotation des secrets : comment ne rien casser
  10. 10 Gestion des secrets - 09 - Glossaire
← Precedent Suivant →

03 - Google Secret Manager : le guide pratique

Ce que tu vas apprendre

  • Configurer Google Secret Manager de zero
  • Stocker, lire et versionner des secrets avec gcloud et l'API Node/Bun
  • Gerer les droits d'acces avec IAM et intégrer avec Docker

Prerequisites

Un compte Google Cloud (le tier gratuit suffit pour commencer). Le CLI gcloud installe.

Pourquoi Google Secret Manager

Google Secret Manager est un vault manage. Tu stockes tes secrets, Google les chiffre avec AES-256, tu y accedes par API ou CLI. Pas de serveur a gerer, pas de cluster a maintenir. Le service est disponible dans toutes les regions GCP, avec replication automatique.

Par rapport au .env qu'on utilise sur paltemps.fr, le gain est clair : chiffrement au repos, contrôle d'acces par IAM, audit trail dans Cloud Audit Logs, versioning automatique. Tout ce qui manque au fichier texte brut.

Setup initial

Commence par créer un projet GCP (ou utiliser un projet existant) et activer l'API :

bash# Creer un projet
gcloud projects create mon-projet-secrets --name="Secrets paltemps"

# Activer l'API Secret Manager
gcloud services enable secretmanager.googleapis.com --project=mon-projet-secrets

# Verifier que c'est actif
gcloud services list --enabled --project=mon-projet-secrets | grep secret

Ensuite, créé un service account pour que ton application puisse acceder aux secrets sans utiliser tes propres credentials :

bash# Creer le service account
gcloud iam service-accounts create paltemps-app \
  --display-name="paltemps app" \
  --project=mon-projet-secrets

# Donner le role "Secret Manager Secret Accessor"
gcloud projects add-iam-policy-binding mon-projet-secrets \
  --member="serviceAccount:paltemps-app@mon-projet-secrets.iam.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"

# Generer une cle JSON
gcloud iam service-accounts keys create sa-key.json \
  --iam-account=paltemps-app@mon-projet-secrets.iam.gserviceaccount.com

Ce fichier sa-key.json est lui-meme un secret. Ne le committe pas dans git (oui, c'est ironique). Stocke-le comme variable CI/CD dans ton pipeline GitLab.

Stocker un secret

bash# Depuis une valeur
echo -n "sk-ant-api03-xxxx" | gcloud secrets create ANTHROPIC_KEY \
  --data-file=- \
  --project=mon-projet-secrets

# Depuis un fichier
gcloud secrets create SMTP_PASS \
  --data-file=smtp-password.txt \
  --project=mon-projet-secrets

Le -n dans echo -n est important : sans lui, echo ajoute un saut de ligne a la fin de la valeur. Ta clé API finirait avec un \n invisible, et tu passerais 2 heures a debugger pourquoi l'API retourne "invalid key".

Lire un secret

bash# Derniere version
gcloud secrets versions access latest --secret=ANTHROPIC_KEY --project=mon-projet-secrets

# Version specifique
gcloud secrets versions access 2 --secret=ANTHROPIC_KEY --project=mon-projet-secrets

Acceder depuis du code TypeScript

Installe le SDK :

bashbun add @google-cloud/secret-manager

Puis dans ton application :

typescriptimport { SecretManagerServiceClient } from "@google-cloud/secret-manager";

const client = new SecretManagerServiceClient();

async function getSecret(name: string): Promise<string> {
  const [version] = await client.accessSecretVersion({
    name: `projects/mon-projet-secrets/secrets/${name}/versions/latest`,
  });

  const payload = version.payload?.data;
  if (!payload) throw new Error(`Secret ${name} is empty`);

  return typeof payload === "string"
    ? payload
    : Buffer.from(payload).toString("utf8");
}

// Usage
const anthropicKey = await getSecret("ANTHROPIC_KEY");
const smtpPass = await getSecret("SMTP_PASS");

Le client s'authentifié automatiquement si la variable GOOGLE_APPLICATION_CREDENTIALS pointe vers le fichier sa-key.json :

bashexport GOOGLE_APPLICATION_CREDENTIALS=/app/sa-key.json

En production Docker, tu montes le fichier comme volume :

yaml# docker-compose.yml
services:
  app:
    image: paltemps-api
    environment:
      - GOOGLE_APPLICATION_CREDENTIALS=/run/secrets/gcp-sa-key
    volumes:
      - ./sa-key.json:/run/secrets/gcp-sa-key:ro

Versioning

Chaque fois que tu mets à jour un secret, une nouvelle version est créée automatiquement :

bash# Mettre a jour (ajoute la version 2)
echo -n "sk-ant-api03-nouvelle-cle" | gcloud secrets versions add ANTHROPIC_KEY \
  --data-file=- \
  --project=mon-projet-secrets

# Lister les versions
gcloud secrets versions list ANTHROPIC_KEY --project=mon-projet-secrets

Les anciennes versions restent accessibles. Tu peux désactiver ou détruire une version spécifique :

bash# Desactiver (reversible)
gcloud secrets versions disable 1 --secret=ANTHROPIC_KEY --project=mon-projet-secrets

# Detruire (irreversible)
gcloud secrets versions destroy 1 --secret=ANTHROPIC_KEY --project=mon-projet-secrets

Rotation

La rotation avec Google Secret Manager suit un schema simple :

  1. Genere une nouvelle clé API auprès du fournisseur (Anthropic, OpenAI, etc.)
  2. Ajoute la nouvelle valeur comme nouvelle version du secret
  3. Deploie ton application (elle prend latest, donc la nouvelle version)
  4. Verifie que tout fonctionne
  5. Desactive l'ancienne version dans Secret Manager
  6. Revoque l'ancienne clé auprès du fournisseur

Pour la rotation automatique, Google propose un système base sur Pub/Sub et Cloud Functions. Un topic Pub/Sub se déclenché selon un planning, une Cloud Function généré le nouveau secret et le stocke. C'est documente dans le guide de rotation de Google.

En pratique, pour un projet comme paltemps.fr, la rotation manuelle suffit. L'automatisation a du sens si tu as des dizaines de secrets a renouveler régulièrement.

Contrôle d'acces avec IAM

La force d'un vault cloud, c'est le contrôle fin. Tu peux donner a un service account l'acces a un seul secret :

bash# Acces a ANTHROPIC_KEY uniquement
gcloud secrets add-iam-policy-binding ANTHROPIC_KEY \
  --member="serviceAccount:paltemps-app@mon-projet-secrets.iam.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor" \
  --project=mon-projet-secrets

C'est l'inverse du .env ou tout est accessible d'un bloc. Si le service qui a besoin de la clé Anthropic est compromis, il n'a pas acces au mot de passe SMTP.

Comme on l'a vu dans la serie sur le chiffrement, la segmentation des acces est un des principes fondamentaux de la gestion des clés.

Cout

Google Secret Manager est quasi gratuit pour les petits usages :

  • 6 versions actives de secrets : gratuit
  • Au-dela : $0.06 par version active par mois
  • Opérations d'acces : $0.03 pour 10 000 opérations
  • Opérations d'admin : $0.05 pour 10 000 opérations

Pour un projet comme paltemps.fr avec 8 secrets accedes quelques centaines de fois par jour, le coût mensuel serait de l'ordre de quelques centimes. Le vrai coût, c'est le temps de configuration initial.

Quand utiliser Google Secret Manager

Si tu es deja sur GCP, c'est un choix évident. Si tu n'es pas sur GCP (comme moi avec un VPS OVH), ca reste faisable mais ca ajoute une dépendance cloud. Il faut peser : est-ce que le gain en sécurité vaut la complexité d'intégration ?

Pour un solo dev sur un VPS, je dirais non. Les variables CI/CD + SOPS (article SOPS + age) suffisent. Pour une équipe qui grandit et qui a besoin d'audit trail et de rotation, oui.

Prochain article : on regarde l'équivalent chez AWS, avec une comparaison entre les deux.

Navigation : Precedent : 02 - Les solutions | Suivant : 04 - AWS Secrets Manager

Sources

Retrouve d'autres articles techniques sur paltemps.fr.

Publie le · Mis a jour le

Articles liés

Réservez un audit gratuit de 30 minutes. Je vous montre concrètement ce qu'on peut automatiser.

Découvrir Pal'Temps