Tema 2 de 5
Cloud Identity y Workforce Identity Federation
IAM decide qué puede hacer cada identidad, pero esas identidades tienen que venir de algún sitio. Google Cloud ofrece dos caminos: gestionar las cuentas en Cloud Identity (a mano o sincronizadas desde otro directorio) o federar las de un IdP externo sin crear cuentas de Google. El temario pide saber gestionar usuarios y grupos, manualmente y de forma automatizada, y configurar Workforce Identity Federation.
Contenido
- ¿Qué es Cloud Identity?
- Cloud Identity Free y Premium
- Gestionar usuarios a mano
- Tipos de grupos
- Automatizar: GCDS y aprovisionamiento
- Fuente autoritativa e IdP
- Workforce Identity Federation
- Grupos y proveedores de identidad de personal
- Asignación y condiciones de atributos
- Identificadores de principal en IAM
- Escenarios de examen
- Trampas frecuentes del examen
¿Qué es Cloud Identity?
Una solución de identidad como servicio (IDaaS) que gestiona usuarios y grupos de forma centralizada y puede federar identidades con otros IdP, como Active Directory o Microsoft Entra ID.
El problema que resuelve: si los desarrolladores usan cuentas personales, como Gmail, esas cuentas quedan fuera del control de la empresa. Con Cloud Identity se crea una cuenta por cada usuario y grupo del dominio, y después se usa IAM para darles acceso a los recursos. Una cuenta de Cloud Identity o Google Workspace es un directorio privado de usuarios y grupos; al crearla se genera automáticamente una organización de Google Cloud con el mismo nombre.
Salvo las cuentas de servicio, la organización de Google Cloud no gestiona usuarios ni grupos. Esa es la diferencia con un tenant de Entra ID, que sí actúa como contenedor de usuarios.
Cloud Identity Free y Premium
Para usar Google Cloud no hace falta la edición Premium. Los clientes de Google Cloud pueden pedir licencias adicionales de Cloud Identity sin coste.
| Free | Premium | |
|---|---|---|
| Para quién | Identidad y gestión básica de dispositivos para usuarios que no necesitan Gmail ni Calendar | Seguridad empresarial, gestión de aplicaciones y de dispositivos avanzada |
| Unidades organizativas y grupos | Ilimitados | Ilimitados |
| Google Cloud Directory Sync | Sí | Sí |
| Verificación en 2 pasos | Sí | Sí |
| Secure LDAP, acceso contextual (Context-Aware Access) | No | Sí |
| Soporte y SLA | Comunidad | Chat y correo 24x7, SLA del 99,9 % |
Gestionar usuarios a mano
Los usuarios y grupos se gestionan en la consola de administración de Google (Menú → Directorio → Usuarios), no en la consola de Google Cloud. Hace falta el privilegio de administración de usuarios correspondiente.
Uno a uno
Add new user: nombre, correo principal, correo secundario recomendado para recibir los datos de la cuenta, unidad organizativa y contraseña. Es la forma más sencilla para pocos usuarios.
En bloque con CSV
Hasta 150 000 usuarios por archivo (200 si se asignan licencias con la columna New Licenses). Los usuarios creados así no reciben correo de bienvenida: hay que enviarles las credenciales aparte.
- No compartas una cuenta entre varias personas: cada cuenta debe usarla un solo usuario.
- Para transferir los datos de un usuario borrado hay que restaurarlo en un plazo de 20 días. Si quieres conservar sus datos, suspéndelo o archívalo en lugar de borrarlo.
Tipos de grupos
Google recomienda conceder roles IAM a grupos, no a usuarios sueltos. La API de grupos de Cloud Identity (solo para Google Groups for Business) admite estos tipos:
| Tipo | Qué es |
|---|---|
| Google Group | Tipo por defecto. Tiene dirección de correo y sirve como lista de distribución, para compartir documentos o para gestionar acceso en IAM. |
| Grupo dinámico | Pertenencia automática según una consulta de atributos, como el puesto o el edificio. Solo en Workspace Enterprise y Cloud Identity Premium; hasta 500 por cliente. |
| Grupo de seguridad | Un Google Group convertido para controlar el acceso a recursos. No se puede volver a convertir en Google Group normal. |
| Grupo bloqueado | Los atributos y la pertenencia solo los cambian ciertos administradores. Evita que se desincronice de un IdP externo. |
| Grupo POSIX (obsoleto) | Se usaba con OS Login en las VM. Desde el 26 de septiembre de 2024 ya no se pueden crear. |
Automatizar: GCDS y aprovisionamiento
Mantener a mano una identidad de Google por empleado es trabajo innecesario si ya existen en otro directorio. La federación con Cloud Identity tiene dos piezas:
1. Aprovisionamiento
Los usuarios y grupos se sincronizan periódicamente desde el directorio externo. Así existen en Google Cloud antes de su primer inicio de sesión y las bajas también se propagan. Es unidireccional y no incluye contraseñas.
2. Inicio de sesión único (SSO)
Google delega la autenticación en el IdP externo mediante SAML. No se sincronizan contraseñas y se aplican las políticas y la MFA configuradas en el IdP.
Google Cloud Directory Sync (GCDS)
- Herramienta gratuita de Google que sincroniza usuarios, alias, grupos y contactos compartidos desde Active Directory o un servidor LDAP.
- Sincronización de un solo sentido: nunca modifica los datos del servidor LDAP, que sigue siendo la fuente de verdad.
- Se ejecuta en tu entorno (on-premises o en Google Cloud). No migra contenido como correos o archivos.
- Permite reglas de mapeo y exclusiones, tiene una fase de simulación y envía un informe por correo tras cada sincronización.
- Como las APIs que usa son públicas, no hace falta conectividad híbrida.
Con Entra ID, el aprovisionamiento lo hace la app de galería «Google Cloud/G Suite Connector by Microsoft», que es un producto de Microsoft. Con un sistema de RR. HH. (HRIS) como fuente, este usa las APIs de Cloud Identity o Workspace para dar de alta y de baja a los usuarios.
Fuente autoritativa e IdP
Las arquitecturas de referencia de Google separan dos decisiones: qué sistema es la fuente autoritativa (el único donde se crean y borran identidades) y cuál es el IdP (el único que autentica).
| Arquitectura | Cómo funciona | Cuándo |
|---|---|---|
| Google como IdP y fuente | Cloud Identity Premium o Workspace gestionan y autentican | Ya usas Workspace y no hay IdP on-premises |
| Google como IdP, HRIS como fuente | El HRIS aprovisiona por API | RR. HH. controla altas y bajas |
| Active Directory como IdP y fuente | GCDS aprovisiona y AD FS hace el SSO. Basta con Cloud Identity Free | Infraestructura AD existente |
| Entra ID como IdP, AD como fuente | Entra ID aprovisiona y autentica con SAML | Ya usas Microsoft 365 o Azure |
Buena práctica: sincroniza también los grupos, no solo los usuarios, para controlar el acceso en IAM con la pertenencia a grupos del directorio.
Workforce Identity Federation
Permite autenticar al personal (empleados, socios, contratistas) con un IdP externo y que accedan a Google Cloud con SSO. El acceso se autoriza con políticas allow de IAM.
Federación, no sincronización
No guarda cuentas de usuario en Google Cloud. No hace falta GCDS ni ninguna herramienta que copie identidades.
Protocolos
Cualquier IdP con OpenID Connect (OIDC) o SAML 2.0: Microsoft Entra ID, AD FS, Okta y otros.
Workforce frente a Workload
Workforce Identity Federation federa personas. Workload Identity Federation federa cargas de trabajo (aplicaciones fuera de Google Cloud) y se ve en el dominio D4.
Los usuarios federados entran en la consola (federada) de Google Cloud. Funciona como un intercambio de tokens OAuth 2.0 (RFC 8693): las credenciales del IdP se presentan al Security Token Service, que devuelve un token de acceso de Google Cloud de corta duración.
Grupos y proveedores de identidad de personal
Workforce identity pool
- Agrupa identidades, por ejemplo
employeesopartners. - Se configura a nivel de organización y su ID debe ser único en todo Google Cloud.
- Permite conceder acceso IAM a todo el grupo o a una parte.
- Registra en Cloud Audit Logs los accesos con el ID del grupo.
- Se pueden crear varios, por ejemplo uno para empleados y otro para cada socio.
Workforce identity pool provider
- Describe la relación entre la organización y un IdP.
- Tipos OIDC y SAML. En OIDC se admite el flujo de código de autorización (el más seguro) y el implícito.
- Contiene la asignación y las condiciones de atributos.
gcloud iam workforce-pools create WORKFORCE_POOL_ID \ --organization=ORGANIZATION_ID --location=global \ --session-duration=3600s gcloud iam workforce-pools providers create-oidc WORKFORCE_PROVIDER_ID \ --workforce-pool=WORKFORCE_POOL_ID --location=global \ --issuer-uri="ISSUER_URI" --client-id="OIDC_CLIENT_ID" ...
La duración de sesión controla cuánto valen los tokens de acceso y las sesiones de la consola federada y de gcloud. Por defecto es 1 hora, con un mínimo de 15 minutos y un máximo de 12 horas.
Asignación y condiciones de atributos
El IdP envía atributos (también llamados claims) que se mapean con CEL (Common Expression Language):
| Atributo | Uso |
|---|---|
google.subject (obligatorio) | ID único del usuario. Aparece como principal en los logs de auditoría. Usa un valor que no cambie o el usuario perderá el acceso. Máx. 127 bytes. |
google.groups | Grupos del usuario, utilizables en IAM. Un usuario con más de 400 grupos no podrá iniciar sesión. |
google.display_name, google.profile_photo | Nombre y foto en la consola. No sirven en políticas IAM. |
google.posix_username | Para SSH desde el navegador y OS Login con federación (vista previa). |
attribute.KEY | Atributos personalizados, p. ej. centro de coste. Hasta 50 reglas. Google recomienda valores estables como attribute.role. |
Una condición de atributo es una expresión CEL opcional que limita qué identidades pueden autenticarse, por ejemplo solo el equipo de contabilidad. Es obligatoria con IdP multiinquilino como GitHub o Terraform Cloud, que usan un único emisor para todos sus inquilinos: sin condición, cualquier inquilino podría entrar.
Identificadores de principal en IAM
| Identidad | Formato |
|---|---|
| Un usuario | principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT |
| Todos los de un grupo | principalSet://…/workforcePools/POOL_ID/group/GROUP_ID |
| Todos con un valor de atributo | principalSet://…/workforcePools/POOL_ID/attribute.NAME/VALUE |
| Todo el grupo de identidades | principalSet://…/workforcePools/POOL_ID/* |
- Los principales de un grupo de identidades de personal no pueden acceder directamente a recursos fuera de su organización, salvo que suplanten una cuenta de servicio.
- Al crear la configuración se indica un proyecto de usuario del grupo, que actúa como proyecto de cuota para las APIs basadas en cliente. Requiere
serviceusage.services.use(rol Service Usage Consumer). - Los usuarios federados no tienen correo de Cloud Identity: configura Essential Contacts (categorías Legal y Suspension) para recibir avisos.
Escenarios de examen
| Situación | Respuesta | Por qué |
|---|---|---|
| Los desarrolladores usan cuentas personales de Gmail y la empresa quiere controlarlas | Adoptar Cloud Identity | Gestiona todas las cuentas del dominio de forma centralizada. |
| Dar acceso a Google Cloud a 40 000 empleados que ya existen en Active Directory | GCDS + SSO con AD FS | Sincronización unidireccional y autenticación delegada. |
| Dar acceso a la consola con SSO de Okta sin crear cuentas de Google | Workforce Identity Federation | Federa sin sincronizar ni guardar cuentas. |
| Alta de 5000 usuarios nuevos de una vez | Subir un CSV en la consola de administración | Hasta 150 000 usuarios por archivo. |
| Grupo cuyos miembros se actualicen solos según el puesto | Grupo dinámico | Pertenencia según una consulta de atributos. |
| Que una empresa colaboradora administre a sus propios usuarios | Un grupo de identidades de personal propio para el socio | Administración distribuida por grupo. |
| Federar con un IdP multiinquilino como GitHub | Condición de atributo obligatoria | Un único emisor sirve a todos los inquilinos. |
Trampas frecuentes del examen
❓ ¿GCDS escribe cambios de vuelta en Active Directory?
No. La sincronización es unidireccional: AD sigue siendo la fuente de verdad y nunca se modifica.
❓ ¿GCDS sincroniza las contraseñas?
La práctica recomendada es no hacerlo: la autenticación se delega en el IdP con SAML (por ejemplo, AD FS), así que no hace falta copiar contraseñas.
❓ ¿Workforce Identity Federation necesita GCDS?
No. Federa sin sincronizar y no guarda cuentas de usuario en Google Cloud.
❓ ¿Hace falta Cloud Identity Premium para usar Google Cloud?
No. La edición Free basta, incluido GCDS. Premium añade seguridad, gestión de dispositivos avanzada, Secure LDAP y SLA.
❓ ¿Dónde se crea un usuario de Cloud Identity?
En la consola de administración de Google, no en la página IAM de la consola de Google Cloud.
❓ ¿Se puede volver a convertir un grupo de seguridad en un Google Group normal?
No. La conversión es irreversible.
❓ ¿Qué atributo de Workforce Identity Federation es obligatorio?
google.subject. Los demás, como google.groups o google.display_name, son opcionales.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa gestiona sus identidades en Okta y no quiere crear ni sincronizar cuentas de Google para sus 3000 empleados. Quiere que inicien sesión en la consola de Google Cloud con SSO y controlar el acceso por grupos de Okta. ¿Qué configura?
¿Listo para poner a prueba "Cloud Identity y Workforce Identity Federation"?
Preguntas originales, cada una con su explicación.
Empezar un simulacro