Support for GCP Service Account with Workload Identity for GCR Artifact Registry

[mcsmgs]

Currently, version-checker only supports basic authentication, which limits the available methods for authenticating against GCR/GAR.

Deploying version-checker on GKE clusters would be significantly more secure if it could leverage Google ADC. This would allow us to stop using static service account keys in production environments, enabling deployments to use cluster metadata for accessing Google private registries.

If version-checker could support GCP Service Accounts with Workload Identity on GKE and GKE Enterprise (Fleet Workload Identity), the Helm chart would just need the required annotations, similar to the existing ECR iamRoleArn annotation.

---

Message from the maintainers:

If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.

[ribbybibby]

We could probably replace our GCR implementation with the google package in ggcr: https://github.com/google/go-containerregistry/tree/main/pkg/v1/google. This uses a custom keychain which can fetch credentials from ADC.

[davidcollom]

@mcsmgs Thanks for raising this issue, I actually hadn't realised this was the case.. (its been a while, since I looked at the gcr code)

I agree with @ribbybibby on this, using Google's SDK would be a better/stronger move here.. I'm actually in the process of updating most of the clients and will take a look at this in the coming days/weeks - right now I'm looking at the ACR Client for exactly the same reason of static tokens.

[mcsmgs]

Thanks, @davidcollom and @ribbybibby. That seems like the more native approach. For apps that don't fully support ADC, the fallback is to use Docker/credhelpers, which is currently the documented method for GKE Enterprise with Fleet Workload Identity (source). This approach uses the GOOGLE_APPLICATION_CREDENTIALS in the environment path.