Private ECR Helm/OCI dependency updates fail

[georgewaters]

Summary

Dependabot Helm jobs against private ECR OCI charts fail whenever helm dependency update actually needs to pull a chart. The job authenticates to ECR fine and resolves versions via the registry API, but the blob download fails because ECR always 307-redirects layer downloads to an S3-backed host, and that host is on neither the static allowlist nor derivable from the job's configured registry credentials.

Reproduction

Any Helm job with a docker-registry-type credential pointing at private ECR, where helm dependency update needs to resolve a new version.

Evidence

GET https://<account-id>.dkr.ecr.<region>.amazonaws.com/v2/<chart>/manifests/X.Y.Z → 200
GET https://<account-id>.dkr.ecr.<region>.amazonaws.com/v2/<chart>/blobs/sha256:... → 307
GET https://prod-<region>-starport-layer-bucket.s3.<region>.amazonaws.com/... (presigned)
* egress not allowlisted prod-<region>-starport-layer-bucket.s3.<region>.amazonaws.com
403 Forbidden
Error: could not download oci://.../<chart>: response status code 403: Forbidden

Related

• Public OCI registries blocked by the enforced proxy egress allowlist #264, Add azure blob redirect urls to egress allowlist #268 — same class of problem (registry → blob-storage redirect blocked). Add azure blob redirect urls to egress allowlist #268 fixed it for Azure's blob storage. No AWS/ECR equivalent exists.
• The existing JFrog entries in the defaults YAML (8 fixed exact s3.amazonaws.com hosts) are the most similar .

Notes

Our traffic hits eu-west-1 so I can confirm that prod-eu-west-1-starport-layer-bucket.s3.eu-west-1.amazonaws.com is a redirect target. The only evidence that I've found for other targets is from community write-ups (blog posts etc) rather than official AWS documentation.