.docker/config.json does not support non-base64 username+password fields

[leonidas-o]

Tested on the following versions: Skopeo inside alpine:3.13.5 docker container

• version 1.2.1 commit: 1b6af3b15975f3142462b6affa85af708feb657f

Skopeo inside fedora:35 docker container

• version 1.2.4-dev

I got a ~/.docker/config.json file which looks like:

{
  "auths": {
    "https://eu.gcr.io": {
      "email": "user@example.com",
      "password": "{\"type\":\"service_account\", \"project_id\": \"MYPROJECTID\",\"private_key_id\": \"123456789\", \"private_key\":\"-----BEGIN PRIVATE KEY-----\nMYPRIVATEKEY=\n-----END PRIVATE KEY-----\n\",\"client_email\": \"my-devops-account@my-project.foo.gserviceaccount.com\", \"client_id\": \"1234567890\" ,\"auth_uri\": \"https://accounts.google.com/o/oauth2/auth\" ,\"token_uri\": \"https://oauth2.googleapis.com/token\" ,\"auth_provider_x509_cert_url\": \"https://www.googleapis.com/oauth2/v1/certs\" ,\"client_x509_cert_url\": \"https://www.googleapis.com/robot/v1/metadata/x509/my-devops-account%40my-project.foo.gserviceaccount.com\"}",
      "username": "_json_key"
    }
  }
}

This docker config.json is set on my host system (Windows - WSL with Ubuntu18.04) and inside the above mentioned docker containers.

When exectuting on my host system:

docker pull eu.gcr.io/my-project/path/to/myImage:develop

This works without any issues.

When executing inside one of the mentioned containers:

skopeo inspect --tls-verify=false docker://eu.gcr.io/my-project/path/to/myImage:develop

I get the following error:

FATA[0000] Error parsing image name "docker://eu.gcr.io/my-project/path/to/myImage:develop": Error reading manifest develop in eu.gcr.io/my-project/path/to/myImage: unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication

Seems like skopeo is not able to use the config.json.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[mtrmac]

Thanks for your report.

AFAIK the ~/.docker/config.json format is not documented to that level of detail. Looking at https://github.com/docker/cli/blob/e3ade90f5b820688f2297e7124c56a3a9e5a8e89/cli/config/configfile/file.go#L127-L133 , you’re right that no auth set + username and password set is read; OTOH the write path https://github.com/docker/cli/blob/e3ade90f5b820688f2297e7124c56a3a9e5a8e89/cli/config/configfile/file.go#L160-L163 makes it quite clear that Docker never creates such files and doesn’t intend them to exist.

So, without any documentation to the contrary (and neither https://docs.docker.com/engine/reference/commandline/cli/ nor https://docs.docker.com/engine/reference/commandline/login/#credentials-store AFAICS says anything to the contrary), it’s tempting to say that this is just exploiting a Docker bug.

Yet apparently there were others exploiting the reuse of the same Go type for config file storage and internal representation (in times where it was even clearer that it was not the intended file format), and it did become an (undocumented!) feature in https://github.com/docker/cli/pull/2122 , starting with Docker 19.03. Oh well.

@rhatdan Is there a general policy WRT keeping up with post-1.13.1 Docker?

[mtrmac]

Note:

• If we add the support, do we add it for auth.json as well, or only for the compatibility paths?
• Either way, it should be documented in https://github.com/containers/image/blob/main/docs/containers-auth.json.5.md .

[Omar007]

We just ran into this problem i.c.w. podman. We build the auths config dynamically due to the use of on-the-fly per-run credentials to be picked up by jobs using Kaniko and Docker (+DinD). When trying to add podman to this set, we ran into issues authenticating against our registries even though it used the exact same file for all these platforms/runs.
We ended up tracing it back to here, specifically https://github.com/containers/image/blob/75ac38905016123908a385c728863d5fdfe735be/pkg/docker/config/config.go#L873, and found this issue/feature request.