Feature Request: Support wildcards in credHelpers config

Problem

Currently, it is only possible to configure a credential helper for an exact registry hostname. I'd like to explore the possibility of adding more expressiveness to the config file to simplify certain scenarios. There are two primary "flavors" of registry namespacing that you often see in the wild.

1. Path-namespaced registries

For example, Docker Hub.

All requests go to the same index.docker.io hostname (well... kind of), so the namespacing is based on the path. Notably, this means that I can only configure one identity for authenticating to Docker Hub, unless I engage in some $DOCKER_CONFIG shenanigans to point to different config files based on what I'm doing.

Possible solution: Allow some path-based matching in the credHelpers field to support something like:

{
  "credHelpers": {
    "index.docker.io/my-personal-repo": "pass",
    "index.docker.io/my-work-org": "paranoidcorp"
  }
}

You can imagine that your employer might want to control access to and rotation of credentials for their public repositories, so they developed docker-credential-paranoidcorp for managing those credentials.

2. Domain-namespaced registries

For example, ECR.

Both your AWS account and the region for a registry are encoded in the domain name. This makes things rather frustrating if you're dealing with a lot of registries. From the amazon-ecr-credential-helper docs, you can see that the first example recommends just setting credsStore:

{
	"credsStore": "ecr-login"
}

Why? Probably because you would otherwise have to configure every registry individually, which would be rather cumbersome. A major drawback of this global credsStore is that it precludes using any other cred helper for any other registries, so if you talk to anything other than ECR, you're out of luck.

It would be wonderful if you could do something like:

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

This would work for all regions and all accounts.

Some registries (e.g. GCR) even suffer from both of these problems, where there is a region encoded in the hostname and the namespace is encoded in the path.

Solutions?

I'm not sold on this exact syntax from my examples, but I think they demonstrate my point pretty well. I tried to find any previous discussion around this, but had no luck.

Is there any reason not to do something like this? I imagine deciding on an appropriate syntax will be rather difficult (to avoid breaking current config files), and we might need to land some changes in the credential helper protocol, but I don't see any technical blockers.

Personally, I'm most affected by the second case, where it would be nice to support wildcards (or something) in the hostname. (I don't really care about path stuff, but it is something to consider.)

If it's simpler to merge, a simple subdomain matching thing would be fantastic, e.g. this would be a huge quality of life improvement for me:

{
  "credHelpers": {
    "gcr.io": "gcr",
    "*.gcr.io": "gcr"
  }
}

Just so I could say gcr.io or any subdomain of gcr.io should use docker-credential-gcr instead of having an individual line for every region.

cc @dekkagaijin @tiborvass @vdemeester

Start by tracing how the Docker CLI reads and resolves the credHelpers configuration, then review the credential helper protocol implications mentioned in the issue. Done would require an agreed matching syntax and precedence rules that preserve existing configurations and cover hostname wildcards, with path matching treated as a separate scope.