Hide Forgot
WORKAROUND (edit): also need to link the secret $ docker login registry.connect.redhat.com --username developer Password: ************* Login Succeeded $ oc secret new redhat-connect .dockerconfigjson=/root/.docker/config.json $ oc secrets link default redhat-connect --for=pull
*** This bug has been marked as a duplicate of bug 1476038 ***
this was improperly closed as a duplicate.
Michal this seems like an issue with registry.connect.redhat.com, or the k8s secret generation logic?
I think Oleg was looking into this, it is more like the secret format if I remember correctly.
If it's an issue w/ the secret format, why is this not a k8s bug?
This certainly looks like it's the classic issue w/ how k8s generates dockercfg secrets using the old docker format, not the new one. Moving to CLI team. (this may need to become an RFE though).
Origin PR: https://github.com/openshift/origin/pull/16868
Upstream PR: https://github.com/kubernetes/kubernetes/pull/53916
Upstream PR has merged. Waiting on Origin PR
With oc v3.6, indeed it produces format without the outer "auths" field in comment 0 Verified in oc v3.7 (v3.7.0-0.182.0), the format has "auths" field: $ oc secret new-dockercfg --docker-server=registry.balabala.com --docker-username=developer --docker-password=balabala --docker-email=unused redhat-connect-37 $ oc extract secret/redhat-connect-37 --confirm .dockercfg $ cat .dockercfg {"auths":{"registry.balabala.com":{"username":"developer","password":"balabala","email":"unused","auth":"ZGV2ZWxvcGVyQGV4YW1wbGUuY29tOmJhbGFiYWxh"}}}
But, should the file contains u/p in plain text? And they're duplicated with the encoded base64 ZGV2ZWxv..., should it it duplicate? (oc 3.6/3.7 both are so)
Fabiano, hello, could you check the above needinfo question and if the plain/duplication needs removed when you have time? Thank you
Tagging Clayton to ask for an opinion.
Upstream patch that addresses the concern stated in Comment 13 https://github.com/kubernetes/kubernetes/pull/57463 Will pick this change into Origin
> Will pick this change into Origin The fix will be brought in by the 1.9.1 rebase: https://github.com/openshift/origin/pull/18003
master is fixed in https://github.com/openshift/origin/pull/18003 3.8 is not affected 3.7 is fixed in https://github.com/openshift/origin/pull/18062
HI, checked with my docker.io private repo "docker.io/starxia/ruby-20-centos7" with both oc 3.7.9 and oc 3.7.27 (3.7.27 includes code of comment 19), the former cannot pull image, the latter can pull. So the code in comment 19 works well for private docker hub. Below are test results. Download v3.7.9 oc and v3.7.27 oc, then run: $ v3.7.9/oc secrets new-dockercfg secret-3-7-9 --docker-server=docker.io --docker-username=starxia --docker-password=$MYPASSWORD --docker-email=unused $ v3.7.27/oc secrets new-dockercfg secret-3-7-27 --docker-server=docker.io --docker-username=starxia --docker-password=$MYPASSWORD --docker-email=unused $ oc run mydc --image=docker.io/starxia/ruby-20-centos7 --command sleep 10d $ oc patch dc mydc -p '{"spec": {"template": {"spec": {"imagePullSecrets": [{"name": "secret-3-7-9"}]}}}}' Will see pod cannot pull private image: $ oc get po NAME READY STATUS RESTARTS AGE mydc-2-deploy 1/1 Running 0 16s mydc-2-tpcsx 0/1 ErrImagePull 0 10s $ oc patch dc mydc -p '{"spec": {"template": {"spec": {"imagePullSecrets": [{"name": "secret-3-7-27"}]}}}}' Will see pod running well: $ oc get po NAME READY STATUS RESTARTS AGE mydc-3-tfsdt 1/1 Running 0 7m --------------------------- But below results show the secret created by oc 3.7.27 is reverted to format causing the "FAILS" in comment 0: $ oc export secret secret-3-7-9 apiVersion: v1 data: .dockercfg: <snipped> kind: Secret metadata: creationTimestamp: null name: secret-3-7-9 type: kubernetes.io/dockercfg $ oc extract secret/secret-3-7-9 --confirm .dockercfg $ cat .dockercfg {"auths":{"docker.io":{"username":"starxia","password":"<snipped>","email":"unused","auth":"<snipped>"}}} $ oc export secret secret-3-7-27 apiVersion: v1 data: .dockercfg: <snipped> kind: Secret metadata: creationTimestamp: null name: secret-3-7-27 type: kubernetes.io/dockercfg $ oc extract secret/secret-3-7-27 --confirm .dockercfg $ cat .dockercfg {"docker.io":{"username":"starxia","password":"<snipped>","email":"unused","auth":"<snipped>"}} This confuses me whether oc 3.7.27 will work for registry.connect.redhat.com reported by Aaron. Maciej, the format in comment 0 reported this bug, now 3.7.27 reverted to that format, WDYT about this? Aaron, could you test oc 3.7.27 against registry.connect.redhat.com? I have no account on it. Thank you all
Chad Scribner, the problem is client caused, thus the workaround is to use new oc that includes the fix in comment 19. E.g. oc 3.7.27 verified in comment 22, or the 3.9 oc version >= the one verified in https://bugzilla.redhat.com/show_bug.cgi?id=1531511#c12 But I don't know if 3.7.27 oc will work against registry.connect.redhat.com this bug reported for, I'm waiting for feedback as asked in comment 22
I just double checked the fix against registry.connect.redhat.com and it is working just fine. The format the secret is in right now is the new docker supported format, so there shouldn't be any problems.
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. https://access.redhat.com/errata/RHBA-2018:0636