Suplantación, credenciales de corta duración y Workload Identity

Un principal autenticado (un usuario u otra cuenta de servicio) obtiene un token de la cuenta de servicio y lo usa para actuar como ella, con todos sus permisos. Siempre hay dos identidades: quien suplanta y la cuenta suplantada. Se parece a AssumeRole de AWS.

• Permiso necesario: iam.serviceAccounts.getAccessToken, incluido en Service Account Token Creator (roles/iam.serviceAccountTokenCreator).
• Usos: acceso elevado temporal sin cambiar políticas, probar si un conjunto de permisos basta, desarrollar en local aplicaciones que solo funcionan como cuenta de servicio y autenticar aplicaciones externas.
• En la consola siempre te autenticas con tus credenciales de usuario: no se puede suplantar una cuenta de servicio.
• Usar una cuenta asociada a un recurso o una clave no es suplantación: solo interviene la identidad de la cuenta.

gcloud iam service-accounts add-iam-policy-binding \
  deployer@my-project.iam.gserviceaccount.com \
  --member=user:ana@example.com --role=roles/iam.serviceAccountTokenCreator

Suplantar con gcloud y ADC

# Un solo comando
gcloud storage buckets list \
  --impersonate-service-account=deployer@my-project.iam.gserviceaccount.com

# Todos los comandos de gcloud
gcloud config set auth/impersonate_service_account \
  deployer@my-project.iam.gserviceaccount.com

# Bibliotecas cliente en tu equipo (archivo de ADC)
gcloud auth application-default login \
  --impersonate-service-account deployer@my-project.iam.gserviceaccount.com

En los tres casos gcloud pide credenciales de corta duración para la cuenta de servicio y ejecuta las llamadas con ellas.

Credenciales de corta duración

Según Google, son la forma más segura de autenticarse como una cuenta de servicio: un token de acceso OAuth 2.0 que caduca a la 1 hora por defecto y no se renueva solo. Suponen menos riesgo que las claves.

• Muchas veces se obtienen automáticamente: con --impersonate-service-account, con una cuenta asociada a una VM (las bibliotecas cliente usan ADC) o con Workload Identity Federation.
• La Service Account Credentials API las crea manualmente: tokens de acceso OAuth 2.0, tokens de ID de OpenID Connect, JWT autofirmados y blobs autofirmados.
• La vida máxima de un token de acceso se puede ampliar a 12 horas añadiendo la cuenta a la restricción iam.allowServiceAccountCredentialLifetimeExtension. Los tokens de ID duran 1 hora.
• No se permite la autosuplantación: usar un token de corta duración de una cuenta para generar otro de la misma cuenta (salvo con JWT autofirmados), para que un token robado no se pueda renovar indefinidamente.
• Credential Access Boundaries reducen los permisos de un token de corta duración, pero solo para Cloud Storage.

Suplantación y registros de auditoría

Application Default Credentials

ADC es la estrategia que usan las bibliotecas para encontrar credenciales automáticamente según el entorno, de modo que el mismo código funciona en desarrollo y en producción. Orden de búsqueda:

1. La variable de entorno GOOGLE_APPLICATION_CREDENTIALS (archivo de configuración de Workload o Workforce Identity Federation, o una clave, que no se recomienda).
2. El archivo creado con gcloud auth application-default login.
3. La cuenta de servicio asociada, que devuelve el servidor de metadatos.

El orden no indica cuál es mejor; solo dónde busca primero.

Da a cargas de trabajo on-premises o de otras nubes acceso a Google Cloud con identidades federadas, sin claves de cuentas de servicio. Funciona con AWS, Azure, Active Directory on-premises, GitHub, GitLab, certificados X.509 y cualquier IdP compatible con OIDC o SAML 2.0.

• El IdP entrega una credencial al Security Token Service, que la verifica y devuelve un token federado (intercambio de tokens OAuth 2.0).
• Google recomienda el acceso directo: conceder roles a principal://… o principalSet://… sobre los recursos. La alternativa es suplantar una cuenta de servicio, que necesita roles/iam.workloadIdentityUser.
• Conceder acceso a todas las identidades del pool es arriesgado: limita con atributos y condiciones.
• La aplicación externa usa un archivo de configuración de credenciales, no una clave.

Es la forma recomendada de que los pods accedan a APIs de Google Cloud: cada aplicación tiene su identidad y se le conceden roles con IAM, sin archivos de claves. Google gestiona el pool y el proveedor.

• Al activarlo, GKE crea el pool fijo PROJECT_ID.svc.id.goog, registra el clúster como proveedor y despliega el servidor de metadatos de GKE en cada nodo.
• Activarlo no concede ningún permiso: hay que dar roles al ServiceAccount de Kubernetes.
• En Autopilot todos los nodos lo usan siempre. En Standard se activa en el clúster y en cada grupo de nodos.

gcloud container clusters update my-cluster --location=europe-west1 \
  --workload-pool=my-project.svc.id.goog
gcloud container node-pools update default-pool --cluster=my-cluster \
  --location=europe-west1 --workload-metadata=GKE_METADATA

# Dar acceso al ServiceAccount de Kubernetes "reader" del namespace "app"
gcloud storage buckets add-iam-policy-binding gs://app-data --role=roles/storage.objectViewer \
  --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/my-project.svc.id.goog/subject/ns/app/sa/reader

Workforce Identity Federation

Federa usuarios (empleados, socios, contratistas) desde un IdP externo compatible con OIDC o SAML 2.0 (Entra ID, AD FS, Okta…) para que entren en Google Cloud con SSO. No guarda cuentas en Google Cloud, así que no hace falta sincronizar con Google Cloud Directory Sync. Los workforce identity pools se configuran a nivel de organización y el acceso se concede con allow policies.

Escenarios de examen

Trampas frecuentes del examen