Zuletzt überprüft: Mai 2026
Erstellen Sie die AWS-Dienste der AGWA-Prüfung mit reinem Terraform — ein Block nach dem anderen, jeweils abgestimmt auf eine Prüfungsdomäne. Derselbe Code funktioniert auch mit OpenTofu.
Am Ende dieses Labs haben Sie mit reinem Terraform das GCP-seitige Substrat bereitgestellt, das jeder Google Workspace-Administrator verstehen sollte – die Cloud Identity API aktiviert, eine IAM-Gruppe auf Projektebene erstellt, die Gruppe an eine Betrachterrolle gebunden und eine Cloud Audit Logs-Senke, die Audit-Ereignisse auf Organisationsebene in einen dedizierten Logging-Bucket leitet. Vier Blöcke; die von der AGWA-Prüfung getestete Grenze zwischen Cloud Identity und Audit Logs.
Fügen Sie die Snippets in eine einzige main.tf ein, führen Sie terraform init aus und anschließend terraform apply Schritt für Schritt.
Hinweis: Die meisten Prüfungsinhalte von AGWA befinden sich in der Workspace-Administratorkonsole (Gmail-Routing, Drive-Freigaberichtlinien, Verwaltung mobiler Geräte, kontextsensitiver Zugriff), die nicht direkt über den google-Provider mit Terraform konfiguriert werden kann. Der googleworkspace-Provider existiert, erfordert jedoch ein Workspace-Super-Admin-Dienstkonto mit domänenweiter Delegierung – dies liegt außerhalb des Umfangs eines Labs.
>= 1.5 oder OpenTofu >= 1.6.your-project-id und your-org-id in den folgenden Snippets.Im Umfang dieses Labs alles kostenlos:
Das Workspace-Produkt selbst wird pro Nutzer abgerechnet (ca. 6 $/Nutzer/Monat für Business Starter, bis zu ca. 30 $/Nutzer/Monat für Enterprise) – dies liegt außerhalb des Lab-Umfangs. Das unten beschriebene Substrat ist kostenlos.
Aktivieren Sie die Cloud Identity-, IAM- und Cloud Logging-APIs.
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
}Cloud Identity Groups sind das GCP-seitige Spiegelbild von Google Workspace-Gruppen – sie leben im selben Identitätsverzeichnis und sind über dasselbe Format gruppen-email@ihre-domain.com ansprechbar. Die AGWA-Prüfung testet dieses Single-Pane-of-Glass-Identitätsmodell: Ein in Workspace bereitgestellter Benutzer ist dieselbe Identität, die IAM-Bindungen in GCP erhält.
Wir erstellen eine Sicherheitsgruppe dev-readers@your-domain.com. Ersetzen Sie your-org-id durch Ihre Cloud Identity-Kunden-ID (zu finden über gcloud organizations list → das Feld directoryCustomerId).
Diese Ressource erfordert Domain-Besitz – sie schlägt fehl, wenn Sie your-domain.com nicht kontrollieren und die Cloud Identity API nicht auf Organisationsebene aktiviert haben. Für ein schnelles Lab ohne echte Domain überspringen Sie diesen Schritt und verwenden Sie eine bestehende IAM-Identität in Schritt 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]
}Workspace-Administratoren weisen Workspace-Gruppen regelmäßig GCP-Berechtigungen zu – das von AGWA empfohlene Muster ist Rollen an Gruppen vergeben, Mitgliedschaft in Workspace verwalten. Wir binden die dev-readers-Gruppe aus Schritt 2 an roles/viewer im aktuellen Projekt. Jeder, den sein Workspace-Administrator zu dev-readers@your-domain.com hinzufügt, erbt sofort die Betrachterrolle für dieses GCP-Projekt. Jeder, der entfernt wird, verliert sie.
Beachten Sie das Präfix group: im IAM-Feld member – dies ist die kanonische Syntax zum Binden einer Gruppenidentität. Weitere Präfixe, die in der AGWA-Prüfung getestet werden: user: (individuell), serviceAccount: (Dienstkonto), domain: (alle Benutzer in einer Domain).
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}"
}Die AGWA-Prüfung testet den Umfang von Cloud Audit Logs: Admin Activity-Logs sind immer aktiviert und kostenlos; Data Access-Logs sind standardmäßig deaktiviert und werden normal abgerechnet; System Event-Logs sind immer aktiviert und kostenlos; Policy Denied-Logs (VPC-SC-Ablehnungen) sind immer aktiviert und kostenlos.
Wir erstellen einen dedizierten Logging-Bucket (getrennt von den standardmäßigen _Required- und _Default-Buckets) namens audit-events und anschließend eine Log-Senke, die jedes IAM-bezogene Audit-Log dorthin leitet. Dies gibt Compliance-Teams ein separates Aufbewahrungsfenster von den operativen Logs in _Default – das von AGWA empfohlene Muster, damit die Aufbewahrung von Audit-Logs länger dauert als die Reaktion auf Vorfälle.
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 entfernt alles. Die Cloud Identity-Gruppe wird zerstört (nur aus Cloud Identity gelöscht; wenn es eine echte Workspace-Gruppe war, kann sie innerhalb von 25 Tagen aus der Administratorkonsole wiederhergestellt werden). Die IAM-Bindung wird gelöst; Gruppenmitglieder verlieren sofort die Betrachterrolle. Der Logging-Bucket + die Senke werden sauber entfernt; die 400-Tage-Aufbewahrung ist nur relevant, solange Logs dort landen.
AGWA deckt Workspace-Administrationsflächen ab, die nicht direkt über den google-Provider mit Terraform konfiguriert werden können – Gmail-Routing-Regeln / Spamfilter / DMARC / DKIM / SPF, Drive-Freigabestandards / geteilte Laufwerke / Labels, Meet-Aufzeichnungsrichtlinien, Calendar-Raumbereitstellung, Verwaltung mobiler Geräte (erweitert + grundlegend), Chrome-Browserrichtlinien, Context-Aware Access-Richtlinien (die eine TF-Oberfläche über google_access_context_manager_* haben, aber auf Organisationsebene angesiedelt sind und Cloud Identity Premium erfordern), Vault-Aufbewahrungsregeln, eDiscovery-Exporte und der gesamte Einstellungsbaum der Workspace-Administratorkonsole.
Der googleworkspace-Terraform-Provider existiert für Benutzer / Gruppen / Organisationseinheiten / Domains / Rollenzuweisungen innerhalb von Workspace selbst, erfordert aber ein Dienstkonto mit domänenweiter Delegierung und ein Super-Admin-subject – dies liegt außerhalb des Umfangs eines kurzen Labs.
Wir beschränken uns auf die grundlegenden Elemente von Cloud Identity Groups + IAM + Audit Logs, da sie die dokumentierte Grenze zwischen Workspace und GCP darstellen – der Teil, den jeder Workspace-Administrator beherrschen muss. Für Workspace-interne Admin-Muster (Gmail / Drive / Meet / Mobile / Chrome) decken die Abschnitte Handbuch und Editorial die konzeptuelle Oberfläche ab.