Bug 1282426 - The secret cannot be recognized which was added via .docker/config.json
The secret cannot be recognized which was added via .docker/config.json
Product: OpenShift Container Platform
Classification: Red Hat
Component: Command Line Interface (Show other bugs)
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Fabiano Franz
Wei Sun
: UpcomingRelease
Depends On:
  Show dependency treegraph
Reported: 2015-11-16 06:27 EST by Meng Bo
Modified: 2016-01-26 14:19 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-01-26 14:19:02 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Meng Bo 2015-11-16 06:27:40 EST
Description of problem:
The docker login will generate .docker/config.json instead of .dockercfg for the latest docker client.

But the secret add via .docker/config.json cannot be recognized by kubernetes/openshift.

Version-Release number of selected component (if applicable):
oc v3.1.0.4-9-g72d3991
kubernetes v1.1.0-origin-1107-g4c8e6f4

How reproducible:

Steps to Reproduce:
1. Login to docker hub to generate the docker config file on local
2. Convert the config file to secret via oc
$ oc secret new <name> .docker/config.json

Actual results:
The docker config file with name .docker/config.json cannot be recognized.
Only the old name .dockercfg works.

Expected results:
Should deal with the docker config with new name.

Additional info:
This will block the build process which needs a private docker image.

secret 'pull' was created by .docker/config.json 
secret 'pull2' was created by .dockercfg
# oc get secret
NAME                       TYPE                                  DATA      AGE
builder-dockercfg-8mf8v    kubernetes.io/dockercfg               1         2h
builder-token-n37ya        kubernetes.io/service-account-token   2         2h
pull                       Opaque                                1         1h
pull2                      kubernetes.io/dockercfg               1         37m
Comment 1 Meng Bo 2015-11-16 06:29:57 EST
# oc logs ruby-sample-build-1-build
I1116 05:42:58.879831       1 source.go:145] Cloning source from git://github.com/openshift/ruby-hello-world.git
F1116 05:43:00.015844       1 builder.go:59] Build error: '/var/run/secrets/openshift.io/pull/.dockercfg': open /var/run/secrets/openshift.io/pull/.dockercfg: no such file or directory

Error like above appears when using the secret which was generated by .docker/config.json
Comment 2 Fabiano Franz 2015-11-19 13:46:36 EST
Fixed in https://github.com/openshift/origin/pull/5744
Comment 3 Meng Bo 2015-11-23 03:46:49 EST
Checked with oc version v1.1-148-g16931c3, the issue still can be reproduced.

Seems the type defined in kubernetes is incorrect. (but I am not pretty sure)

$ oc secrets new test1 .docker/config.json
$ oc secrets new test2 .dockerconfigjson
$ oc get secret
NAME                       TYPE                                  DATA      AGE
test1                      Opaque                                1         1m
test2                      kubernetes.io/dockerconfigjson        1         1m
Comment 4 Meng Bo 2015-11-24 00:01:53 EST

Can you figure out what are changed? I still get the same result as Comment#3.

$ oc secrets new test-1 .docker/config.json 
$ oc secrets new test-2 .dockerconfigjson 
$ oc get secret
NAME                       TYPE                                  DATA      AGE
test-1                     Opaque                                1         18s
test-2                     kubernetes.io/dockerconfigjson        1         3s
Comment 5 David Eads 2015-11-24 08:06:16 EST
Since the key name is not a direct filename match, you have to specify the key like this:

oc secrets new -o yaml my-secret .dockerconfigjson=.docker/config.json
Comment 6 Meng Bo 2015-11-24 21:07:52 EST

Do you think we should add the usage in commnet#5 to the help page? Or else user won't know how to use the .docker/config.json correctly.
Comment 7 Fabiano Franz 2015-11-25 11:43:48 EST
@meng sure, example added in https://github.com/openshift/origin/pull/6086
Comment 8 Meng Bo 2015-11-25 21:41:41 EST
Bug has been fixed.
The usage print on the help page, and the secret with new docker config format can be identified. 

$ oc secrets new --help
Create a new secret based on a file or directory

Key files can be specified using their file path, in which case a default name will be given to them, or optionally 
with a name and file path, in which case the given name will be used. Specifying a directory will create a secret 
using with all valid keys in that directory.

  oc secrets new NAME [KEY=]SOURCE ... [options]

  # Create a new .docker/config.json secret named my-secret
  $ oc secrets new my-secret .dockerconfigjson=path/to/.docker/config.json

[user1@master ~]$ oc secrets new test5 .dockerconfigjson=.docker/config.json
[user1@master ~]$ oc get secrets
NAME                       TYPE                                  DATA      AGE
builder-dockercfg-41nn9    kubernetes.io/dockercfg               1         9s
builder-token-aev5c        kubernetes.io/service-account-token   2         9s
builder-token-n92am        kubernetes.io/service-account-token   2         9s
default-dockercfg-e4q21    kubernetes.io/dockercfg               1         9s
default-token-u7uzm        kubernetes.io/service-account-token   2         10s
default-token-zi564        kubernetes.io/service-account-token   2         10s
deployer-dockercfg-02xeo   kubernetes.io/dockercfg               1         8s
deployer-token-cdhk9       kubernetes.io/service-account-token   2         8s
deployer-token-qvoa8       kubernetes.io/service-account-token   2         9s
deployer-token-ubnra       kubernetes.io/service-account-token   2         9s
test5                      kubernetes.io/dockerconfigjson        1         3s
Comment 10 errata-xmlrpc 2016-01-26 14:19:02 EST
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.


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