VOOZH about

URL: https://repost.aws/questions/QUn_MwE5MZSpGlvKKGsy05Jw/pull-ecr-images-from-eks-with-custom-vanity-domain

⇱ Pull ECR Images from EKS with Custom Vanity Domain | AWS re:Post


Skip to content

Pull ECR Images from EKS with Custom Vanity Domain

0

I've set up a simple HTTP redirect vanity domain for my ECR private registry, e.g. docker.mycompany.com.

I can easily log in, pull/push images to the registry, etc. on my local machine and in CI:

aws ecr get-login-password | docker login -u AWS --password-stdin docker.mycompany.com
docker pull docker.mycompany.com/my-image:latest
docker push docker.mycompany.com/my-image:latest

I have an EKS cluster and when I attempt to run a container using this image, if I use the actual underlying ECR private registry URL, it works just fine:

kubectl run -it --rm --image=012345678901.dkr.ecr.us-east-1.amazonaws.com/my-image:latest \
 tmp-my-image

However, if I attempt to use my custom vanity domain, it fails:

kubectl run -it --rm --image=docker.mycompany.com/my-image:latest \
 tmp-my-image

This essentially times out after a while saying that image pull failed: image can't be pulled.

I think what's happening is that EKS does not see the custom domain as being ECR and this is the source of the issue.

Is there a way that I can tell EKS/Kubernetes that it should use ECR auth scheme for my custom vanity name for the registry?

2 Answers
  • Newest
  • Most votes
  • Most comments
Are these answers helpful? Upvote the correct answer to help the community benefit from your knowledge.
0
This recommendation was generated using AWS Generative AI capabilities. You are responsible for evaluating the recommendation in your specific context and implementing appropriate oversight and safeguards. Learn more
This answer has not been reviewed by an expert

To use a custom vanity domain with Amazon ECR in your EKS cluster, you need to configure Kubernetes to authenticate properly with your custom domain. The issue you're experiencing occurs because the EKS nodes don't recognize your vanity domain as an ECR endpoint and therefore don't apply the appropriate authentication.

Here are a few approaches to solve this:

  1. Create an image pull secret: You'll need to create a Kubernetes secret with your ECR credentials and reference it in your pod/deployment specs:
kubectl create secret docker-registry ecr-cred \
--docker-server=docker.mycompany.com \
--docker-username=AWS \
--docker-password=$(aws ecr get-login-password) \
--namespace=your-namespace

Then reference this secret in your pod spec:

imagePullSecrets:
- name: ecr-cred
  1. Use a credential helper on your nodes: You can configure the containerd runtime on your EKS nodes to use the ECR credential helper for your custom domain. This would require customizing your node configuration.

  2. Use a pull-through cache configuration: If you're using your vanity domain as a proxy to ECR, ensure your node's containerd configuration recognizes this mapping.

For EKS nodes using containerd runtime (which is the default), you can pull images directly using the ctr command with authentication:

ctr image pull --user "AWS:$(aws ecr get-login-password --region region)" docker.mycompany.com/my-image:latest

However, for Kubernetes to use your vanity domain automatically, you'll need to implement one of the solutions above, with the image pull secret being the most straightforward approach.

Remember that the EKS worker node IAM role must have the necessary ECR permissions (BatchCheckLayerAvailability, BatchGetImage, GetDownloadUrlForLayer, GetAuthorizationToken) for any ECR operations to work.
Sources
How to pull ECR image using ctr tool where runtime is containerd? | AWS re:Post
Using Amazon ECR Images with Amazon EKS - Amazon ECR

answered a year ago

  • Naftuli Kay
    a year ago

    The only issue I see above is that the login password will expire. I have seen people essentially write a CronJob which will update the secret on an interval, but I suppose this means that there's no built-in way of doing this.

0

You're spot on , AWS doesn't provide a built-in refresh mechanism for vanity domains. Most teams either:

  • Write a CronJob to rotate the secret
  • Or switch back to using the raw *.amazonaws.com ECR URL to avoid the hassle
  • If you're committed to the vanity domain for branding or standardization, then the CronJob pattern is the safest and most common fix.

answered a year ago