Setting up Google Cloud Identity for Multinational Companies

Published in

Google Cloud - Community

4 min readNov 19, 2020

First step when on-boarding an enterprise in Google Cloud is to set up Cloud Identity or Google Workspace to centrally manage Google Cloud.

This process is well explained in the Enterprise onboarding checklist and there are best practices and reference architectures in the Cloud Identity Architecture site.

Setting up Cloud Identity for multinational companies can be trickier taking into account that these companies may have centralized services such as the email service but by the other hand, their Operating Companies (OpCos) may have enough autonomy to manage their own Google Cloud Organizations.

Overview

Let’s suppose there is a multinational company called “Example LLC” with four subsidiaries (or OpCos) in Brazil, UK, Germany and Spain.

“Example” owns a set of shared services including the global identity and email services for all of their employees (<user>@example.com), offered by a global instance of Microsoft Azure AD. A guide to setup user federation between Azure AD and Cloud Identity is available here.

On the other hand, the different OpCos have full autonomy in terms of Technology and Operations, and therefore each OpCo they decide to manage its own Google Cloud Organization.

The issue

The Organization resource is the root node in the Google Cloud resource hierarchy and is the hierarchical super node of projects. The Organization resource is available once Google Workspace or Cloud Identity is set up and for that it is mandatory to verify the company’s domain . This domain is used during the Google Cloud authentication process to identify to what Organization the user belongs to, therefore a domain can only belong to a unique Cloud Identity of the Google Cloud Organization.

Summarizing:

All the users from the different OpCos share the same domain in their email address (<user>@example.com)
Each OpCo require to have their own Google Cloud Organization (and its associated domain)
The example.com domain can only be associated with a unique Cloud Identity instance.

How can @example.com users from the different OpCos get access to their corresponding Google Cloud Organization ?

The solution

A solution for this use case could consist in setting up different Cloud Identity instances:

1 x global Cloud Identity instance (CI Global) associated with the example.com domain and containing all the users belonging to the different OpCos. This CI would be responsible for user authentication and would be integrated with the Azure AD for user federation and Single Sign On.
n x Cloud Identity instances (CI OpCo) associated to each one of the OpCos domains/Google Cloud Organizations. These CI instances wouldn’t contain users, but could contain local groups (i.e. gcp-net-admins@example.de). The authorization to manage the resources hosted in the OpCo Organization is performed by Cloud IAM, assigning permissions to user identities available in the CI Global.

In case a user has permissions in 2 different Organizations and access the Google Cloud Console, it can select the right one in the Google Cloud Console

Restricting the allowed identity domains

In order to restrict the set of identities that are allowed to be used in IAM policies of each one of the OpCo Organizations, it is necessary to set iam.allowedPolicyMemberDomains organization policy [1].

iam.allowedPolicyMemberDomain defines the set of members that can be added to Cloud IAM policies. The allowed/denied list must specify one or more Cloud Identity or Google Workspaces customer IDs.

The organization policy can be set up using the Google Cloud Console or the following gCloud command:

gcloud alpha resource-manager org-policies allow \
--organization 'ORGANIZATION_ID_example_opco' \
 iam.allowedPolicyMemberDomains 'CUSTOMER_ID_example.com' \
 'DOMAIN_ID_example_opco'

The Domain ID can be obtained using the following gCloud command:

gcloud organizations list

This command will return the DISPLAY_NAME, ID (Organization ID), and DIRECTORY_CUSTOMER_ID. The Google Workspace customer ID is the DIRECTORY_CUSTOMER_ID.

Considerations and limitations

Domain restricted sharing (allowedPolicyMemberDomain) can interfere with some Google Cloud services, and you might need to provide exceptions for some Google Cloud services. [2]
External groups are not allowed to be owners of organisation-owned projects. You can have group@example.es as project owner and group@example.com as member of group@example.es, or you can have group@example.com as Project Editor. [3]
Context-Aware Access: Anyone not part of your organization, even if you’ve added them to the group of users that should be bound by Context-Aware Access restrictions, are not subject to the access binding. [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