Checklist
Proposed Feature
Enable Kargo's ambient credential provider to support cross-account ECR access by dynamically assuming IAM roles in the account where the ECR registry resides.
Current Behavior
The ManagedIdentityProvider always uses the controller's AWS account ID (from sts:GetCallerIdentity) to construct the role ARN. Accessing ECR in a different account requires granting cross-account permissions to the controller role, which is less secure and more complex to manage.
Proposed Behavior
- Extract account ID from ECR URL — The URL already contains the target account ID (
${account_id}.dkr.ecr.${region}.amazonaws.com)
- Auth token workflow:
- Try assume
kargo-project-<project> in controller account (A) as usual
- If fails AND ECR account differs (current AWS account ≠ AWS account in repo URL) → try assume
kargo-project-<project> in ECR account (B)
- Fall back to controller role directly
Motivation
- Multi-account AWS architectures are common. ECR registries can be spread across multiple accounts
- Keeping ECR permissions scoped to the ECR account follows least privilege
- Creating a role that has access to ECR in other accounts can be a solution, but can be too complex if we have a lot of repositories.
Checklist
kargo version, if applicable.Proposed Feature
Enable Kargo's ambient credential provider to support cross-account ECR access by dynamically assuming IAM roles in the account where the ECR registry resides.
Current Behavior
The
ManagedIdentityProvideralways uses the controller's AWS account ID (fromsts:GetCallerIdentity) to construct the role ARN. Accessing ECR in a different account requires granting cross-account permissions to the controller role, which is less secure and more complex to manage.Proposed Behavior
${account_id}.dkr.ecr.${region}.amazonaws.com)kargo-project-<project>in controller account (A) as usualkargo-project-<project>in ECR account (B)Motivation