Exploring the world of Multi-Cloud and unlocking its potentials … Part 1

This Blog series will look at how in my experience some industries configure identity synchronization into various other Cloud directories. Then we look at how we can pivot into these various directories without credentials/keys and thereby opening a whole new world of possibilities.

Let's look at the various components that make up scenarios we find in the real world.

Synchronization of identity to Google Workspace

Suppose you have an environment where you have an on-prem Active Directory environment and also use Azure AD/Entra as well as another cloud provider service like Google Workspace/GCP.

In this case, there are at least 3 ways that you can follow to synchronize identities to Google.

1. Synchronize identities from Active Directory to Google Workspace directly using GCDS (Google Cloud Directory Sync)
2. Using Directory sync to Google Workspace either from Entra or from AD(Cloud only similar to Entra Cloud sync). **This is currently in BETA**
3. Google cloud/GSuite Connector by Microsoft to sync identities from Entra to Google Workspace (SAAS Application available from Entra Enterprise application gallery)

Automation in Google Workspace through Domain Wide Delegation ( the old way )

Control API access with domain-wide delegation — Google Workspace Admin Help

If you need to automate things in the Google Workspace world, you need to be aware of this powerful feature called domain wide delegation. Basically, GCP and Google Workspace are different services. Hence, Service Accounts (Google Managed service accounts or User Managed Service accounts) in Google GCP Projects that we create, require a relationship with API scopes defined in Google workspace before they can access Google Workspace.

Let's see an example of how this looks like.

Below i have a GCP project created that i will be using for testing. The Google cloud domain is naras.cloud and the project name is NarasProject.

Once inside my project, I can create a Service Account that i wish to use to automate in Google Workspace.

I can create the Service account from within the Service Accounts blade.

Notice that the Key ID property is empty. That is, I have not created any Keys for authentication using this service account. Let's create the Key now.

Click Create

And this will create the JSON key which we can use for authentication to GCP as the service account.

Also note down the property Oauth2 Client ID as seen in the below screenshot.

Now, this Service account that we have created, cannot by default access any Services in the Google Workspace. We need to assign it a domain wide delegation AND API Scopes before we can start having fun with Google Workspace identities.

Lets go back to “https://admin.google.com” and login with our SuperAdmin Credentials which are required to create the domain wide delegation scopes.

Navigate to Security->Access and Data control-> API Controls.

Click on MANAGE DOMAIN WIDE DELEGATION

Click Add new and provide the OAuth2 Client ID which we saved before and the API scope we need which in this case we shall use as “https://www.googleapis.com/auth/admin.directory.user”

Click Authorize.

This completes the steps we need so that this Service account in GCP can now access Google workspace for that particular API.

But in this solution, there is a big difference. Once we authenticate as the Service Account, we would need to impersonate a user while calling the API and that User must be a real live user in the Google Workspace directory with the appropriate permissions already granted to them.

This is known as impersonation and why the domain-wide-delegation has come into the picture which we setup earlier.

Now, how can we use automation and manage identities in Google Workspace without using impersonation. Lets look at the next section.

Automation in Google Workspace through Domain Wide Delegation (the NEW way)

Recognizing the need to make it easier for Service Accounts in GCP to manage users in Workspace without needing to impersonate Live users in Workspace, Google introduced some changes a while back. Now you are allowed to add a Google Service account directly into ROLES available in Google Workspace.

Lets look at an example with a new service account which we can create in the same project.

Here we have a new service account created.

Now lets add this Service Account into the following Role in Google Workspace.

lets navigate to admin.google.com and -> Accounts ->Admin Roles

Click on User Management Admins and click Assign Admins

Now Click on Assign Service Accounts

Now, we can see that we can assign Groups as well as the role can be scoped to Organizational Units as well. For now, i give this service account role over the entire Domain for testing purposes.

Click on Assign Role and we are done.

Now, once you create a Key for the service account, you can authenticate and get the API scope for managing users directly into your Token. You no longer need to impersonate a user in the Google Workspace.

But for an important reason , i will not generate any KEYS for this service account now. We will see how that Service Account can still be used in our next segment.

***This has been a long post with many moving parts. So, let's continue the exploration in part 2***