Bug 1476330

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