Feature request: Support OCI registry proxies with cloud provider authentication
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
- Allowlist of custom domains: More complex, requires maintaining domain lists
- Per-resource annotation: More granular but increases API surface
- 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).