Cómo utilizo Microsoft Entra ID como origen de identidad para Google Cloud, con Cloud Identity, aprovisionamiento selectivo, SAML e IAM nativo.
En los dos primeros artículos de esta serie expliqué el objetivo general de la arquitectura multicloud y después entré en detalle en la integración con AWS.
La idea de fondo sigue siendo la misma: mantener una identidad común sin intentar sustituir el modelo de autorización de cada proveedor.
En Google Cloud, sin embargo, el camino es distinto al de AWS. En el modelo que utilizo en algunos laboratorios aparece un componente adicional: Cloud Identity.
El flujo simplificado es este:
Microsoft Entra ID
│
├── Aprovisionamiento de usuarios y grupos
▼
Google Cloud Identity
│
├── Identidades y grupos de Google
│
└── SAML SSO → autenticación en Entra ID
│
▼
Google Cloud IAM
│
▼
Proyecto
Figura 1. Flujo simplificado de identidad, autenticación y autorización entre Microsoft Entra ID y Google Cloud.
La arquitectura está basada en un entorno real de formación, pero nombres de dominios, grupos, proyectos e identificadores se han anonimizado o simplificado deliberadamente.
¿Por qué aparece Cloud Identity?
Si Microsoft Entra ID ya conoce a los usuarios, ¿por qué necesitamos además Cloud Identity?
Porque en este modelo Google Cloud necesita una identidad de Google correspondiente que pueda ser utilizada por sus servicios y referenciada en las políticas IAM.
Google documenta este patrón de forma explícita: podemos aprovisionar usuarios y grupos desde Microsoft Entra ID hacia Cloud Identity o Google Workspace y delegar después la autenticación en Entra ID mediante SAML.
Google Cloud — Microsoft Entra ID user provisioning and single sign-on
En el entorno de laboratorio utilizo Cloud Identity Free, suficiente para representar usuarios y grupos sin convertir el laboratorio en un entorno de Google Workspace.
Entra ID sigue siendo el origen; Cloud Identity mantiene la representación que Google Cloud necesita.
Aprovisionamiento y autenticación son dos cosas distintas
Aprovisionar significa crear y mantener los objetos de identidad que Google necesita. Autenticar significa demostrar quién es el usuario cuando intenta iniciar sesión.
Aprovisionamiento
Entra ID ───────────────▶ Cloud Identity
Autenticación
Usuario ─▶ Google ─▶ SAML ─▶ Entra IDEl aprovisionamiento es unidireccional: los cambios realizados en Entra ID se reflejan en Cloud Identity, pero Cloud Identity no se convierte en el sistema maestro. Tampoco se sincronizan contraseñas.
Cuando llega el momento de autenticarse, Google redirige al usuario a Microsoft Entra ID mediante SAML. De esta forma, las credenciales permanecen bajo el control del proveedor de identidad corporativo.
Dos conectores, no uno
Un detalle de implementación que merece la pena destacar es que utilizo dos instancias separadas del conector Google Cloud / G Suite Connector by Microsoft.
Una se dedica al aprovisionamiento y la otra al Single Sign-On.
Microsoft Entra ID
Enterprise App 1
Google Cloud / G Suite Connector
└── Provisioning
Enterprise App 2
Google Cloud / G Suite Connector
└── SAML SSOGoogle utiliza precisamente este enfoque en su arquitectura de referencia. Separar ambas funciones hace que la configuración sea más comprensible y reduce el riesgo de mezclar cambios de aprovisionamiento con cambios de autenticación.
No utilizar una cuenta Super Admin para aprovisionar
Para que Entra ID pueda crear y mantener usuarios y grupos en Cloud Identity necesita una cuenta administrativa.
La solución fácil sería utilizar una cuenta con privilegios de Super Admin. No es el enfoque que prefiero.
En el laboratorio utilizo una cuenta dedicada exclusivamente a automatización, situada además en una unidad organizativa separada.
Cloud Identity
/Automation
provisioning-service
/Training
student-01
student-02
student-03
...La cuenta de automatización recibe solo los permisos administrativos necesarios para gestionar los objetos que debe aprovisionar.
Esto deja una separación clara entre administración humana y automatización de identidades.
Una OU específica para las identidades del laboratorio
Los usuarios aprovisionados no se mezclan con el resto de identidades del dominio. Los sitúo dentro de una unidad organizativa dedicada, por ejemplo:
/TrainingEsto permite aplicar a esa OU una política de SSO específica, controles de sesión concretos o cualquier ajuste que solo deba afectar a los participantes del laboratorio.
No todo el mundo tiene que utilizar SSO
Configurar SAML en Google no obliga necesariamente a convertir toda la organización en federada.
En el laboratorio, el perfil de SSO se asigna únicamente a las identidades de formación.
Cloud Identity
/Automation → autenticación local protegida
/Training → SAML SSO con Entra IDAsí mantenemos fuera de la federación determinadas cuentas administrativas o de emergencia que no deberían depender del mismo camino de autenticación.
El problema práctico de los grupos
Durante la implementación apareció un detalle especialmente interesante.
En Google, los grupos necesitan una dirección de correo válida. Pero los grupos de seguridad de Entra ID no siempre tienen definido el atributo mail.
Si el conector intenta utilizar ese campo como identificador de grupo, el aprovisionamiento puede fallar porque falta la propiedad necesaria para construir el objeto en Google.
La solución que utilizo es derivar de forma determinista la dirección del grupo a partir de su nombre.
Entra ID displayName
Student-01
↓ transformación
g-student-01@training.example.comLa ventaja es que el nombre del grupo en Entra ID sigue siendo legible, mientras que Google recibe un identificador válido y predecible.
Aprovisionar un grupo tampoco concede permisos
Al igual que en AWS, sincronizar un usuario o un grupo no equivale a concederle acceso a recursos.
Cloud Identity contiene el objeto. Google Cloud IAM decide qué puede hacer.
Grupo aprovisionado
↓
Google Cloud IAM
↓
Rol
↓
ProyectoEn un laboratorio podemos tener una correspondencia sencilla:
g-student-01@training.example.com
↓
Owner
↓
Project Student-01Ese nivel de privilegio solo tiene sentido porque hablamos de un sandbox de formación aislado. En producción utilizaría roles mucho más granulares y aplicaría privilegio mínimo.
La identidad puede estar centralizada; la autorización sigue siendo nativa de Google Cloud.
Cloud Shell vuelve a simplificar el laboratorio
Una vez que el participante entra en Google Cloud con su identidad federada, puede abrir Google Cloud Shell desde el navegador.
Entra ID
↓
SAML SSO
↓
Google Cloud Console
↓
Cloud Shell
↓
TerraformEl alumno no necesita descargar una clave privada de una Service Account para trabajar con Terraform ni guardar secretos permanentes en su equipo.
Para un entorno formativo, donde además queremos evitar instalaciones locales, esto reduce mucho la fricción de entrada.
¿Y Application Default Credentials?
Cuando una herramienta necesita acceder a APIs de Google Cloud con identidad de usuario, aparece otro concepto habitual: Application Default Credentials, o ADC.
Las credenciales basadas en usuario también tienen ciclo de vida y están afectadas por las políticas de sesión. Google documenta que, cuando expira la sesión correspondiente, puede ser necesario volver a autenticarse para renovar esas credenciales.
Google Cloud — Reauthentication
Identidad, autorización y sesión tienen ciclos de vida relacionados, pero no son la misma cosa.
El tiempo también forma parte del control de acceso
Google Cloud permite aplicar controles de sesión y exigir reautenticación periódica.
Actualmente pueden configurarse controles de reautenticación para servicios de Google Cloud mediante Access Context Manager y políticas de sesión.
Google Cloud — Session controls for reauthentication
Quién es → Entra ID
Qué identidad existe → Cloud Identity
Qué puede hacer → Google Cloud IAM
Durante cuánto tiempo → Session controls¿Por qué no Workforce Identity Federation?
Hoy Google Cloud ofrece también Workforce Identity Federation, que permite federar usuarios de un proveedor externo sin tener que sincronizarlos previamente como cuentas de Cloud Identity.
Es una opción muy interesante y, para determinados diseños, puede reducir la necesidad de mantener identidades duplicadas.
Google Cloud — Workforce Identity Federation with Microsoft Entra ID
Pero este artículo describe deliberadamente la arquitectura utilizada en estos laboratorios, donde Cloud Identity forma parte del diseño y los grupos aprovisionados se utilizan directamente en políticas IAM de proyectos.
La cadena completa
Microsoft Entra ID
│
┌─────────────┴─────────────┐
│ │
Provisioning SAML SSO
│ │
▼ │
Cloud Identity ◀──────────────────┘
│
Users + Groups
│
▼
Google Cloud IAM
│
Role binding
│
▼
Project
│
▼
Google Cloud Shell
│
▼
TerraformEntra ID mantiene la identidad de origen.
El aprovisionamiento replica los objetos necesarios.
Cloud Identity proporciona la representación de usuarios y grupos en Google.
SAML devuelve la autenticación a Entra ID.
Google Cloud IAM determina los permisos sobre los recursos.
Cloud Shell proporciona un entorno de trabajo ya autenticado.
Terraform utiliza ese contexto sin que tengamos que distribuir claves privadas permanentes.
Qué me llevo de esta arquitectura
La parte más interesante de este diseño no es que el usuario tenga que recordar una sola contraseña.
Es que podemos separar correctamente identidad, representación, autenticación y autorización.
Entra ID sigue siendo el sistema en el que nace y muere la identidad. Cloud Identity representa esa identidad dentro del ecosistema Google. SAML permite que las credenciales se validen en el IdP corporativo. Google Cloud IAM conserva el control sobre los permisos reales.
Y Cloud Shell nos permite trabajar con herramientas como Terraform sin introducir una colección de secretos estáticos en los equipos de los alumnos.
Próximo artículo
Hay un tema que ha aparecido ya dos veces en esta serie y merece tratarse por separado:
Deshabilité el usuario en Entra ID… ¿por qué seguía teniendo acceso al cloud?
En el siguiente artículo veremos la diferencia entre identidad y sesión, por qué unas credenciales temporales ya emitidas pueden seguir siendo válidas y qué implica esto para el offboarding y la respuesta ante incidentes en entornos federados.
Referencias
Google Cloud — Microsoft Entra ID user provisioning and single sign-on
Documentación oficial de Google Cloud
Google Cloud — Federate Google Cloud with Microsoft Entra ID
Documentación oficial de Google Cloud
Google Cloud — Cloud Identity overview
Documentación oficial de Google Cloud
Google Cloud — Reauthentication
Documentación oficial de Google Cloud
Google Cloud — Workforce Identity Federation with Microsoft Entra ID
Documentación oficial de Google Cloud
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.
Francisco Sepúlveda
Instructor de Cloud Computing y Ciberseguridad, Diseñador de Experiencias Formativas
Instructor y consultor en Cloud Computing, Ciberseguridad e IA, con más de 25 años de experiencia en entornos empresariales reales. Diseño e imparto programas de formación técnica combinando experiencia profunda en la materia con diseño de experiencias formativas, para que los conceptos complejos de seguridad realmente se queden. Comparto análisis técnico aplicado en Cloud Security in Practice.
Conoce más →