Using workload identity federation for admin sdk api

[tlonist]

How can I use workload identity federation to call admin sdk apis?

I know I can impersonate service account to call other services, for instance, like cloud storage buckets. But calling admin sdk api, like directory api, is different. Because it is admin feature, it typically needs impersonating to the admin user to use.

The thing is, credential acquired by using federation does not support createDelegated method, hence making it impossible to impersonate.

I've tried to pass the access token acquired from the federation credential to the Google credential, but it didn't help. (simply didn't work out)

Does anybody have any experience regarding this?

[abhishek-wings]

Hi,

There are two options:

1. You can use Menu > Security > Access and Data Control > API Controls and configure a service account.

2. Alternatively, you can create a custom role in the admin console to invoke a specific Admin SDK and add your GCP service account to that role via Menu > Account > Admin Roles > Create New Role.

 Enable Domain Wide Delegation -  https://developers.google.com/admin-sdk/directory/v1/guides/authorizing

                                                                    https://developers.google.com/admin-sdk/directory/reference/rest/v1/groups

[lawrencenelson]

Hi @tlonist,

Welcome to the Google Cloud Community!

May I ask the reason why you prefer using Workload Identity Federation instead of a Service account for calling Admin SDK?

Workload Identity Federation is designed to authenticate service accounts when your workloads run outside Google Cloud, allowing them to assume a Google Cloud identity without needing to manage long-lived service account keys. This is particularly useful for service-to-service authentication. However, when it comes to the Admin SDK, which often requires acting on behalf of a Google Workspace user, this approach encounters limitations.

This is because Workload Identity Federation doesn't natively support the user impersonation model that's typically used with the Admin SDK for tasks requiring user-level permissions. While a service account can be granted domain-wide delegation to impersonate a user, generating the necessary delegated credentials isn't directly facilitated by Workload Identity Federation.

What you might consider is configuring a service account with the appropriate domain-wide delegation and then using the credentials obtained through Workload Identity Federation to authenticate as that service .... Once authenticated, you can then use the delegated authority to perform actions via the Admin SDK as if you were the impersonated user.

You may also review this Stack Overflow thread - Accessing Google Admin API via Service Account.

I hope this answers your question. Thank you.

[tlonist]

This is because Workload Identity Federation doesn't natively support the user impersonation model that's typically used with the Admin SDK for tasks requiring user-level permissions. While a service account can be granted domain-wide delegation to impersonate a user, generating the necessary delegated credentials isn't directly facilitated by Workload Identity Federation.

This is truely the case. 

I'm considering using service account via federation, because I need to use it for my google workspace marketplace app. My app audits customers' workspaces for their token logs of various applications, much like what 'bettercloud' or 'G2' is doing. 

So to do so, I need a service account that can impersonate as customer workspace's admins, and should be able to query the necessary token logs. Do you see where I'm getting? Therefore, using the service account through json keyfile is extremely unsafe thing to do.

Do you have any better approaches? I've taken the measure here (https://cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys#domain-wide-deleg...), and it worked out just fine.