GCP IAM: cómo se audita y se escala en Google Cloud

2026-11-06 · 10 min de lectura

GCP tiene su propio modelo IAM con jerarquía de organización, roles primitivos/predefinidos/custom, service accounts y metadata server. Aprende las vías clásicas de escalada: setIamPolicy, actAs, deployfunctions, cloudbuild, impersonation.

Google Cloud Platform (GCP) tiene su propio modelo de IAM (Identity and Access Management), paralelo pero distinto al de AWS y Azure. Las empresas que usan GCP lo usan en serio: Google Workspace para productividad, GCP para infraestructura, los dos integrados vía la misma identidad corporativa. Para un pentester cloud, GCP es el tercer pilar después de AWS (lección de IAM escalada vista) y Azure (lección anterior); conocer los tres es lo que convierte a un operador junior en senior cloud.

GCP IAM introduce conceptos propios que no existen en AWS: jerarquía de organización → folders → projects, primitive roles (Owner/Editor/Viewer) que son enormemente amplios, service account impersonation como primitiva de seguridad, y un metadata server similar al de AWS/Azure pero con endpoints distintos. Las técnicas de escalada también son únicas: setIamPolicy, actAs, deployFunctions, cloudbuild hijacking, impersonation chain.

Esta lección cubre el flujo entero de audit ofensivo en GCP: modelo IAM, enumeración desde dentro, las vías clásicas de escalada documentadas por Rhino Security Labs en el paper específico para GCP (2020), y las defensas modernas. Complementa la lección de IAM AWS y de Azure para completar el bloque multicloud de la Tanda 5.

Prueba solo contra proyectos propios o autorizados. Google Cloud tiene Acceptable Use Policy que prohíbe scanning no autorizado. Las consecuencias legales son las mismas que AWS o Azure.

El modelo IAM de GCP#

GCP IAM: organización → folders → projects → resources. Service accounts + roles primitivos/predefinidos/custom

Jerarquía:

Organization: el tenant corporativo entero.
Folders: agrupaciones opcionales (por departamento, entorno).
Projects: contenedores de recursos. Unidad de facturación.
Resources: VMs, buckets, bases, funciones, etc.

Los permisos se heredan hacia abajo. Un role asignado a nivel organization aplica a todos los proyectos.

Tipos de roles:

Primitive roles: Owner, Editor, Viewer. Extremadamente amplios, se desaconsejan.
Predefined roles: miles de roles específicos (roles/storage.admin, roles/compute.instanceAdmin).
Custom roles: tuyos, específicos.

Identidades:

Usuarios Google (gmail, Workspace): humanos.
Service accounts: cuentas para aplicaciones, con email [email protected] y keys.
Groups: colecciones de identidades.
All authenticated users / All users: pseudo-identidades especiales (muy peligrosas si asignadas por error).

Enumeración desde dentro#

Cuando tienes credenciales (JSON key de SA, token OAuth, acceso desde VM):

# Quién soy
gcloud auth list
gcloud config list

# Qué proyectos veo
gcloud projects list

# Qué puedo hacer en el proyecto
gcloud projects get-iam-policy PROJECT_ID

# Enumerar recursos
gcloud compute instances list
gcloud iam service-accounts list
gcloud functions list
gcloud container clusters list

Herramientas:

GCPBucketBrute: enumerar buckets públicos por fuerza bruta de nombre.
ScoutSuite: audit defensivo completo.
GCP IAM Privilege Escalation (Rhino): script con 27+ paths.
GCPwn: fork de Pacu para GCP.
cloudfox: enumeración ofensiva.

Metadata server#

Cada instancia GCP expone metadata en metadata.google.internal:

# Desde dentro de VM
curl -H "Metadata-Flavor: Google" \
  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

Devuelve access_token con los scopes de la SA de la VM. Si la SA tiene permisos amplios → control del proyecto.

El header Metadata-Flavor: Google es obligatorio: sin él, 403. Es defensa débil contra SSRF triviales pero bypaseable con SSRF que soporte headers.

Las vías de escalada clásicas#

Escaladas GCP: setIamPolicy, actAs, serviceAccountKey create, impersonation, deployFunctions, cloudbuild hijack

Rhino Security Labs documentó 27 paths en su paper de 2020. Los más usados:

iam.serviceAccounts.getAccessToken#

Si tienes este permiso sobre otra SA, pides su token y actúas como ella. Si esa otra SA tiene permisos amplios → escalada directa.

gcloud auth print-access-token --impersonate-service-account=victim-sa@project.iam.gserviceaccount.com

iam.serviceAccountKeys.create#

Permite crear keys para otras SAs:

gcloud iam service-accounts keys create key.json \
  [email protected]

iam.serviceAccounts.actAs + deploy#

Varios servicios permiten adjuntar una SA al desplegar (Cloud Functions, Cloud Run, Compute Engine). Si tienes actAs sobre una SA potente y permiso de deploy, haces:

# Desplegar función que ejecuta como SA potente
gcloud functions deploy pwn \
  --runtime python39 \
  --trigger-http \
  --entry-point handler \
  [email protected] \
  --source=./malicious

El handler de la función puede leer credenciales del metadata y exfiltrarlas.

cloudbuild hijacking#

Cloud Build ejecuta pipelines con un SA de servicio. Modificar cloudbuild.yaml del proyecto → ejecución como ese SA.

resourcemanager.projects.setIamPolicy#

Permite modificar IAM policy del proyecto → añadirte Owner directamente.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=user:[email protected] \
  --role=roles/owner

Compute instance metadata#

Si puedes modificar startup-script de VMs:

gcloud compute instances add-metadata INSTANCE \
  --metadata=startup-script="curl http://metadata.google.internal/..."

La VM ejecuta tu script al reiniciar; el script usa su SA para hacer lo que quieras.

Serverless escalation#

Cloud Run services que aceptan request con parametros controlables pueden ser hijacked para ejecutar código con la SA del Cloud Run. Con run.services.update modificas la imagen del servicio.

Buckets públicos (Cloud Storage)#

Equivalente GCP del fallo clásico S3. Enumeración:

# Herramientas
gcpbucketbrute -k keywords.txt

# Manual
curl -s https://storage.googleapis.com/BUCKET-NAME/
# 200 = público
# 403 = existe pero no listable
# 404 = no existe

Cuentas con allUsers o allAuthenticatedUsers como principal en IAM policy → acceso público.

Acceso cross-project#

Un error común: configurar Owner sobre un proyecto a una SA de otro proyecto. Si comprometes el otro proyecto, controlas el primero. GCP permite estos arreglos cross-project por defecto; los defensores deben auditar con gcloud organizations get-iam-policy qué externos tienen acceso.

Workload Identity (GKE)#

Equivalente a IRSA en EKS: los pods de Kubernetes asumen SA de GCP. Si un pod se compromete y tiene WI configurado con SA potente → SSRF al metadata, token de GCP, escalada. El flujo es idéntico al visto en lecciones de SSRF a metadata y k8s RBAC.

Defensa#

Evitar primitive roles (Owner, Editor, Viewer). Usar predefined específicos o custom roles.
Boundary via IAM Conditions: restrictos basados en tiempo, IP, resource tags.
Organization Policies: bloquean a nivel org (p. ej. iam.disableServiceAccountKeyCreation).
Workload Identity Federation: elimina keys JSON persistentes.
IAM Recommender: Google sugiere eliminar permisos no usados.
Audit logs → Cloud Logging → BigQuery / Chronicle para alertas.
Access Context Manager: Conditional Access para GCP.
VPC Service Controls: perimetros de servicio, previenen exfiltración.

Comparación cross-cloud#

Resumen rápido para operadores que saltan entre AWS, Azure y GCP:

Concepto	AWS	Azure	GCP
Identidades humanas	IAM User	Entra ID User	Google user
Identidades aplicaciones	IAM Role / User	Service Principal	Service Account
Permisos	IAM Policy JSON	Role + scope	IAM Policy
Metadata endpoint	169.254.169.254	169.254.169.254 (header Metadata)	metadata.google.internal (header Metadata-Flavor)
Impersonation	STS AssumeRole	On-Behalf-Of	iam.serviceAccounts.getAccessToken
Boundary	Permissions Boundary	Scope + Conditional	IAM Conditions
Equivalent SCP	SCP Organizations	Management Group	Organization Policies
Audit	CloudTrail	Activity Log + Sign-in Log	Cloud Audit Logs

Las técnicas conceptuales son similares; los detalles cambian.

Workload Identity Federation#

Alternativa moderna a keys JSON: WIF permite que una identidad externa (GitHub Actions, AWS role, Azure SP) asuma una SA de GCP temporalmente. No hay keys persistentes que robar. Es el equivalente de OIDC trust de AWS.

# En GitHub Actions
- uses: google-github-actions/auth@v2
  with:
    workload_identity_provider: 'projects/.../providers/github'
    service_account: '[email protected]'

En 2026 es la mejor práctica para CI/CD con GCP. Si ves keys JSON persistentes en un proyecto, es deuda técnica a migrar.

Errores comunes#

Primitive Owner a SA de CI/CD.
Keys JSON en repos públicos (uno de los leaks más frecuentes).
allUsers en buckets por error de typeo en gcloud.
Compute metadata sin Metadata-Flavor check en applications.
Service accounts con iam.serviceAccountTokenCreator cross-project.
No habilitar VPC SC cuando hay BigQuery con datos sensibles.

Preguntas frecuentes#

¿Cómo encuentro keys JSON filtradas en GitHub?#

Buscar patrones específicos: "type": "service_account" + "private_key". TruffleHog, GitLeaks, detect-secrets automatizan. Google escanea GitHub y rota keys que detecta, pero no todas.

¿Service Account impersonation es ataque o feature?#

Feature. Es la primitiva recomendada: usar impersonation temporal en vez de keys permanentes. Pero mal configurada se convierte en vector de escalada por los permisos actAs y getAccessToken.

¿GKE con Workload Identity reemplaza a service account keys?#

Sí, y debería usarse. Pods asumen SA automáticamente vía mapeo Kubernetes SA ↔ GCP SA. Sin keys JSON en secrets de k8s.

¿Qué pasa con Google Workspace y GCP?#

Están integrados: el admin de Workspace puede ser Organization Admin de GCP automáticamente si así se configuró. Compromiso de Workspace admin → GCP owner.

¿Dónde practico?#

El laboratorio armageddon de whoami-labs incluye un proyecto GCP simulado con escaladas vía Cloud Function deploy, buckets con allUsers por error, SA keys en metadata de VM. Practicas detectar y explotar.

¿Service Account impersonation vs token exchange?#

Impersonation es de corta duración (hasta 1 hora default) y se registra en Cloud Audit Logs. Token exchange (vía STS) es la primitiva subyacente. En uso práctico, gcloud oculta la complejidad y --impersonate-service-account es el flag que cualquier user conoce. Audit logs muestran impersonation events distintos de login normal.

¿Cómo encontrar buckets públicos en GCP?#

GCPBucketBrute con wordlist de nombres de empresa. También grayhatwarfare.com indexa algunos buckets GCP similar a S3. Google proactivamente escanea y reporta buckets con allUsers; algunos equipos tienen alertas automáticas.

¿Diferencia entre VPC Service Controls y VPC Perimeter?#

VPC SC es el perimetro de servicio: un conjunto de recursos (buckets, bases BigQuery, Cloud Run) que solo pueden hablar entre sí y no al exterior, independiente de IAM. Previene exfiltración incluso si credentials son comprometidas. Es el control defensivo más potente en GCP y debe estar en cualquier organización con datos sensibles.

¿GCP tiene Conditional Access como Azure?#

Parcial: Context-Aware Access (basado en BeyondCorp) permite reglas según device, location, user attributes. No tan maduro como Conditional Access de Azure pero funcional para casos comunes.

Resumen#

GCP IAM con jerarquía Organization → Folders → Projects → Resources.
Roles: primitive (evitar), predefined, custom.
Identidades: users, service accounts, groups, allUsers/allAuthenticatedUsers.
Escalada: getAccessToken, serviceAccountKey.create, actAs + deploy, setIamPolicy, cloudbuild hijack, startup-script.
Metadata server: metadata.google.internal con header obligatorio.
Herramientas: gcloud, GCPBucketBrute, ScoutSuite, GCPwn, cloudfox.
Defensa: evitar primitive roles, WIF, VPC SC, Organization Policies, IAM Recommender.

Walkthrough corto#

Para fijar el patrón, un flujo típico tras conseguir key JSON filtrada en repo GitHub:

Paso 1 — autenticar:

gcloud auth activate-service-account --key-file=sa.json
gcloud config set project PROJECT_ID

Paso 2 — enumerar permisos:

# ¿Qué puedo hacer en el proyecto?
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --filter="bindings.members:serviceAccount:MY_SA_EMAIL"

# Qué recursos accesibles
gcloud compute instances list
gcloud iam service-accounts list

Paso 3 — identificar vía de escalada: la SA tiene iam.serviceAccountKeys.create sobre otra SA que es Owner del proyecto.

Paso 4 — crear key de la otra SA:

gcloud iam service-accounts keys create admin-key.json \
  --iam-account=admin-sa@PROJECT_ID.iam.gserviceaccount.com

Paso 5 — login con la nueva key:

gcloud auth activate-service-account --key-file=admin-key.json
gcloud projects get-iam-policy PROJECT_ID  # Ya soy Owner

Game over. Mitigación: iam.disableServiceAccountKeyCreation a nivel organization, forzar WIF, auditoría continua de keys existentes en toda la organización de GCP y rotación semestral obligatoria para las pocas excepciones autorizadas que permanezcan.

Service Account Hijacking modernas#

En 2024-2025 Google documentó ataques donde:

Compromiso de un desarrollador con iam.serviceAccounts.implicitDelegation → cadena de impersonation hasta SA con permisos broad.
Abuso de actAs combinado con Cloud Deploy o Cloud Build: una pipeline con SA potente hijacked por modificación de config.
Secret Manager con permisos de acceso a SA potente: lectura del secret = acceso como SA.
GCS bucket con allUsers por typo: lectura → config files con client secrets OAuth → login en console.

El patrón recurrente: una pequeña debilidad combinada con actAs o getAccessToken cascada hacia Owner del proyecto. Por eso IAM Recommender es clave: recomienda recortar actAs y getAccessToken donde no son necesarios.