Bug 1476330 - oc secret new-dockercfg generated secret is not compatible with registry.connect.redhat.com
oc secret new-dockercfg generated secret is not compatible with registry.conn...
Status: VERIFIED
Product: OpenShift Container Platform
Classification: Red Hat
Component: Command Line Interface (Show other bugs)
3.6.0
Unspecified Unspecified
urgent Severity high
: ---
: 3.7.z
Assigned To: Juan Vallejo
Xingxing Xia
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-28 12:07 EDT by Aaron Weitekamp
Modified: 2018-02-20 14:57 EST (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-28 14:10:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3356541 None None None 2018-02-16 17:08 EST

  None (edit)
Comment 1 Aaron Weitekamp 2017-07-28 12:12:13 EDT
WORKAROUND (edit): also need to link the secret

$ docker login registry.connect.redhat.com --username developer@example.com
Password: *************
Login Succeeded
$ oc secret new redhat-connect .dockerconfigjson=/root/.docker/config.json
$ oc secrets link default redhat-connect --for=pull
Comment 2 Paul Weil 2017-07-28 14:10:15 EDT

*** This bug has been marked as a duplicate of bug 1476038 ***
Comment 3 Ben Parees 2017-10-10 18:44:49 EDT
this was improperly closed as a duplicate.
Comment 4 Ben Parees 2017-10-10 18:45:37 EDT
Michal this seems like an issue with registry.connect.redhat.com, or the k8s secret generation logic?
Comment 5 Michal Fojtik 2017-10-11 09:47:20 EDT
I think Oleg was looking into this, it is more like the secret format if I remember correctly.
Comment 6 Ben Parees 2017-10-11 10:41:21 EDT
If it's an issue w/ the secret format, why is this not a k8s bug?
Comment 7 Ben Parees 2017-10-12 10:18:26 EDT
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).
Comment 8 Juan Vallejo 2017-10-13 14:05:56 EDT
Origin PR: https://github.com/openshift/origin/pull/16868
Comment 9 Juan Vallejo 2017-10-13 19:35:56 EDT
Upstream PR: https://github.com/kubernetes/kubernetes/pull/53916
Comment 10 Juan Vallejo 2017-10-20 14:44:51 EDT
Upstream PR has merged. Waiting on Origin PR
Comment 11 Xingxing Xia 2017-10-27 07:22:27 EDT
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@example.com --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@example.com","password":"balabala","email":"unused","auth":"ZGV2ZWxvcGVyQGV4YW1wbGUuY29tOmJhbGFiYWxh"}}}
Comment 12 Xingxing Xia 2017-10-27 07:26:23 EDT
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)
Comment 13 Xingxing Xia 2017-11-05 22:38:36 EST
Fabiano, hello, could you check the above needinfo question and if the plain/duplication needs removed when you have time? Thank you
Comment 14 Fabiano Franz 2017-12-04 14:07:03 EST
Tagging Clayton to ask for an opinion.
Comment 16 Juan Vallejo 2018-01-09 14:30:56 EST
Upstream patch that addresses the concern stated in Comment 13
https://github.com/kubernetes/kubernetes/pull/57463

Will pick this change into Origin
Comment 17 Juan Vallejo 2018-01-09 15:03:46 EST
> 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
Comment 18 Maciej Szulik 2018-01-11 09:02:25 EST
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
Comment 22 Xingxing Xia 2018-02-02 05:39:08 EST
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
Comment 24 Xingxing Xia 2018-02-04 21:54:07 EST
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
Comment 26 Maciej Szulik 2018-02-06 04:46:09 EST
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.

Note You need to log in before you can comment on or make changes to this bug.