Add support for Workload Identity Federation authentication

[fjkdjhfs]

GCP's Workload Identity Federation allows other Cloud Providers to obtain temporary credentials to GCP Service Accounts without the need to create Service Account Keys for said Service Accounts. This behaviour is highly desirable from a security perspective as it means we do not have to worry about dealing with long-lived Service Account Keys.

Workload Identity Federation works by having a Workload Identity Pool generate a credential configuration file that can be passed to any GCP client just like as if it were a Service Account Key. This credential configuration file contains no sensitive information, but instead instructs the GCP client (which could be running on an AWS instance for example) how to go about talking to GCP to obtain temporary credentials. It is brilliant and makes for very secure communication.

Unfortunately, right now, it is not possible to use Workload Identity Federation credential configuration files with the GCP Auth backend. The problem is that these files contain no private keys and the current credentials implementation does an explicit check for such keys. The result is a frustrating error that forces the user to use Service Account Keys instead.

Would it be possible to get rid of such checks and allow for credential configuration files to be passed to the GCP Auth backend? Furthermore, the current documentation states that the common ways of providing credentials to Google Cloud are supported. I hope I have shown here that this is not the case right now.

[nia-potato]

need this too.

[nia-potato]

@hsimon-hashicorp @tvoran i think this needs to remove checks to support workload identity, can anyone from hashicorp take a look at this? I currently cannot stand up gcp auth with workload identity, are there any current documentation that supports workload identity on gcp auth?

[fairclothjm]

Hello! Thanks for the feature request! We think this is a reasonable request. We would happily accept a PR for this.

[shinji62]

I think that have been already implemented as part of #204