### 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 ```yaml spec: containers: - name: manager args: - --oci-skip-registry-validation=true ``` Or via Helm: ```yaml 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`).