El primer paso al incorporar una empresa en Google Cloud es configurar Cloud Identity o Google Workspace para administrar Google Cloud de forma centralizada.
Este proceso está bien explicado en la lista de verificación de incorporación empresarial y hay mejores prácticas y arquitecturas de referencia en el sitio de Cloud Identity Architecture .
Configurar Cloud Identity para empresas multinacionales puede ser más complicado teniendo en cuenta que estas empresas pueden tener servicios centralizados como el servicio de correo electrónico, pero por otro lado, sus empresas operativas (OpCos) pueden tener suficiente autonomía para gestionar sus propias organizaciones de Google Cloud.
Visión general
Supongamos que existe una empresa multinacional llamada "Example LLC" con cuatro filiales (u OpCos) en Brasil, Reino Unido, Alemania y España.
"Ejemplo" posee un conjunto de servicios compartidos que incluyen la identidad global y los servicios de correo electrónico para todos sus empleados (
Por otro lado, los diferentes OpCos tienen total autonomía en cuanto a Tecnología y Operaciones, y por tanto cada OpCo decide gestionar su propia Organización Google Cloud.
La cuestión
El recurso de la organización es el nodo raíz en la jerarquía de recursos de Google Cloud y es el supernodo jerárquico de proyectos. El recurso Organización está disponible una vez que se configura Google Workspace o Cloud Identity y para eso es obligatorio verificar el dominio de la empresa. Este dominio se utiliza durante el proceso de autenticación de Google Cloud para identificar a qué organización pertenece el usuario, por lo tanto, un dominio solo puede pertenecer a una identidad de nube única de la organización de Google Cloud .
Resumiendo:
- Todos los usuarios de los diferentes OpCos comparten el mismo dominio en su dirección de correo electrónico (
@ example.com) - Cada OpCo requiere tener su propia organización de Google Cloud (y su dominio asociado)
- El dominio example.com solo se puede asociar con una instancia única de Cloud Identity.
¿Cómo pueden los usuarios de @ example.com de los diferentes OpCos obtener acceso a su organización de Google Cloud correspondiente?
La solución
Una solución para este caso de uso podría consistir en configurar diferentes instancias de Cloud Identity:
- 1 x instancia global de Cloud Identity (CI Global) asociada al dominio example.com y que contiene todos los usuarios pertenecientes a los diferentes OpCos. Este CI sería responsable de la autenticación de usuarios y se integraría con Azure AD para la federación de usuarios y el inicio de sesión único.
- nx instancias de Cloud Identity (CI OpCo) asociadas a cada uno de los dominios OpCos / Google Cloud Organizations. Estas instancias de CI no contendrían usuarios, pero podrían contener grupos locales (es decir, gcp-net-admins@example.de). La autorización para administrar los recursos alojados en la Organización OpCo la realiza Cloud IAM, asignando permisos a las identidades de usuario disponibles en CI Global.
En caso de que un usuario tenga permisos en 2 organizaciones diferentes y acceda a Google Cloud Console, puede seleccionar la correcta en Google Cloud Console.
Restringir los dominios de identidad permitidos
Para restringir el conjunto de identidades que se permite utilizar en las políticas de IAM de cada una de las Organizaciones de OpCo, es necesario establecer la política de organización iam.allowedPolicyMemberDomains [1].
iam.allowedPolicyMemberDomain define el conjunto de miembros que se pueden agregar a las políticas de Cloud IAM. La lista de permitidos / denegados debe especificar uno o más ID de cliente de Cloud Identity o Google Workspaces.
La política de la organización se puede configurar mediante Google Cloud Console o el siguiente comando de gCloud:
gcloud alpha resource-manager org-policies permiten \
--organización 'ORGANIZATION_ID_example_opco' \
iam.allowedPolicyMemberDomains 'CUSTOMER_ID_example.com' \
"DOMAIN_ID_example_opco"
El ID de dominio se puede obtener mediante el siguiente comando de gCloud:
lista de organizaciones de gcloud
Este comando devolverá DISPLAY_NAME, ID (ID de organización) y DIRECTORY_CUSTOMER_ID. El ID de cliente de Google Workspace es DIRECTORY_CUSTOMER_ID.
Consideraciones y limitaciones
- El uso compartido restringido de dominios (allowedPolicyMemberDomain) puede interferir con algunos servicios de Google Cloud y es posible que deba proporcionar excepciones para algunos servicios de Google Cloud. [2]
- Los grupos externos no pueden ser propietarios de proyectos propiedad de la organización. Puede tener group@example.es como propietario del proyecto y group@example.com como miembro de group@example.es , o puede tener group@example.com como editor de proyecto. [3]
- Acceso sensible al contexto : cualquier persona que no forme parte de su organización, incluso si los ha agregado al grupo de usuarios que deberían estar sujetos a las restricciones de acceso sensible al contexto, no están sujetos al enlace de acceso. [4]
[1] https://cloud.google.com/resource-manager/docs/organization-policy/restricting-domains
[2] https://cloud.google.com/resource-manager/docs/organization-policy/restricting-domains#known_issues
[3] https://cloud.google.com/iam/docs/faq#can_i_use_google_groups_with
[4] https://cloud.google.com/context-aware-access/docs/securing-console-and-apis
La configuración de Google Cloud Identity para empresas multinacionales se publicó originalmente en Google Cloud - Community on Medium, donde las personas continúan la conversación destacando y respondiendo a esta historia.