Configuring Certificate Authority (CA) certificates

IBM Storage Scale container native uses Transport Layer Security (TLS) verification to guarantee secure HTTPS communication with the storage cluster GUI. It verifies the server's certificate chain and host name.

Configure a security protocol

A security protocol must be configured for use with IBM Storage Scale container native in one of three different ways.

Option 1 - CA certificate ConfigMap

A ConfigMap containing the CA certificate of the storage cluster GUI must be created to allow the IBM Storage Scale container native operator to perform TLS verification. CA certificate data can exist in base64 encoded or decoded forms.

In the following example, we create a ConfigMap from storage-cluster-1.crt file. This file contains the storage cluster CA certificate data in decoded form. The decoded form must appear as shown:

# cat storage-cluster-1.crt
-----BEGIN CERTIFICATE-----
MIIDZDC.........................................................
................................................................
...........n/J9OJFdoXs=
-----END CERTIFICATE-----

Create the ConfigMap with one of the following two commands. The second command is provided to assist the users who wish to trust the self-signed certificate of the storage cluster GUI.

kubectl create configmap cacert-storage-cluster-1 --from-file=storage-cluster-1.crt=storage-cluster-1.crt -n ibm-spectrum-scale

By default, the storage cluster GUI self-signs a certificate that can be used in lieu of a CA certificate. This certificate can be obtained and used to create the cacert ConfigMap by entering the following command. Replace the gui host with the hostname of the storage cluster GUI.

kubectl create configmap cacert-storage-cluster-1 --from-literal=storage-cluster-1.crt="$(openssl s_client -showcerts -connect <gui host>:443 </dev/null 2>/dev/null|openssl x509 -outform PEM)" -n ibm-spectrum-scale

Option 2 - Storage cluster uses the OpenShift Container Platform CA or a Red Hat default CA

IBM Storage Scale container native automatically includes the OpenShift Container Platform CA and the default Red Hat CA bundle for storage cluster GUI communication. If the storage cluster uses the OpenShift Container Platform CA or a Red Hat trusted CA, a ConfigMap, as described in Option 1, does not need to be created for the CA certificate and the cacert field should be deleted from the RemoteCluster Custom Resource. For more information, see RemoteClusters.

Option 3 - Skip verification

Storage cluster verification may be skipped if desired, however, TLS is susceptible to machine-in-the-middle attacks. To skip verification, the insecureSkipVerify option must be set to true, when configuring the RemoteCluster Custom Resource. For more information, see RemoteClusters.

Storage cluster verification

Events are posted onto the RemoteCluster resource if configuration is missing. For example, if secrets and ConfigMaps are missing, you may see events similar to the following sample:

$ kubectl describe remotecluster.scale remotecluster-sample
...
Events:
  Type     Reason           Age                From           Message
  ----     ------           ----               ----           -------
  Warning  RemoteConnError  6m3s               RemoteCluster  Secret "cnsa-remote-mount-storage-cluster-1" not found
  Warning  RemoteConnError  3s (x6 over 5m3s)  RemoteCluster  ConfigMap "cacert-storage-cluster-1" not found