Feature request: Support OCI registry proxies with cloud provider authentication

[yegortokmakov]

Problem

When using a custom OCI registry proxy/gateway (e.g., oci-gateway.example.org) with cloud provider workload identity authentication (GCP, AWS, Azure), the source-controller fails because the auth package validates that the registry domain matches official cloud provider patterns.

Example error with GCP:

HelmChart 'xxx' is not ready: unknown build error:
failed to get credential from 'gcp': failed to parse artifact repository
'oci-gateway.example.org/oci/charts/': invalid GCP registry:
'oci-gateway.example.org'. must match ^(((.+\.)?gcr\.io)|(.+-docker\.pkg\.dev))$

Motivation

Organizations deploy OCI registry proxies/gateways for legitimate reasons:

• Security: Centralized access control and audit logging
• Multi-cloud: Unified registry endpoint across cloud providers
• Caching: Reduced latency and bandwidth costs
• Compliance: Data residency and network isolation requirements

These proxies are trusted and authenticate to the upstream registry on behalf of clients, but still require the source-controller to obtain valid cloud provider credentials. The current hardcoded domain validation blocks this use case.

Affected Components

Provider	Validation Pattern
GCP	^(((.+\.)?gcr\.io)|(.+-docker\.pkg\.dev))$
AWS	ECR pattern + public.ecr.aws
Azure	^.+\.(azurecr\.io|azurecr\.cn|azurecr\.de|azurecr\.us)$

Proposed Solution

Add a controller flag --oci-skip-registry-validation that bypasses domain validation for all cloud providers. This allows using custom registry proxies while still obtaining cloud provider credentials via workload identity.

Usage

spec:
  containers:
    - name: manager
      args:
        - --oci-skip-registry-validation=true

Or via Helm:

extraArgs:
  - --oci-skip-registry-validation=true

Security Considerations

• This flag should only be enabled when using trusted registry proxies
• The proxy is responsible for validating upstream registry access
• Cloud provider credentials will be sent to the configured registry endpoint
• Consider network policies to restrict egress to known proxy endpoints

Alternatives Considered

1. Allowlist of custom domains: More complex, requires maintaining domain lists
2. Per-resource annotation: More granular but increases API surface
3. Automatic proxy detection: Unreliable and adds complexity

The global flag approach was chosen for simplicity and alignment with existing Flux patterns (e.g., --default-service-account).

[yegortokmakov]

RFC @stefanprodan @matheuscscp