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): v3.7.0-0.181.0 How reproducible: Always Steps to Reproduce: 1. $ cat .dockercfg # fake password "balabala" {"auths":{"registry.connect.redhat.com":{"auth":"ZGV2ZWxvcGVyQGV4YW1wbGUuY29tOmJhbGFiYWxh"}}} 2. Create secret with the same file $ oc secrets new mydockercfg .dockercfg secret/mydockercfg $ oc secrets new mydockerconfigjson .dockerconfigjson=.dockercfg secret/mydockerconfigjson 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:
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": "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": "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.
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: - kubernetes.io/dockerconfigjson - kubernetes.io/dockercfg - opaque
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` https://github.com/openshift/origin/pull/16868/files We should only be storing the new kind of docker config now.
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`.
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)? 1. https://github.com/openshift/origin/blob/master/pkg/oc/cli/secrets/new.go#L265
@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: https://github.com/openshift/origin-web-console/pull/2392
@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.
The console fix in https://github.com/openshift/origin-web-console/pull/2392 is the only fix necessary.
Per https://url.corp.redhat.com/559353b (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
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": "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: {"auths":{"registry.connect.redhat.com":{"auth":"ZGV2ZWxvcGVyQGV4YW1wbGUuY29tOmJhbGFiYWxh"}}} 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 https://bugzilla.redhat.com/show_bug.cgi?id=1476330#c11 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.
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 https://bugzilla.redhat.com/show_bug.cgi?id=1476330#c11 , then click Create. Check the secret, it uses old ".dockercfg" as key and no "auths" in value, similar to https://bugzilla.redhat.com/show_bug.cgi?id=1476330#c0 . I'm afraid the secret created from web console will still reproduce that issue "not compatible with registry.connect...". Now that CLI https://bugzilla.redhat.com/show_bug.cgi?id=1476330#c11 fixed it, web console seems to need fix it too?
So what you are describing is that you create .dockercfg, which is an old configuration file format with content: { "auths":{ "registry.connect.redhat.com":{ "auth":"ZGV2ZWxvcGVyQGV4YW1wbGUuY29tOmJhbGFiYWxh" } } } which basically is the format for the new docker/config.json file type. So you are mixing two different things. Please check https://bugzilla.redhat.com/show_bug.cgi?id=1506998#c1 where I described the format diffs
We've fixed what we can for 3.7 in https://github.com/openshift/origin-web-console/pull/2463 Remaining concern around changing the default type we create in the web console is being discussed in https://github.com/openshift/origin-web-console/pull/2464 but the changes are too big for 3.7
As Jessica mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1506998#c14 we are now checking in for the `auths` root field in both secret types (dockerconfigjson and dockercfg)
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 https://bugzilla.redhat.com/show_bug.cgi?id=1476330#c11 so I report this bug. (In reply to Jessica Forrester from comment #14) > https://github.com/openshift/origin-web-console/pull/2464 but the changes > are too big for 3.7 Subscribing it and will verify it when available Thank you all
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-server=registry.abc.com --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
I've can reproduce the bug in the DC's Environment tab. On it will send the fix asap.
Commits pushed to master at https://github.com/openshift/origin-web-console https://github.com/openshift/origin-web-console/commit/467905c3ca07781360f373ac153b991d0df8aef5 Bug 1506998 - DC's environment tab not showing image secrets properly https://github.com/openshift/origin-web-console/commit/e006275a8309b554a7b21c9e6d83f36e8b24702a 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. Screen:  After fix:  @spadgett PTAL
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
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/RHSA-2017:3188