Prevention code against forwarding credentials belonging to other registry than the one being contacted did not cope with urls lacking schema. These are recently being sent by Docker clients.
All the credentials were thrown away - therefore user couldn't authenticate to any registry except for docker.io.
Docker daemon's credential checking is now more robust.
Users can now authenticate against any registry.
Description of problem:
Docker cannot authenticate against additional registries.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. run daemon with --add-registry=<private>
2. docker login <private>
3. docker pull <private>/<user>/redis
[root@centos7 ~]# docker login $PRIVATE_REGISTRY
[root@centos7 ~]# docker pull <private>/<user>/redis
Trying to pull repository <private>/<user>/redis ... failed
FATA Authentication is required.
[root@centos7 ~]# systemctl status docker.service -l
docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled)
Active: active (running) since Mon 2015-04-06 20:49:51 MSK; 11min ago
Main PID: 10923 (docker)
└─10923 /usr/bin/docker -d --selinux-enabled
Apr 06 21:00:14 centos7.kasured.com docker: time="2015-04-06T21:00:14+03:00" level="info" msg="-job resolve_repository(<private>/<user>/redis) = OK (0)"
Apr 06 21:00:14 centos7.kasured.com docker: time="2015-04-06T21:00:14+03:00" level="info" msg="authConfig does not conform to given endpoint ( != <private>)"
Apr 06 21:00:14 centos7.kasured.com docker: Authentication is required.
Apr 06 21:00:14 centos7.kasured.com docker: time="2015-04-06T21:00:14+03:00" level="info" msg="-job pull(<private>/<user>/redis, latest) = ERR (1)"
Repository is pulled.
Created attachment 1011745 [details]
fix authentication issue
Note that this does not fix authentication against additional registries when dealing with unqualified repositories:
docker -d --add-registry $repo
docker login $repo
docker pull user/app
will still fails if $repo requires authentication.
Has there been any movement on this? It blows my mind that with RHEL 7.1 (in EC2) I am unable to pull any of my private containers from quay.io without failures. This seems like a crippling, huge, bug, and it's just sitting here for days.
Fixed in docker-1.5.0-30.el7.
Ashley, does the current build address your issue?
How would I get access to -30? In EC2 when I add server-extras it only has -28 currently. Is there another location for docker I should be pulling from?
One can find the latest docker version in virt7-testing repository. It is version 1.6.0-1.el7 though.
If you do not already have the repo file for this repository you can create it with the contents
Later on go ahead and install the latest docker with
yum --enablerepo=virt7-testing install docker
Meanwhile as the initial reporter of the issue I can verify that I can no longer reproduce the issue against the latest build version.
Login/Logout/Pull/Push are working as expected against the private repo as described in the aforementioned scenario.
Reproduced in docker-1.5.0-28 and verified in docker-1.6.0-11.el7.x86_64.
Anyone can refer http://www.dropbit.ch/private-docker-registry-with-nginx-on-centos-7/ to build a private docker-registry that uses https connection.
The key trigger step here is that use #docker login timesu.com(my repo address) instead of #docker login --username=timesu.com --password=$pwd https://timesu.com.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.