Bug 1969849

@anli @kbharti Can one of you please confirm that this is true not only for IBM Z (s390x) but also for x86? 

If yes I will add to the callout (6) text: The secret must be of type opaque or generic.

That is a generic issue, One example to create secret:
oc create secret -n openshift-logging generic es-forward-secret --from-file=tls.key=ca-for-es/logging-es.key --from-file=tls.crt=ca-for-es/logging-es.crt --from-file=ca-bundle.crt=ca-for-es/ca.crt --from-file=ca.key=ca-for-es/ca.key

Created a PR to update the docs: https://github.com/openshift/openshift-docs/pull/35372

I'm closing my PR35372 this issue will be handled in this PR: https://github.com/openshift/openshift-docs/pull/35445/files#diff-5d0fb5b037436663f79140c18a2886bbd555df4f8960091b273e0cf7842e5556

I've discussed with @rdlugyhe to include this update in his cluster logging PR here: 
https://github.com/openshift/openshift-docs/pull/35445/files#r691574276
Adding the procedure to create a secret for username/password doesn't solve the issue since he is creating the secret for TLS certificates. 


@nishantchauhan.com wrote me that he gets an error when not specifying generic see: 
 

This is how I create the secret, and if I do not specify the "generic" parameter it fails [I have shown this in below steps].
At Cluster Logging PR they are creating secret for "username/password" , and I am creating secret for "tls certificates".
[root@t8375029 ~]# oc version
Client Version: 4.9.0-0.nightly-s390x-2021-08-06-063914
Server Version: 4.9.0-0.nightly-s390x-2021-08-18-165339
Kubernetes Version: v1.22.0-rc.0+f967870
[root@t8375029 ~]#
[root@t8375029 tls]# ll
total 60
-rw-r--r--. 1 root root 4490 Jul 27 08:13 bundle.pem
-rw-r--r--. 1 root root 1452 Jul 27 08:13 ca.crt
-rw-------. 1 root root 1704 Jul 27 08:13 ca.key
-rw-r--r--. 1 root root 3156 Jul 27 08:13 ca.pem
-rw-r--r--. 1 root root   41 Jul 27 08:13 ca.srl
-rw-r--r--. 1 root root 1334 Jul 27 08:13 client.crt
-rw-r--r--. 1 root root 1062 Jul 27 08:13 client.csr
-rw-------. 1 root root 1708 Jul 27 08:13 client.key
-rw-r--r--. 1 root root 3042 Jul 27 08:13 client.pem
-rwxr-xr-x. 1 root root 1113 Jul 27 08:13 gen.sh
-rw-r--r--. 1 root root 1334 Jul 27 08:13 server.crt
-rw-r--r--. 1 root root 1062 Jul 27 08:13 server.csr
-rw-------. 1 root root 1704 Jul 27 08:13 server.key
-rw-r--r--. 1 root root 3038 Jul 27 08:13 server.pem
[root@t8375029 tls]# oc create secret tls-rs --from-file=tls.crt=client.crt --from-file=tls.key=client.key --from-file=ca-bundle.crt=bundle.pem
Error: unknown flag: --from-file
See 'oc create secret --help' for usage.
[root@t8375029 tls]# oc create secret generic tls-rs --from-file=tls.crt=client.crt --from-file=tls.key=client.key --from-file=ca-bundle.crt=bundle.pem
secret/tls-rs created
[root@t8375029 tls]# oc describe secret tls-rs
Name:         tls-rs
Namespace:    openshift-logging
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
tls.crt:        1334 bytes
tls.key:        1708 bytes
ca-bundle.crt:  4490 bytes
[root@t8375029 tls]#



@anli @kbharti  Is this behaviour known and should be documented or is it a bug? 
If it needs to be documented do we need an extra procedure how to create the secret for TLS certificates?

Tracking this issue with https://issues.redhat.com/browse/RHDEVDOCS-3252

I suggest update the content as follows
For an `https` prefix, if your external server are using custom authorization or You want to using Mutual Transport Layer Security (mTLS). You need to specify the name of the secret required by the endpoint for TLS communication. The secret must exist in the `openshift-logging` project.  It may include keys of: *tls.crt*, *tls.key*, and *ca-bundle.crt* that point to the respective certificates that they represent.

Otherwise, for `http` and `https` prefixes, you can specify a secret that contains a username and password. For more information, see the following "Example: Setting secret that contains a username and password."

Close as prefer to https://issues.redhat.com/browse/RHDEVDOCS-3252