Enabling a secured connection with a TLS enabled event source

This is only applicable when configuring the probe to connect as a client to a TLS enabled target server.

Pre-requisite

To connect to a TLS enabled target server, the probe requires a secret containing the TLS configuration to establish a secured connection. An Administrator needs to pre-create a secret that contains the target server's certificate and keystore password before installing the chart. The created secret must contain the following keys server.crt and keystorepassword.txt where the former key contains the server certificate and the latter key contains the keystore password.

  • Server certificate is the target server's TLS certificate usually is a X.509 PEM file. Make sure it is save in .crt extension. An example command to obtain the server certificate using Open SSL tool is shown below:
     export TARGET_HOST=target-server.host;
  export TARGET_PORT=443;
  openssl s_client \
  -connect $TARGET_HOST:$TARGET_PORT \
  -showcerts 2>/dev/null \
  | openssl x509 -outform PEM > server.crt
  • Keystore password is a text file that contains the password to be used as the probe's keystore password. The password will be encrypted using nco_aes_crypt tool during chart installation. A simple keystore password can be created by running:

    echo -n "password123" > keystorepassword.txt

Creating a secret for the probe

To create a secret for the probe, use the following steps:
  1. The administrator must import the server certificate and name it server.crt and then create a password using the name keystorepassword.txt.
    Note: The password will be encrypted during the installation process.
  2. To create a secret, use the command kubectl create secret tls <Secret Name> --from-file=server.crt --from-file=keystorepassword.txt. Substitute <Secret Name> in the command with the actual name, for example probe-client-secret.
    Note: The expected secret keys are server.crt and keystorepassword.txt, hence the files must have the correct names.

Configuring the probe to use the pre-created secret

To configure the probe to use the pre-created secret, use the following steps:

  1. When installing the chart, set the probe.sslSecretName parameter with value of the secret created in Creating a Secret For The Probe section (for example, probe-client-secret as used by the sample command above).
  2. Set the webhook.securityProtocol parameter to the server supported security protocol version, for example TLSv1.2, TLSv1.1 or TLSv1.

Troubleshooting a failed installation when Secured Mode is enabled

If the status of the pods remains in the pending state after the installation, this may indicate that installation might have failed and the probe is unable to start.

In this case,it is recommended to use the command line to troubleshoot the condition of the pods.

  1. To identify the pod names that belongs to the unhealthy release, use command kubectl get pods -l release==<release name>, where <release name> is the Helm release name. Alternatively using the UI, go to Menu > Workloads > Deployments and find the probe deployment which has the Ready and Available pod count less than the Desired and Current counts.
  2. If the pods are terminating or pending, run the following command:

    kubectl describe pod <pod name>

  3. Identify possible warning from the generated output. (Troubleshoot based on the output)
    • If the generated warning message looks similar to the example provided below, the pod cannot start due to the provided secret name does not exist in kubernetes environment.

      Warning FailedMount 45m (x8 over 46m) kubelet, MountVolume.SetUp failed for volume "tls-secret" : secrets "wrongsecret" not found

    • If the generated warning message looks similar to the example provided below, the pod cannot start due to the provided secret does not contain server.crt and/or keystorepassword.txt as key.

      Warning FailedMount 21s (x7 over 52s) kubelet, MountVolume.SetUp failed for volume "tls-secret" : references non-existent secret key

  4. For more information about the failed installation, check the init container's log by running the following command:

    kubectl logs <pod name> -c init-webhook

  5. To delete the unhealthy release, use the following command:

    helm del --purge <release name>

    If the pods are not successfully deleted, use the following command to forcefully delete them:

    kubectl delete pod <pod name> --force --grace-period=0