Containers-roadmap: [ECR] [request]: support custom domains, or alternate URIs for repositories

[philippmoehler0440]

Tell us about your request
Currently a repository URI looks like this: <account_id>.dkr.ecr.<region>.amazonaws.com/<repository>. Account ID and region might be movable parts which has negative effects for the following scenarios described. It would be helpful to be able to define an alternate URI for ECR repositories.

Which service(s) is this request for?
ECR, (.. and maybe other container services?)

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Our team provides a docker image for ~12 other teams that acts as a build tool for frontend resources within their pipelines. We identified different disaster recovery scenarios where the current ECR URI is a disadvantage:

(1) Unavailability of ECR within the specified region

• For this case all teams would have to change the URI of our repository or won`t be able to deploy frontend resources instead, until ECR is reachable again.

(2) Disaster recovery for the ECR account

• When the account which contains the ECR repository is (e.g.) compromised or we have to do a complete disaster recovery for other reasons, then all teams would have to change the URI of our repository. This is a dependency we could prevent..

An alternate repository URI could be a fixed interface for other consumers. Changes for account ID or region behind this part would not affect them anymore.

Are you currently working around this issue?
One way we had seen to "solve" this, is to use an nginx as reverse proxy for the ECR, but this is an effort we don`t want to practice.

Additional context
This topic from January 2016 also describes some pain points with this.

Attachments

• none

[FernandoMiguel]

all my docker images have an ARG for the account id, so i can and do easily replace it to point to different accounts

[philippmoehler0440]

all my docker images have an ARG for the account id, so i can and do easily replace it to point to different accounts

This is fine if you are the only consumer - but with dependencies to around 12 other teams, you would always have to share this, even this could be solved more easily.

[jtoberon]

This is a great idea, and it's something we've planned for as we made other networking changes such as VPC Endpoint support. We see a bunch of additional benefits. For example, your developers will be able to use a friendly URI like "repo.mycompany.com" instead of having to remember an AWS account number. Also, if you run your own registry today, and you want to switch to ECR so that you don't have to manage (upgrade, monitor, scale, etc.) it, then DNS might help with the transition.

We are interested in hearing more about how customers would like to manage SSL certificates and DNS. Would you use AWS Certificate Manager (ACM) for certs? Would you create a Route 53 hosted zone for the subdomain?

[FernandoMiguel]

@jtoberon ACM for sure.
We already have hosted zones on route53

[philippmoehler0440]

@jtoberon yes we would use ACM and different hosted zones.

[okor]

@jtoberon

if you run your own registry today, and you want to switch to ECR ...., then DNS might help with the transition.

^ This is exactly the scenario we are in. If ECR supported custom DNS the switch would be relatively painless. Without custom DNS, there are a number of pain points:

• We will need to open up a ton of PRs to change Dockerfile FROM values.
• We will have to decide if we want to rewrite GIT history so older images can be built (rewriting GIT history is very cringy but so is having a repo history filled with Dockerfiles that won't be able to build)
• We _could_ circumvent the problem above by running our older registry in parallel to ECR but that ... also sucks.

And all of that is on top of the wacky authentication requirements for ECR. Y'all are not helping folks with established (but standard) authentication workflows or existing registries. The pain level goes up with the scale of the established operation. But those big registry users also seem like they would be the juicier targets for y'all, right?

[jtoberon]

@okor Currently, we're tentatively planning to work on this after cross region replication. What established authentication workflows do you have in mind?

[alok87]

When is the work going to start on this?
Interested to contribute to make this live. ✋

[fred-vogt]

Have to dog pile on this one.

I too have wanted this to be officially supported for awhile.

It is possible with an NGinx proxy.

• https://itnext.io/enable-aws-elastic-container-registry-custom-domain-and-anonymous-access-over-private-network-123d07663709

Or API gateway + lambda

• https://github.com/monken/aws-ecr-public

NOTE: you can't use the standard docker credential helper however, it has a regex that expects the default repo URIs

• https://github.com/awslabs/amazon-ecr-credential-helper
  
  
  
  • amazon-ecr-credential-helper/ecr-login/api/client.go#L34
  
  

[robbyt]

It looks like this was already requested back in early 2016 here: https://forums.aws.amazon.com/thread.jspa?threadID=223934&start=25&tstart=0

But unfortunately, the team at Amazon have been very quiet about when we can expect a fix for this.

[davidkarlsen]

+1.
We'd like to use ACM for the cert, but probably not route53 for DNS and instead cloudflare (simply because that's what we already do for the domain).

[terowz]

+850

[guerzon]

+1

This would definitely be very useful and would save our repositories and documentations from getting cluttered with a long ECR URL that has an account number in it.

[oleksandr-gubchenko]

+1

[michelangelomo]

+1

[LegoStormtroopr]

+1

(Purposefully not leaving a reaction, as I want to get notified when this is updated.)

[Rana-Salama]

You can subscribe to the issue to receive notifications instead of commenting.

[kj187]

+1

[Ferparishuertas]

+1