URL

https://docs.openshift.com/container-platform/4.14/logging/log_collection_forwarding/configuring-log-forwarding.html

SECTION

• Log collection and Forwarding > Configuring log forwarding > Supported Authorized Keys

• Log collection and Forwarding > Configuring log forwarding > Creating a Secret

•  Log collection and Forwarding > Configuring log forwarding > All examples where it's said: "The secret must exist in the openshift-logging project and have tls.crt, tls.key, and ca-bundle.crt keys that each point to the certificates they represent."

  DESCRIPTION

In OBSDOCS-100 was reported that:

"starting in RHOL 5.3 were relaxed the authorization Requirements for Log Forwarding implemented in LOG-1468.

Then, the phrases in the documentation as:

"If using a tls prefix, you must specify the name of the secret required by the endpoint for TLS communication. The secret must have keys of: `tls.crt`, `tls.key`, and `ca-bundle.crt` that point to the respective certificates that they represent"

are not more valid since now it's allowed to use for example only the `ca-bundle.crt` and not needed the `tls.crt`, `tls.key`"

The pull-request done in OBSDOCS-100 was not correct at all and it should be reverted and at the same time modify to reflect the "relaxed the Authorization Requirements for Log Forwarding".

Then, key word here is "relaxed", this means, it's not more mandatory or a "must", but it's possible to configure all the fields inside the secret and what fields are inside depends on the level of security the user/admin desires/needed.

Then, let's go by documentation sections:

Section: Log collection and Forwarding > Configuring log forwarding > Supported Authorized Keys

Revert the pull-request indicating that the ca-bundle.crt, tls.crt and tls.key are optional now and not mandatory (must). 

insecureSkipVerify

Starting in some Logging versions ago is possible to use `skipTLSVerification: true`, this is not documented already and documentation bug opened: OBSDOCS-773. I feel this should be documented also in this Section.

Section: Log collection and Forwarding > Configuring log forwarding > Creating a Secret

This is related to OBSDOCS-802 opened when I was not already aware of the change done in OBSDOCS-100.

Then, the fields in the example before the pull-request in OBSDOCS-100 were good with the exception that the secret must not have all the fields because of they can be present or not and the user/admin needs to indicate what fields must be inside of the secret:

oc create secret generic -n openshift-logging <secret_name> \
  --from-file=ca-bundle.crt=<your_bundle_file> \
  --from-file=tls.key=<your_tls_crt_file> \
  --from-file=tls.crt=<your_tls_key_file> \
  --from-literal=passphrase=<your_tls_key_file> \
  --from-literal=username=<your_username> \
  --from-literal=password=<your_password> 

As a second point, the secret can contain more fields as the `hecToken`:

oc -n openshift-logging create secret generic vector-splunk-secret --from-literal hecToken=<HEC_Token> 

If we are speaking about Authorization in this section, the hecToken is also missing here, even, when it's specific for Splunk.

As a third point, the sentence before the command to create the secret says:

 
You can create a secret in the directory that contains your certificate and key files by using the following command:

As it's currently, if it's not reverted the command before OBSDOCS-100, then, this phrase is wrong because it contains the CA, the username and password, but not the "certificate and key files". Exactly, it contains the opposite of the written.

Section: Log collection and Forwarding > Configuring log forwarding > All examples where it's said: "The secret must exist in the openshift-logging project and have tls.crt, tls.key, and ca-bundle.crt keys that each point to the certificates they represent."

Then, all the examples where it's said `must exist in the openshift-logging project and have tls.crt, tls.key, and ca-bundle.crt keys that each point to the certificates they represent.`, this phrase is wrong as said in OBSDOCS-100 because of as explained before, it depends on the grade of security that the user desires to implement.

The user could configure:

  + TLS with `skipTLSVerification: true`, then, not needed the secret

  + TLS with `skipTLSVerification: true` and secret containing hectoken

  + TLS  with `skipTLSVerification: true` and secret containing username + password

  + TLS with secret containing username + password + CA

  + TLS with secret containing username + password + CA `tls.key` and tls.crt`

  + TLS with secret containing username + password + CA `tls.key`, tls.crt` and passphrase

  + The latest 3 combinations before, but without username + password,

  + etc....