Última revisión: mayo de 2026
Crea los servicios de AWS del examen AGWA con Terraform puro: bloque a bloque, cada uno vinculado a un dominio del examen. El mismo código funciona en OpenTofu.
Al finalizar este laboratorio, habrá aprovisionado, con Terraform puro, la infraestructura del lado de GCP que todo administrador de Google Workspace debe comprender: la API de Cloud Identity habilitada, un grupo de IAM creado con alcance de proyecto, el grupo vinculado a un rol de visualizador y un destino de Cloud Audit Logs que enruta los eventos de auditoría a nivel de la organización a un bucket de registro dedicado. Cuatro bloques; el límite de Cloud Identity + Audit Logs que evalúa el examen AGWA.
Coloque los fragmentos en un único main.tf, ejecute terraform init, luego terraform apply paso a paso.
Nota: la mayor parte del contenido del examen AGWA se encuentra en la consola de administración de Workspace (enrutamiento de Gmail, políticas para compartir Drive, administración de dispositivos móviles, acceso con reconocimiento de contexto), que no es directamente "terraformable" a través del proveedor google. El proveedor googleworkspace existe, pero requiere una cuenta de servicio de superadministrador de Workspace con delegación de todo el dominio, lo cual está fuera del alcance de un laboratorio.
>= 1.5 o OpenTofu >= 1.6.your-project-id y your-org-id en los fragmentos a continuación.Todo gratis en el alcance del laboratorio:
El producto Workspace en sí se factura por puesto (aproximadamente $6/usuario/mes para Business Starter, hasta ~$30/usuario/mes para Enterprise) — fuera del alcance del laboratorio. La infraestructura a continuación es gratuita.
Habilite las API de Cloud Identity, IAM y 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
}Los Grupos de Cloud Identity son el espejo del lado de GCP de los grupos de Google Workspace; viven en el mismo directorio de identidades y son direccionables a través del mismo formato group-email@your-domain.com. El examen AGWA evalúa este modelo de identidad de panel único: un usuario aprovisionado en Workspace es la misma identidad que obtiene las vinculaciones de IAM en GCP.
Creamos un grupo de seguridad dev-readers@your-domain.com. Reemplace your-org-id con su ID de cliente de Cloud Identity (encuéntrelo a través de gcloud organizations list → el campo directoryCustomerId).
Este recurso necesita la propiedad del dominio: fallará a menos que controle your-domain.com y tenga la API de Cloud Identity habilitada en el ámbito de la organización. Para un laboratorio rápido sin un dominio real, omita este paso y use una identidad de IAM existente en el Paso 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]
}Los administradores de Workspace asignan regularmente permisos de GCP a los grupos de Workspace; el patrón recomendado por AGWA es otorgar roles a grupos, administrar membresías en Workspace. Vinculamos el grupo dev-readers del Paso 2 a roles/viewer en el proyecto actual. Cualquier persona cuyo administrador de Workspace la agregue a dev-readers@your-domain.com heredará instantáneamente el rol de Visualizador en este proyecto de GCP. Cualquier persona eliminada lo perderá.
Tenga en cuenta el prefijo group: en el campo member de IAM, esa es la sintaxis canónica para vincular una identidad de grupo. Otros prefijos que evalúa el examen AGWA: user: (individual), serviceAccount: (cuenta de servicio), domain: (todos los usuarios de un dominio).
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}"
}El examen AGWA evalúa el alcance de Cloud Audit Logs: los registros de actividad de administrador siempre están activados y son gratuitos; los registros de acceso a datos están desactivados por defecto y se facturan normalmente; los registros de eventos del sistema siempre están activados y son gratuitos; los registros de políticas denegadas (denegaciones de VPC-SC) siempre están activados y son gratuitos.
Creamos un bucket de registro dedicado (separado de los buckets predeterminados _Required y _Default) llamado audit-events, y luego un destino de registro que enruta cada registro de auditoría relacionado con IAM a él. Esto les da a los equipos de cumplimiento una ventana de retención separada de los registros operativos en _Default, el patrón recomendado por AGWA para que la retención de registros de auditoría supere la respuesta a incidentes.
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 destruye todo. El grupo de Cloud Identity se destruye (solo se elimina de Cloud Identity; si fuera un grupo real de Workspace, restáurelo desde la consola de administración dentro de los 25 días). La vinculación de IAM se desvincula; los miembros del grupo pierden el rol de Visualizador inmediatamente. El bucket de registro + destino se destruyen limpiamente; la retención de 400 días solo importa mientras los registros están llegando allí.
AGWA cubre superficies de administración de Workspace que no son directamente "terraformables" a través del proveedor google: reglas de enrutamiento de Gmail / filtros de spam / DMARC / DKIM / SPF, configuraciones predeterminadas para compartir Drive / unidades compartidas / etiquetas, políticas de grabación de Meet, aprovisionamiento de salas de Calendar, administración de dispositivos móviles (avanzada + básica), políticas del navegador Chrome, políticas de Acceso sensible al contexto (que SÍ tienen una superficie de TF a través de google_access_context_manager_* pero viven en el ámbito de la organización y necesitan Cloud Identity Premium), reglas de retención de Vault, exportaciones de eDiscovery y el árbol de configuración más amplio de la consola de administración de Workspace.
El proveedor de Terraform googleworkspace existe para usuarios / grupos / unidades organizativas / dominios / asignaciones de roles dentro del propio Workspace, pero requiere una cuenta de servicio con delegación de todo el dominio y un subject de superadministrador, lo cual está fuera del alcance de un laboratorio rápido.
Nos ceñimos a las primitivas de Grupos de Cloud Identity + IAM + Audit Logs porque son el límite documentado entre Workspace y GCP, la parte que todo administrador de Workspace debe poseer. Para los patrones de administración internos de Workspace (Gmail / Drive / Meet / móvil / Chrome), las secciones de Manual y Editorial cubren la superficie conceptual.