We run workloads on Amazon EKS and currently pull container images directly from Amazon ECR Public, Docker Hub, and other external registries. We want to move everything into our own private ECR repositories for better vulnerability scanning, governance, and reliability, since we have previously seen upstream images deleted or changed.
Should we also mirror the AWS-provided images required by EKS, such as CoreDNS, kube-proxy, and the VPC CNI, or is it reasonable to implicitly trust images hosted in Amazon ECR? What approach are other teams using, and what would be considered a good practice for securing and stabilizing the image supply chain?
4 Answers
Mirror production images into your private ECR and scan them before allowing them into the cluster. That gives you control over retention and lets deployments keep working even if an upstream image is deleted, changed, rate-limited, or temporarily unreachable. Keep the approved copy pinned to a digest rather than relying on mutable tags.
A common setup is to mirror approved images through CI/CD, scan them, pin them by digest, and control updates through a review or promotion process. Scanning alone is not a complete trust decision, so also consider image provenance, signing, least-privilege registry access, and policies that prevent unapproved registries or unscanned images from running.
An ECR pull-through cache can reduce the operational work. Configure it for the upstream registries you use, then have workloads reference the cached paths. For stronger control, promote images from the cache into an approved repository after scanning and validation instead of allowing every first pull directly into production.
I would include the AWS-managed EKS images rather than making an implicit trust exception for them. Images such as the VPC CNI, kube-proxy, and CoreDNS are still part of your production supply chain. Scan them, restrict who can publish or promote images, and update the mirrored versions when you upgrade the EKS cluster or add-ons.
Pay particular attention to add-on upgrades. A one-time copy can become stale because those images are tied to specific EKS and add-on versions.
That makes sense. Keeping an approved digest locally also means an upstream update cannot silently change what a deployment runs.