Google Artifact Registry credentials should be more flexible

[kacpercesarz98]

Checklist

• I've searched the issue queue to verify this is not a duplicate feature request.
• I've pasted the output of kargo version, if applicable.
• I've pasted logs, if applicable.

Proposed Feature

Improve the flexibility of Google Artifact Registry credentials service account impersonation.

Motivation

Currently, the hardcoded identity format:
kargo-project-<kargo project name>@<gcp project name>.iam.gserviceaccount.com leads to a suboptimal administrator experience.
In scenarios where tens or hundreds of projects are required, administrators must create numerous Service Accounts and IAM permissions, even when all of them ultimately point to the same Artifact Repository. This results in unnecessary complexity and overhead.

Suggested Implementation

Instead of enforcing a strict identity format, allow experienced users to manage their IAM configurations more flexibly. One possible approach is to enable mapping a Service Account to an Artifact Registry instance rather than binding it directly to a Kargo Project. Other way is to add some field/annotation to the Repository secret with the name of service account which should be impersonated.

[krancour]

For AWS/ECR, we have long had a feature where if the project-specific ambient credentials could not be assumed or were assumed and have insufficient permissions, Kargo will fall back on using the ambient credentials of the controller itself.

We don't have this for Google/GAR yet, but I've been meaning to get it caught up to AWS/ECR in this regard.

Without necessarily closing the door to other approaches in the future, would you find this relatively simple improvement helpful?

[kacpercesarz98]

For AWS/ECR, we have long had a feature where if the project-specific ambient credentials could not be assumed or were assumed and have insufficient permissions, Kargo will fall back on using the ambient credentials of the controller itself.

We don't have this for Google/GAR yet, but I've been meaning to get it caught up to AWS/ECR in this regard.

Without necessarily closing the door to other approaches in the future, would you find this relatively simple improvement helpful?

Yes it will be definitely helpful and more convenient. If it will not close doors for future improvements it is good enough for now.

[kacpercesarz98]

Another issue which I found is lenght limit of GCP service account name:
The account ID "kargo-project-*" does not have a length between 6 and 30., badRequest
It force me to create project with not clear, shortener name.

[remi-gelinas]

@krancour We're running into the same service account fatigue - we have a distinct project per logical application (for more granular access control) and it does get extremely cumbersome when the permissions required are the exact same for every SA. Being able to fall back to the controller's service account would be a VERY helpful quick win :D