Pentesting GCP

Google Cloud Platform organiza todo en torno a proyectos y usa service accounts (SA) como identidades de las aplicaciones. La escalada en GCP gira, casi siempre, en torno a impersonar service accounts: con los permisos adecuados puedes obtener tokens de SAs más privilegiados y encadenar hasta Owner del proyecto o de la organización. Entender SAs, roles y la jerarquía (organización → carpeta → proyecto → recurso) es la clave.

Jerarquía e identidades

Organización -> Carpetas -> Proyectos -> Recursos
# identidades
Usuarios (Google), Grupos, Service Accounts (SA: identidad de apps/VMs)
# roles: primitivos (Owner/Editor/Viewer), predefinidos, custom
# los permisos se heredan hacia abajo en la jerarquía

Credenciales y acceso

# formas de entrar
gcloud auth login                    # usuario
gcloud auth activate-service-account --key-file=sa.json   # SA (JSON filtrado = acceso)
# tokens de SA desde una VM (ver cloud-metadata)
# un service account JSON filtrado (recon-code) es acceso directo

Enumeración

gcloud auth list ; gcloud config list
gcloud projects list ; gcloud projects get-iam-policy <proj>
gcloud iam service-accounts list
gcloud <servicio> ... list           # recursos por servicio
# herramientas
gcp_scanner, GCPBucketBrute, Hayat, ScoutSuite (soporta GCP)

El corazón: impersonación de service accounts

# si tienes iam.serviceAccounts.getAccessToken sobre un SA -> obtienes su token
gcloud auth print-access-token --impersonate-service-account=<SA>@<proj>.iam.gserviceaccount.com
# iam.serviceAccounts.actAs + crear recurso (función/VM/job) que corre como ese SA
# iam.serviceAccountKeys.create -> crear una clave para un SA (persistencia/acceso)
gcloud iam service-accounts keys create k.json --iam-account=<SA>

Si el SA objetivo es más privilegiado (Editor/Owner), lo impersonas y escalas.

Permisos de escalada típicos

resourcemanager.projects.setIamPolicy   -> concederte Owner del proyecto
iam.serviceAccounts.getAccessToken/actAs -> impersonar SA privilegiado
iam.serviceAccountKeys.create            -> clave de SA (acceso persistente)
# vía servicios: deploymentmanager, cloudfunctions/run/compute con SA privilegiado
cloudfunctions.functions.create + actAs  -> función como SA admin (cloud-serverless)

Servicios comunes

# Cloud Storage (ver cloud-s3)
gsutil ls ; gsutil ls gs://<bucket>   # buckets públicos/legibles
# Compute Engine
gcloud compute instances list ; metadata del proyecto (claves SSH, startup scripts)
gcloud compute project-info describe   # a veces credenciales en metadata
# Secret Manager
gcloud secrets list ; gcloud secrets versions access latest --secret=X
# Cloud Functions / Cloud Run (cloud-serverless)

Para la defensa

Mínimo privilegio: evitar roles primitivos (Owner/Editor) amplios; roles predefinidos acotados.
Controlar la impersonación: restringir iam.serviceAccounts.getAccessToken/actAs; deshabilitar creación de claves de SA (iam.disableServiceAccountKeyCreation).
SA sin claves estáticas: usar Workload Identity; no exponer service account JSON.
Organization Policies para limitar (dominio restringido, no claves de SA, no IPs públicas).
Cloud Audit Logs (Admin Activity + Data Access) + Security Command Center; alertas sobre setIamPolicy/keys.create.

Checklist de prueba

Acceso (usuario / SA JSON / token de VM) y enumeración (gcloud)
IAM policy de proyectos y SAs (roles heredados)
Impersonar SAs (getAccessToken/actAs) hacia más privilegio
serviceAccountKeys.create (acceso/persistencia)
setIamPolicy → Owner del proyecto
Buckets GCS públicos (Buckets y almacenamiento público), metadata de Compute (claves)
Secret Manager y funciones con SA privilegiado
Mapear hasta Owner del proyecto/organización