Unify AWS ECR and GCP Artifact Registry behavior in Docker reverse proxy

[warren830]

Summary

This PR introduces a unified architecture for handling Docker registry operations across AWS ECR and GCP Artifact Registry, ensuring consistent behavior and improved maintainability for multi-cloud deployments.

Key Changes

🏗️ Architecture Refactoring

• Introduced unified proxy interface: Created DockerProxyHandler interface to standardize behavior across cloud providers
• Factory pattern implementation: Added proxy_factory.go for automatic provider selection based on environment configuration
• Provider-specific handlers: Split logic into dedicated proxy_aws.go and proxy_gcp.go handlers

🏷️ Tag Format Standardization

• AWS ECR composite tags: Implemented templateID_buildID format instead of just buildID
• GCP consistency: Maintained existing templateID:buildID format
• Tag utilities: Added comprehensive tag generation, parsing, and validation with proper error handling

🔒 Enhanced Security & Validation

• Unified path validation: Both providers now use consistent URL path validation
• Template ID verification: Improved access control by validating template ownership across both platforms
• Input sanitization: Added proper validation for template IDs and build IDs to prevent injection attacks

🧪 Comprehensive Testing

• AWS registry tests: Added extensive test coverage for composite tag functionality
• Tag utility tests: Implemented 20+ test cases covering edge cases, validation, and error scenarios
• Mock ECR client: Created testable architecture with proper dependency injection

Technical Details

Before

// AWS returned: repositoryUri:buildID
// GCP returned: repositoryUri:templateID:buildID

After

// AWS returns: repositoryUri:templateID_buildID
// GCP returns: repositoryUri:templateID:buildID
// Both now include templateID for consistent access control

Provider Selection Logic

// Auto-detection based on environment variables:
// 1. CLOUD_PROVIDER (explicit)
// 2. AWS_ACCOUNT_ID (AWS detection)
// 3. GCP_PROJECT_ID (GCP detection)
// 4. Defaults to GCP for backward compatibility

Breaking Changes

⚠️ AWS ECR tag format changed: Tags now include template ID prefix (templateID_buildID instead of buildID)

Environment Variables

New required for AWS:

• CLOUD_PROVIDER: Set to "aws" or "gcp"
• AWS_DOCKER_REPOSITORY_NAME: ECR repository name
• AWS_REGION: AWS region
• AWS_ACCOUNT_ID: AWS account ID

Test Plan

• Verify AWS ECR operations with new composite tag format
• Confirm GCP Artifact Registry continues to work unchanged
• Test provider auto-detection logic with different environment configurations
• Validate template ID access control across both platforms
• Run integration tests for Docker push/pull operations
• Verify tag parsing and validation edge cases

Migration Notes

Existing AWS deployments will need to:

1. Set the new required environment variables
2. Update any hardcoded tag references to use the new composite format
3. Consider re-tagging existing images if strict consistency is required

[mlejva]

Hey @warren830, thanks for the PR.

I'm curious what's the goal of the PR - are you trying to run on AWS?

[warren830]

Hey @warren830, thanks for the PR.

I'm curious what's the goal of the PR - are you trying to run on AWS?

Yes, that's my target

[warren830]

We had some discussion in #846

[sitole]

I just quickly went through. Is there a reason why breaking change for AWS was introduced?

[warren830]

I just quickly went through. Is there a reason why breaking change for AWS was introduced?

There are two main reasons for introducing this breaking change for AWS:

First, I wanted AWS repos to also be able to use template IDs for differentiation, similar to other platforms.

Second, I wanted to ensure that AWS and GCP maintain the same workflow at the Docker proxy layer for consistency. This change helps align the processes between these two cloud providers.

[warren830]

Hi @sitole , is there anything I can do to do for this pr?

[sitole]

Hi @sitole , is there anything I can do to do for this pr?

Currently, we are internally discussing next steps.
We introduce build system v2, which discards the use of a private Docker repository. In the following weeks, it will start to be a not recommended way of building templates and will be needed just for temporary back compatibility.

[warren830]

Hi @sitole , is there anything I can do to do for this pr?

Currently, we are internally discussing next steps.

We introduce build system v2, which discards the use of a private Docker repository. In the following weeks, it will start to be a not recommended way of building templates and will be needed just for temporary back compatibility.

Ok,is there anything I can do to make aws available?