Provide environment variable to automatically login to registries

[stevexuereb]

Problem

With the new Docker Hub limits, users are required to login Docker Hub when using Docker in Docker workflow so that users can build images. Building images usually involves pulling base images like alpine from Docker Hub.

Most of the time, these kinds of builds happen inside of a CI system, in multiple places. Right now users would have to remember to add docker login manually for every job that they run, this can be error-prone, tedious, and requires extra education/documentation for users writing every pipeline configuration.

The ideal scenario would be that you set this once somewhere, most likely by an administrator of the CI system so that it's transparent for the users that they need to login into the registry for Docker in Docker builds to prevent any rate limits.

Proposal

Support environment variable for auth configuration

Support an environment variable that specifies the auth configuration for the user. For example, let's consider the DOCKER_AUTH_CONFIG environment variable, it can be set to the following values.

Raw docker login:

{
        "auths": {
                "https://index.docker.io/v1/": {
                        "auth": "bXlfdXNlcm5hbWU6bXlfcGFzc3dvcmQ="
                }
        }
}

Credential store:

{
  "credHelpers": {
    "aws_account_id.dkr.ecr.region.amazonaws.com": "ecr-login"
  }
}

Inside of the entrypoint check for the presence of DOCKER_AUTH_CONFIG, if it's present set it to ~/.docker/config.json

Pros

• Can support multiple registries at once
• Can support more than just docker login flow, users can provide credHelpers and credStore

Cons

• Thecnincaly this isn't just about AUTH only this can set every config field inside of ~/.docker/config.json

Run docker login on entrypoint

We can add 3 new environment variables DOCKER_REGISTRY_USER, DOCKER_REGISTRY_PASS, and DOCKER_REGISTRY. DOCKER_REGISTRY should be optional since most of the time users want to log into Docker Hub.

If DOCKER_REGISTRY_USER and DOCKER_REGISTRY_PASS are present we can update the entrypoint to automatically run:

echo "$DOCKER_REGISTRY_PASS" | docker login $DOCKER_REGISTRY --username $DOCKER_REGISTRY_USER --password-stdin

Pros

• The administrator of the CI system can set these environment variables one time, and it's transparent for users who are running docker in docker builds.

Cons

• Only supports 1 registry
• Only supports registry authentication and no credential store helpers.

[tianon]

Ignoring for a moment that we are very hesitant to add additional environment variables to what Docker itself natively supports (and would prefer that those get added to Docker itself instead so that they are not a creation specific to this image), the main technical challenge I see here is that this login credential is needed on the client side of the usage, which is not typically inside the same container as the daemon (and the daemon only uses credentials that get passed to it from the client -- it never looks up credentials itself, unfortunately).

[stevexuereb]

@tianon thank you for taking the time to respond 🙇

Ignoring for a moment that we are very hesitant to add additional environment variables to what Docker itself natively supports (and would prefer that those get added to Docker itself instead so that they are not a creation specific to this image)

Ahh, I wasn't aware of this! Would it make sense to close this issue then and discuss it in moby/moby?

the main technical challenge I see here is that this login credential is needed on the client side of the usage,

I understand, which is why I was proposing to update the docker:19.03 entrypoint and not the dind image. From what I understand if we update that entrypoint that will update the docker:19.03 image which is the docker client right?

[tianon]

Yes, I think it makes sense to at least discuss the wishlist use-case of being able to pre-seed authentication to a daemon in moby/moby instead of here (IMO it would be interesting for the daemon to have fallback credentials in its own auth.json or similar that it uses when the client doesn't provide any for a given registry, but I'm not sure what the appetite for that in the moby/moby project is).

As for the client image, many of the CI providers using this image are not necessarily using the CLI image we provide because it's specifically compatible with any Docker client which can access it (by design/intention), and this environment variable wouldn't necessarily be set on the client context anyhow if it were set at a "system" level within the CI environment/dind service definition. 😅

[stevexuereb]

@tianon thank you so much for the help so far! I've opened moby/moby#41706 to discuss it there. I will close this issue for now since there isn't any action we can take here 🙇