Any update on this from Googlers? This is a pretty tricky annoyance in our CI/CD workflows on GitHub Actions to Vertex and Dataflow, since gcloud just works while TensorFlow Datasets (tfds CLI and tfds.load) does not without jumping through hurdles.

Hi,

If this is issue is related to any security vulnerability of Tensorflow, could you please report it in the proper channel so that this will be taken on priority.
For more details on how to report these, please refer https://github.com/tensorflow/tensorflow/security/policy#vulnerabilities-in-tensorflow

cc @sachinprasadhs
Is there any update here either from Google or acceptable workaround found by the community? Workload Identity Federation has been in GA for 4+ years and is GCP's recommended pattern for impersonating service accounts vs. using service account keys. Pulling from GCP's own documentation for "Best practices for managing service account keys":

Service account keys can become a security risk if not managed carefully. You should choose a more secure alternative for authentication whenever possible. The main threats are related to service account keys are:

• Credential leakage: Service account keys might inadvertently end up in places where they are not supposed to be stored. A bad actor can use a leaked service account key to authenticate and gain a foothold in your environment.
• Privilege escalation: If a bad actor gets access to a poorly secured service account key, they might be able to use the key to escalate their privileges.
• Information disclosure: Service account keys might inadvertently disclose confidential metadata.
• Non-repudiation: By authenticating using a service account key and letting the service account carry out operations on their behalf, a bad actor might conceal their identity and actions.

cc @sachinprasadhs Is there any update here either from Google or acceptable workaround found by the community? Workload Identity Federation has been in GA for 4+ years and is GCP's recommended pattern for impersonating service accounts vs. using service account keys. Pulling from GCP's own documentation for "Best practices for managing service account keys":

Even better Google has now gone even farther introducing direct auth, allowing you to fully bring your own identity to authenticate directly with GCP APIs instead of using an impersonated service account at all. Also recommended by Google over service account impersonation. That's certainly not supported here either.