Bug 1476330 - oc secret new-dockercfg generated secret is not compatible with registry.connect.redhat.com [NEEDINFO]
Summary: oc secret new-dockercfg generated secret is not compatible with registry.conn...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 3.6.0
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: ---
: 3.7.z
Assignee: Juan Vallejo
QA Contact: Xingxing Xia
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-28 16:07 UTC by Aaron Weitekamp
Modified: 2018-04-05 09:29 UTC (History)
26 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-05 09:28:25 UTC
jvallejo: needinfo? (smunilla)


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0636 None None None 2018-04-05 09:29:03 UTC
Red Hat Bugzilla 1462606 None CLOSED Cannot import image from Red Hat Container Catalog which requires authentication 2019-08-07 20:07:05 UTC
Red Hat Bugzilla 1473810 None CLOSED Cannot authenticate against registry.connect.redhat.com 2019-08-07 20:07:05 UTC
Red Hat Knowledge Base (Solution) 3356541 None None None 2018-02-16 22:08:34 UTC

Internal Links: 1462606 1473810

Comment 1 Aaron Weitekamp 2017-07-28 16:12:13 UTC
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 18:10:15 UTC

*** This bug has been marked as a duplicate of bug 1476038 ***

Comment 3 Ben Parees 2017-10-10 22:44:49 UTC
this was improperly closed as a duplicate.

Comment 4 Ben Parees 2017-10-10 22:45:37 UTC
Michal this seems like an issue with registry.connect.redhat.com, or the k8s secret generation logic?

Comment 5 Michal Fojtik 2017-10-11 13:47:20 UTC
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 14:41:21 UTC
If it's an issue w/ the secret format, why is this not a k8s bug?

Comment 7 Ben Parees 2017-10-12 14:18:26 UTC
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 18:05:56 UTC
Origin PR: https://github.com/openshift/origin/pull/16868

Comment 9 Juan Vallejo 2017-10-13 23:35:56 UTC
Upstream PR: https://github.com/kubernetes/kubernetes/pull/53916

Comment 10 Juan Vallejo 2017-10-20 18:44:51 UTC
Upstream PR has merged. Waiting on Origin PR

Comment 11 Xingxing Xia 2017-10-27 11:22:27 UTC
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 11:26:23 UTC
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-06 03:38:36 UTC
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 19:07:03 UTC
Tagging Clayton to ask for an opinion.

Comment 16 Juan Vallejo 2018-01-09 19:30:56 UTC
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 20:03:46 UTC
> 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 14:02:25 UTC
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 10:39:08 UTC
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-05 02:54:07 UTC
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 09:46:09 UTC
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.

Comment 44 errata-xmlrpc 2018-04-05 09:28:25 UTC
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


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