Dernière révision : mai 2026
Configurez les services AWS figurant à l'examen AGWA avec Terraform simple — un bloc à la fois, chacun étant lié à un domaine de l'examen. Le même code fonctionne sur OpenTofu.
À la fin de ce labo, vous aurez provisionné, avec Terraform pur, le substrat côté GCP que tout administrateur Google Workspace devrait comprendre — l'API Cloud Identity activée, un groupe IAM créé au niveau du projet, le groupe lié à un rôle de lecteur, et un récepteur Cloud Audit Logs acheminant les événements d'audit au niveau de l'organisation vers un bucket de journalisation dédié. Quatre blocs ; la frontière Cloud Identity + Audit Logs testée par l'examen AGWA.
Déposez les extraits dans un unique main.tf, exécutez terraform init, puis terraform apply étape par étape.
Note : la majeure partie du contenu de l'examen AGWA se trouve dans la console d'administration Workspace (routage Gmail, politiques de partage Drive, gestion des appareils mobiles, accès contextuel) qui n'est pas directement gérable par Terraform via le fournisseur google. Le fournisseur googleworkspace existe mais nécessite un compte de service super-administrateur Workspace avec délégation à l'échelle du domaine — ce qui est hors de portée pour un labo.
>= 1.5 ou OpenTofu >= 1.6.your-project-id et your-org-id dans les extraits ci-dessous.Tout est gratuit dans le cadre du labo :
Le produit Workspace lui-même est facturé par utilisateur (environ 6 $/utilisateur/mois pour Business Starter, jusqu'à environ 30 $/utilisateur/mois pour Enterprise) — ce qui est hors du cadre du labo. Le substrat ci-dessous est gratuit.
Activez les API Cloud Identity, IAM et Cloud Logging.
terraform {
required_version = ">= 1.5"
required_providers {
google = { source = "hashicorp/google", version = "~> 6.0" }
}
}
provider "google" {
project = "your-project-id" # REPLACE
region = "us-central1"
}
locals {
labels = {
project = "certlabpro-agwa"
managed_by = "terraform"
}
}
resource "google_project_service" "cloudidentity" {
service = "cloudidentity.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "logging" {
service = "logging.googleapis.com"
disable_on_destroy = false
}Les Groupes Cloud Identity sont le miroir côté GCP des groupes Google Workspace — ils résident dans le même annuaire d'identités et sont accessibles via le même format group-email@your-domain.com. L'examen AGWA teste ce modèle d'identité à panneau unique : un utilisateur provisionné dans Workspace est la même identité qui obtient des liaisons IAM dans GCP.
Nous créons un groupe de sécurité dev-readers@your-domain.com. Remplacez your-org-id par votre ID client Cloud Identity (trouvez-le via gcloud organizations list → le champ directoryCustomerId).
Cette ressource nécessite la propriété du domaine — elle échouera si vous ne contrôlez pas your-domain.com et si l'API Cloud Identity n'est pas activée au niveau de l'organisation. Pour un labo rapide sans domaine réel, sautez cette étape et utilisez une identité IAM existante à l'Étape 3.
resource "google_cloud_identity_group" "dev_readers" {
display_name = "dev-readers"
description = "Lab Cloud Identity group for the AGWA walkthrough"
parent = "customers/your-org-id" # REPLACE — find via `gcloud organizations list`
group_key {
id = "dev-readers@your-domain.com" # REPLACE with your Workspace domain
}
labels = {
"cloudidentity.googleapis.com/groups.discussion_forum" = ""
}
initial_group_config = "WITH_INITIAL_OWNER"
depends_on = [google_project_service.cloudidentity]
}Les administrateurs Workspace attribuent régulièrement des permissions GCP aux groupes Workspace — le modèle recommandé par AGWA est d'« accorder des rôles aux groupes, gérer l'appartenance dans Workspace ». Nous lions le groupe dev-readers de l'Étape 2 au rôle roles/viewer du projet actuel. Toute personne ajoutée à dev-readers@your-domain.com par son administrateur Workspace hérite instantanément du rôle de lecteur sur ce projet GCP. Toute personne retirée le perd.
Notez le préfixe group: sur le champ member d'IAM — c'est la syntaxe canonique pour lier une identité de groupe. Autres préfixes testés par l'examen AGWA : user: (individuel), serviceAccount: (compte de service), domain: (tous les utilisateurs d'un domaine).
data "google_project" "current" {}
resource "google_project_iam_member" "dev_readers_viewer" {
project = data.google_project.current.project_id
role = "roles/viewer"
member = "group:${google_cloud_identity_group.dev_readers.group_key[0].id}"
}L'examen AGWA teste la portée des journaux d'audit Cloud : les journaux d'activité d'administration sont toujours activés et gratuits ; les journaux d'accès aux données sont désactivés par défaut et facturés normalement ; les journaux d'événements système sont toujours activés et gratuits ; les journaux de politique refusée (refus VPC-SC) sont toujours activés et gratuits.
Nous créons un bucket de journalisation dédié (séparé des buckets par défaut _Required et _Default) nommé audit-events, puis un récepteur de journaux acheminant chaque journal d'audit lié à IAM vers celui-ci. Cela offre aux équipes de conformité une fenêtre de rétention distincte des journaux opérationnels dans _Default — le modèle recommandé par AGWA pour que la rétention des journaux d'audit survive à la réponse aux incidents.
resource "google_logging_project_bucket_config" "audit" {
project = data.google_project.current.project_id
location = "global"
retention_days = 400 # 13 months — typical compliance ask
bucket_id = "audit-events"
depends_on = [google_project_service.logging]
}
resource "google_logging_project_sink" "audit_sink" {
name = "certlabpro-agwa-audit-sink"
destination = "logging.googleapis.com/${google_logging_project_bucket_config.audit.id}"
filter = "logName:\"cloudaudit.googleapis.com\" AND protoPayload.serviceName=\"iam.googleapis.com\""
unique_writer_identity = true
}terraform destroy détruit tout. Le groupe Cloud Identity est supprimé (uniquement de Cloud Identity ; s'il s'agissait d'un vrai groupe Workspace, restaurez-le depuis la console d'administration dans les 25 jours). La liaison IAM est détachée ; les membres du groupe perdent immédiatement le rôle de lecteur. Le bucket et le récepteur de journalisation sont proprement détruits ; la rétention de 400 jours n'est pertinente que tant que les journaux y sont acheminés.
AGWA couvre des interfaces d'administration Workspace qui ne sont pas directement gérables par Terraform via le fournisseur google — règles de routage Gmail / filtres anti-spam / DMARC / DKIM / SPF, paramètres de partage Drive par défaut / drives partagés / étiquettes, politiques d'enregistrement Meet, provisionnement de salles Calendar, gestion des appareils mobiles (avancée + basique), politiques de navigateur Chrome, politiques d'accès contextuel (qui ont bien une interface TF via google_access_context_manager_* mais vivent au niveau de l'organisation et nécessitent Cloud Identity Premium), règles de rétention Vault, exportations eDiscovery, et l'arborescence plus large des paramètres de la console d'administration Workspace.
Le fournisseur Terraform googleworkspace existe pour les utilisateurs / groupes / unités organisationnelles / domaines / attributions de rôles au sein de Workspace lui-même, mais nécessite un compte de service avec délégation à l'échelle du domaine et un subject de super-administrateur — ce qui est hors de portée pour un labo rapide.
Nous nous en tenons aux primitives Groupes Cloud Identity + IAM + Journaux d'audit car elles représentent la frontière documentée entre Workspace et GCP — la partie que tout administrateur Workspace doit maîtriser. Pour les modèles d'administration internes à Workspace (Gmail / Drive / Meet / mobile / Chrome), les sections Guide + Editorial couvrent la surface conceptuelle.