You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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.
The text was updated successfully, but these errors were encountered: