Terraform — Provider GCP

Fiche express
Type	Provider Terraform pour le cloud public
Provider	hashicorp/google
Auth recommandée	compte de service attaché à la ressource, pas de clé JSON en dur
Backend de state	GCS (Google Cloud Storage)
Voir aussi	GCP · Terraform — Concepts fondamentaux · Terraform — Provider AWS · Terraform — Provider Azure

Cette page couvre le provider Terraform google : authentification, ressources typiques et backend de state sur GCS. Pour une présentation générale de GCP (CLI, organisation en projets, supervision), voir la page dédiée. Pour les notions transverses de state et de verrouillage, voir Terraform — Concepts fondamentaux.

Déclaration du provider

terraform {
  required_version = ">= 1.6"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}

provider "google" {
  project = "mon-projet-exemple"
  region  = "europe-west1"
  zone    = "europe-west1-b"
}

Authentification

Comme rappelé sur la page GCP, une clé JSON de compte de service téléchargée ne doit jamais figurer en dur dans le code Terraform ni dans un dépôt. Le provider google résout les identifiants dans cet ordre de préférence :

1. compte de service attaché (attached service account) à la ressource qui exécute Terraform (VM Compute Engine, Cloud Build, GKE Workload Identity) — aucune clé à gérer ;
2. fédération d'identité de charge de travail (workload identity federation) depuis une CI externe (GitLab CI, GitHub Actions) — le pipeline échange un jeton OIDC contre des identifiants Google temporaires, sans clé stockée ;
3. à défaut, clé JSON de compte de service stockée dans un gestionnaire de secrets (Secret Manager, variable protégée CI) — solution de repli, cas exceptionnel comme mentionné sur la page GCP.

provider "google" {
  project = "mon-projet-exemple"
  region  = "europe-west1"
  # aucun champ credentials : résolution via Application Default Credentials
  # (compte de service attaché ou fédération d'identité)
}

Ressources typiques

resource "google_project" "app" {
  name       = "Projet Exemple"
  project_id = "exemple-app-prod"
  org_id     = "000000000000"
}

resource "google_compute_instance" "web" {
  name         = "web-01"
  machine_type = "e2-micro"
  zone         = "europe-west1-b"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    network = "default"
    access_config {}
  }
}

• google_project — projet GCP, unité structurante (facturation + permissions IAM), sans équivalent direct chez AWS ou Azure (voir la page GCP).
• google_compute_instance — instance Compute Engine (l'équivalent conceptuel de l'EC2 AWS ou de la VM Azure).

Backend de state : GCS

Le backend recommandé pour GCP stocke le state dans un bucket Google Cloud Storage. Le verrouillage s'appuie sur le mécanisme natif de GCS, sans composant additionnel (même logique que le backend Azure, à la différence du backend S3 historique qui nécessite une table DynamoDB séparée).

terraform {
  backend "gcs" {
    bucket = "exemple-tfstate-prod"
    prefix = "infra/network"
  }
}

Prérequis à créer une seule fois (hors Terraform, ou via un bootstrap séparé) :

resource "google_storage_bucket" "tfstate" {
  name     = "exemple-tfstate-prod"
  location = "EU"

  versioning {
    enabled = true
  }

  uniform_bucket_level_access = true
}

Le nom d'un bucket GCS doit être globalement unique ; exemple-tfstate-prod est un identifiant d'exemple, pas un bucket réel. Activer le versionnement du bucket permet de retrouver une version antérieure du state en cas de corruption.

Voir aussi

• GCP — CLI, organisation en projets, supervision
• Terraform — Concepts fondamentaux — state, backend, verrouillage
• Terraform — Provider AWS · Terraform — Provider Azure
• Terraform — Modules et variables