Revisit how we authenticate with GCP in GHA

[dcdenu4]

We are currently using a service account key from GCP to authenticate. Historically, given how our GHAs are set up for InVEST, each team member has copied those secrets over to their personal fork in order to develop and have the workflows pass there. There's a few issues with that general setup:

• Service account keys are essentially long-lived passwords that are tedious to manage. Google often points people to better authentication methods that are more secure and less likely to cause security concerns.
• Having secrets / keys copied into personal forks doesn't seem great. It's a hassle if a secret changes and needs to be updated and causes further risk exposure. If a team member ever left, they also would have those secrets still in their personal repo and if we felt like we needed to, we'd have to update our secrets.

One possible direction to take is using OpenID Connect (OIDC). This along with Google's Workload Identity Federation seem to provide a path towards more security and less maintenance. It appears that a lot of the permission checkpoints are handled on the GCP side.

• https://cloud.google.com/iam/docs/workload-identity-federation
• https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect

[phargogh]

It appears that we can also use OIDC to authenticate with PyPI from GHA: https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-pypi

[phargogh]

The best instructions I have found relating to identity federation have been in the little collapsible sections of https://github.com/google-github-actions/auth?tab=readme-ov-file#preferred-direct-workload-identity-federation, which will walk you through the specific gcloud commands to set things up.