## Overview Add support for AWS Elastic Container Registry (ECR), Google Artifact Registry (GAR), and Azure Container Registry (ACR) as upstream sources in the Docker virtual registry. These cloud provider registries use IAM-based authentication with short-lived tokens, which requires a fundamentally different approach than the username/password and long-lived token authentication supported in the beta for Docker Hub, Harbor, and Quay. This is one of the most requested capabilities for the Docker virtual registry. Enterprise customers running workloads on AWS, GCP, and Azure need to aggregate images from their cloud-native registries alongside public registries like Docker Hub. Without this, the Docker virtual registry cannot serve as a true single pane of glass for container image management. ## Goals * Support ECR, GAR, and ACR as first-class upstream sources in Docker virtual registries * Handle IAM-based authentication and automatic short-lived token refresh transparently * Leverage existing GitLab cloud provider integrations where available * Provide connection testing and health monitoring for cloud provider upstreams ## Scope ### In Scope #### AWS ECR * IAM role-based authentication support * Automatic token refresh (ECR tokens are valid for 12 hours) * Cross-region ECR support * Support for both public and private ECR registries #### Google Artifact Registry * Service account authentication * Workload identity support (where available) * Multi-region support * Leverage existing GitLab Google Cloud IAM integration as a prerequisite #### Azure Container Registry * Managed identity authentication * Service principal support * Cross-subscription registry support #### General * Cloud provider credential configuration via UI and API * Connection testing and health checks for IAM-authenticated upstreams * Automatic credential/token refresh handled transparently by the backend * Audit logs for cloud provider authentication events * Clear documentation for each provider's setup requirements ## User Stories As a DevOps engineer on AWS, I want to add our ECR registry as an upstream source in the Docker virtual registry so that my teams can pull internal and public images from a single endpoint. As a platform engineer on GCP, I want to configure Google Artifact Registry as an upstream using our existing service account so that I don't need to manage separate long-lived credentials. As an administrator, I want the virtual registry to automatically handle ECR token refresh so that image pulls don't fail when the 12-hour token expires. As a platform engineer, I want to test the connection to my cloud provider upstream during setup so that I can verify authentication is working before developers start pulling images. ## Technical Considerations * **Token refresh architecture:** ECR tokens expire every 12 hours, GAR service account keys are long-lived but workload identity tokens are short-lived, ACR tokens vary by auth method. The backend needs a robust token refresh service that handles each provider's lifecycle. * **"Token to get a token" pattern:** Cloud provider registries require an IAM token to obtain a registry-specific bearer token. This two-layer authentication adds complexity (see discussion in &6061). * **Integration reuse:** Leverage existing GitLab Google Cloud IAM integration for GAR. Investigate similar integration patterns for AWS and Azure. * **Competitive context:** Both JFrog Artifactory and Sonatype Nexus struggle with ECR token refresh — neither has robust built-in IAM integration. A strong implementation here is a competitive differentiator. * **Design for extensibility:** The authentication backend should support adding new cloud providers without major refactoring. ## Acceptance Criteria * \[ \] ECR, GAR, and ACR can be added as upstream sources in Docker virtual registries * \[ \] IAM-based authentication is configured via UI and API for each provider * \[ \] Token refresh is handled automatically and transparently — no manual intervention required * \[ \] Connection testing validates authentication during upstream setup * \[ \] Health monitoring detects and surfaces authentication failures * \[ \] Audit logs capture cloud provider authentication events * \[ \] Documentation covers setup for each provider with step-by-step guides * \[ \] Image pulls from cloud provider upstreams perform within acceptable latency thresholds ##