admin/directory: unable to authenticate requests

[derekperkins]

We're trying to use the admin/directory package on GKE using Workload Identity, and it doesn't appear to be working. We use multiple other Google Cloud apis, though I believe all of them are using the proto generated clients at google.golang.org/genproto/googleapis/.

After a lot of trials and searching, I believe that this library suffers from the same issue with Workload Identity on GKE as both the Java and .Net SDKs.
googleapis/google-auth-library-java#283
googleapis/google-api-dotnet-client#1409

I tracked it down and submitted a PR for that, but that didn't seem to solve the issue.
googleapis/google-cloud-go#1891

Really baffled by what could be causing this.

[derekperkins]

cc @whizard @mordfustang

[codyoss]

I will try to take a look at this today and get back to you. Sounds like it should be easy to reproduce.

[codyoss]

Could you please share a code snippet of how you are creating your client and what types of options you might be passing in?

[codyoss]

Same issue as googleapis/google-cloud-go#1892. Will keep both open temporarily while I try to figure out where the problem is.

[codyoss]

Let's have all relevant discussion over on the other issue.

[derekperkins]

Ok, will do. Thanks

[codyoss]

Moving the discussion back over here as we have ruled out an Workload Identity issue. The issue seems to be proper scoping. Look around I have noticed similar issues in other repositories of ours as well.

Node: googleapis/google-api-nodejs-client#1884

[codyoss]

Also, I suggest taking a look at this thread: #379

[derekperkins]

Thanks for finding those references. Copying the Google issue tracker link here for reference: https://issuetracker.google.com/issues/113755665

to use Directory API, you need to impersonate an admin in the domain using domain-wide delegation. See https://developers.google.com/identity/protocols/oauth2/service-account#delegatingauthority for details. You need a "sub" claim (field) that includes the email address of an admin to impersonate

That seems like an unreasonable policy as it defeats the entire purpose of service accounts. Assuming that they're not going to fix that server-side, we're now prevented from using the SDK until this is resolved: #378

[derekperkins]

Thanks again @codyoss. We had just been switching to Workload Identity so I just assumed that we had misconfigured something there. I never dreamed that the server would just not allow for service accounts to access the api. I'll go ahead and close this for now in favor of the linked issue, and hopefully this helps somebody else save a couple of days of figuring out auth.

[codyoss]

I am sorry this api caused so much trouble. I have started some talks internally to at least provide some helpers for this api until we have better support for impersonating credentials. This feature still should eventually land, just not sure when right now.

[derekperkins]

I'll post back here once we decide on a workaround. We'll be checking out this library mentioned in one of the other issues. I'm not in love with importing a package for auth impersonation on a service account we're granting G Suite God mode to, so maybe we'll just copy and audit it.
https://github.com/salrashid123/oauth2#usage-impersonatedcredentials

[whizard]

@derekperkins Thanks for bringing this up. If we truly believe in Least Privilege then we need to have this API do things appropriately. Please let us know when this can be resolved. Thanks.