Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1506998

Summary: Should support to reveal secret with field .dockercfg
Product: OpenShift Container Platform Reporter: Xingxing Xia <xxia>
Component: Management ConsoleAssignee: Jakub Hadvig <jhadvig>
Status: CLOSED ERRATA QA Contact: Yadan Pei <yapei>
Severity: low Docs Contact:
Priority: medium    
Version: 3.7.0CC: aos-bugs, ffranz, jforrest, jhadvig, jokerman, mmccomas, xxia
Target Milestone: ---   
Target Release: 3.8.0   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-11-28 22:20:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
Page of secret of field .dockercfg does not show u/p
DC page's Reveal Secret shows [object Object] for image secret none

Description Xingxing Xia 2017-10-27 11:41:42 UTC
Created attachment 1344270 [details]
Page of secret of field .dockercfg does not show u/p

Description of problem:
Should support to reveal secret from .dockercfg

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. $ cat .dockercfg # fake password "balabala"

2. Create secret with the same file
$ oc secrets new mydockercfg .dockercfg

$ oc secrets new mydockerconfigjson .dockerconfigjson=.dockercfg

3. Go to secret page to check fields

Actual results:
3. Though `oc extract secret/$secret --confirm` gets same content for both secrets, for secret/mydockerconfigjson, page shows u/p, while for secret/mydockercfg, page shows "No username and password", see attachment

Expected results:
3. For both, page should show u/p to be consistent

Additional info:

Comment 1 Jakub Hadvig 2017-10-27 15:47:31 UTC
There are two types of docker config files.
1, ".dockercfg" that docker used up to version 1.7.x, which format is:
$ cat .dockercfg
        "registryaddress": {
                "auth": "auth string",
                "email": ""

2, "docker/config.json" that docker uses from version 1.8.x and up, which format is:
$ cat config.json
        "auths": {
                "registryaddress": {
                        "auth": "auth string",
                        "email": ""

I see that you mismatched those two in the mismatched those two in the repro steps. In step 1. you are creating the .dockercfg(which is the old format) and enter json in the new format.

When creating secrets there are differences between those two commands:

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

But I agree that mismatching the secret creation could happen pretty easy.
Would be maybe good to improve the warning when this happens.

Comment 2 Jakub Hadvig 2017-10-27 16:08:35 UTC
Also when creating the secrets (both cases) we dont do any semantic checks, we just check if the input is in the JSON format and thats and base on its structure
kubelet decides whats secret type, either:
- opaque

Comment 3 Jessica Forrester 2017-10-30 19:25:17 UTC
There was a change related to dockercfg secrets that was already applied to `oc secret new-dockercfg` but may not have been applied to `oc secrets new`

We should only be storing the new kind of docker config now.

Comment 4 Juan Vallejo 2017-10-30 21:07:33 UTC
In a few tests I did, I found that the web-console only revealed the secret's data if it was formatted in the new `config.json` format, and placed under the `.dockerconfigjson` field.

Storing `config.json`-formatted data under the `.dockercfg` field did not cause the web-console to reveal it. Neither did storing `.dockercfg`-formatted data under the `.dockercfg` field, or `.dockercfg`-formatted data under the `.dockerconfigjson` field.

Will open a PR against `oc secret new ...` to format data in a given .dockercfg file as `config.json`, regardless of the format in which it is originally given.

I believe that the web-console would also need a patch to handle data under a `.dockercfg` field, and not just under `.dockerconfigjson`.

Comment 5 Juan Vallejo 2017-10-30 21:30:26 UTC
Taking a look at the code for `oc secret new ...` [1], since we expect the fieldname and secret data to be anything (not just docker config data), I am not sure that we should make a special case for detecting if the given secret data was docker registry auth data, and that it is formatted in a way that we expect.

@ffranz maybe a solution could be to have the web-console handle both formats under both ".dockercfg" and ".dockerconfigjson" fields (and encourage users to use the "new-dockercfg" subcommand in the help output)?


Comment 6 Jakub Hadvig 2017-10-31 08:42:32 UTC
@jvallejo the webconsole is creating secret only in the `dockerconfigjson` format, not the old `.dockercfg`.
The patch for properly handling data under `.dockercfg` is here:

Comment 7 Juan Vallejo 2017-10-31 14:01:53 UTC
@jhadvig thanks for putting together a PR for this.

> the webconsole is creating secret only in the `dockerconfigjson` format, not the old `.dockercfg`.

What I meant by this was that, on the cli, there's no straightforward way (as far as I'm aware) to take a secret's data given to us by a user through `oc secret new ...` and parse it so that if it is the case that the data matches the .dockercfg format, it is stored as dockerconfig.json instead, without special casing a method meant to handle generic secret data. We are able to do this under the `new-dockercfg` sub-command, as we know the type of secret we are  dealing with, and only receive expected parameters with values, rather than a blob of generic data from a file.

Comment 8 Jessica Forrester 2017-10-31 15:06:54 UTC
The console fix in is the only fix necessary.

Comment 10 Xingxing Xia 2017-11-01 09:59:46 UTC
Per (RH internal), latest OCP v3.7.0-0.188.0 does not include include the PR origin-web-console/pull/2392. Neither does latest origin ami instance. Will verify next days

Comment 11 Xingxing Xia 2017-11-06 03:24:41 UTC
Checked in v3.7.0-0.194.0. The PR origin-web-console/pull/2392 seems not solving this bug's original description. See below
From the PR's comment, it solves to reveal secret whose key is .dockercfg and value is:
        "registryaddress": {
                "auth": "auth string",
                "email": ""

Though it is an issue and is indeed verified in v3.7.0-0.194.0, this bug was not opened for it. Instead, it was opened for another kind of secret whose key is .dockercfg but value is:
But this is not fixed in v3.7.0-0.194.0 and is still reproduced.

Honestly speaking, this bug is found after verifying another bug 1476330 : the secret created via CLI in reproduced this bug's issue (Note: the CLI created secret includes "username"/"password" fields in "auths") . So, this bug's issue is: no matter it has "username"/"password" fields in "auths" or not, we should reveal secret that uses ".dockercfg" as key and "auths" format as value.

Comment 12 Xingxing Xia 2017-11-06 03:35:07 UTC
BTW, found another issue in v3.7.0-0.194.0. It seems an web console equivalent bug  of the CLI bug 1476330:
In "Create Secret" page, "Secret Type" chooses "Image Secret", "Authentication Type" chooses "Image Registry Credentials", and input other fields like the CLI "oc secret new-dockercfg ..." in , then click Create. Check the secret, it uses old ".dockercfg" as key and no "auths" in value, similar to . I'm afraid the secret created from web console will still reproduce that issue "not compatible with registry.connect...". Now that CLI fixed it, web console seems to need fix it too?

Comment 13 Jakub Hadvig 2017-11-06 14:49:29 UTC
So what you are describing is that you create .dockercfg, which is an old  configuration file format with content:

which basically is the format for the new docker/config.json file type. So you are mixing two different things.
Please check where I described the format diffs

Comment 14 Jessica Forrester 2017-11-06 19:29:06 UTC
We've fixed what we can for 3.7 in

Remaining concern around changing the default type we create in the web console is being discussed in but the changes are too big for 3.7

Comment 15 Jakub Hadvig 2017-11-06 21:01:11 UTC
As Jessica mentioned in we are now checking in for the `auths` root field in both secret types (dockerconfigjson and dockercfg)

Comment 16 Xingxing Xia 2017-11-07 11:03:01 UTC
Verified in v3.7.0-0.196.0
username/password can be shown correctly, no matter which combination it is:
key .dockercfg + value "auths"
key .dockerconfigjson + value "auths"
key .dockercfg + value "$registryadress"

(In reply to Jakub Hadvig from comment #13)
> which basically is the format for the new docker/config.json file type. So
> you are mixing two different things.
Yes, mixing it intentionally because the mix is used by CLI `extract` output in so I report this bug.

(In reply to Jessica Forrester from comment #14)
> but the changes
> are too big for 3.7
Subscribing it and will verify it when available

Thank you all

Comment 17 Xingxing Xia 2017-11-09 07:52:59 UTC
Created attachment 1349805 [details]
DC page's Reveal Secret shows [object Object] for image secret

Hmm, today found minor inconsistency issue that may relate to this fix, so continue here. The issue has 2 parts
a) In _secret_ page, for most secrets, before clicking "Reveal Secret", _all_ keys' values are obfuscated, no matter whether the key is "password" or not.
But image secret is not consistent with this, NOT _all_ are obfuscated, i.e.:
$ oc secret new-basicauth --username user1 --password pass1 src-secret
$ oc secret new mulkey-secret data1=data1.txt data2=data2.txt
$ oc secret new-dockercfg --docker-username user1 --docker-password pass1 --docker-email=unused img-secret # old .dockercfg format image secret created from "Create Secret" page has same issue

For secrets mulkey-secret, src-secret, all keys' values are obfuscated, for image secret, only "password" is, but remaining values are not

2) In DC page's Environment tab, select a secret under "Environment From", click View Details --> Reveal Secret. The resulting display of image secret is inconsistent with most secrets, i.e.:
$ oc secret new longvalue-secret data=/home/xxia/.kube/config
For longvalue-secret, value is shown well, but for image secret, value is shown [object Object], see attachment

Sorry for bothering, please check, thank you

Comment 18 Jakub Hadvig 2017-11-09 14:01:43 UTC
I've can reproduce the bug in the DC's Environment tab.
On it will send the fix asap.

Comment 19 openshift-github-bot 2017-11-15 13:40:56 UTC
Commits pushed to master at
Bug 1506998 - DC's environment tab not showing image secrets properly
Merge pull request #2495 from jhadvig/BZ_1506998

Automatic merge from submit-queue.

Bug 1506998 - DC's environment tab not showing image secrets properly

Image secrets of `kubernetes/dockercfg` and `kubernetes/dockerconfigjson` havent been shown properly on the DC's environment tab.

![dc_page 1](

After fix:

@spadgett PTAL

Comment 20 Xingxing Xia 2017-11-16 08:18:46 UTC
Checked both latest v3.7.9 and v3.8.0-0.1.0 don't include the PR. Moving to MODIFIED for test when version includes it.
Due to the issue before comment 16 is fixed and the issue after comment 17 is  minor, lowering the severity

Comment 25 errata-xmlrpc 2017-11-28 22:20:01 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.