Search the docs

Workflow Overview

Enabling TLS on an Existing Cluster

Use this workflow when enabling TLS on a Hammerspace cluster that is already configured with backend storage and clients.

This workflow is fully disruptive to normal platform operations. Schedule this procedure during a maintenance window. While the operation is in progress, the Hammerspace cluster, clients, and backend storage volumes will be offline for normal data operations.

Prepare the storage systems and clients before you enable TLS. When TLS is enabled, Hammerspace refuses NFS connections that do not use TLS and mounts every backend storage volume with TLS. A backend storage volume whose storage system cannot complete the mutual TLS handshake becomes unavailable, and client mounts that do not use TLS stop working.

  1. Prepare the backend storage systems. On each storage system that requires it, install the Hammerspace cluster root CA certificate, so that the storage system trusts Hammerspace. To download the certificate, go to Administration  TLS, select the Cluster Root CA tab, and click Download Certificate. Also obtain the root CA certificate that signed each storage system’s own certificate; you add it to Hammerspace in step 3. See Reference: Supported Third-Party Backend Storage.

  2. Prepare each Linux client. Make sure the client meets Reference: Client Requirements. Remount Clients gives the commands for each supported Linux distribution; do not remount the clients yet. On each client:

    • Install a client certificate and its private key. The certificate must be signed by a CA that Hammerspace will trust in step 3 (for example, your organization’s CA), or signed by the cluster itself with cert-csr-sign. See Manage Certificates and CAs.

    • Add the Hammerspace cluster root CA certificate to the client’s trust store.

    • Configure tlshd.

  3. Add the root CAs to Hammerspace. Add the root CA certificate of every CA that signed a client certificate or a storage system certificate. Hammerspace trusts a client because its certificate chains to a CA in the Hammerspace trust store; you do not upload individual client certificates.

    In the Enable TLS wizard, add root CA certificates on the Certificates tab. The wizard accepts root CA certificates only. To trust an intermediate CA, add it with the Admin CLI command cert-add --trust-intermediate-ca before you run the wizard, or include the intermediate certificate in each client’s certificate file. See Manage Certificates and CAs and Reference: Certificate Trust Model.

    Certificates that you add in the wizard are uploaded only when you click Enable TLS on its last tab. If you close the wizard before then, they are discarded. If you use the Management GUI, steps 3 and 4 are therefore one pass through the wizard.

  4. Enable TLS. Complete the Enable TLS wizard and click Enable TLS on its last tab (GFS), or run cluster-config --nfs-tls-required. See Enable TLS Using the Management GUI or Enable or Disable TLS.

  5. Remount each client. Unmount each Hammerspace share and mount it again with the xprtsec=mtls mount option. See Remount Clients.

If this cluster is part of a global file system (GFS), the wizard’s GFS tab recommends enabling TLS on every site in the GFS configuration: enable it on this cluster first, then on the remote sites.

Enabling TLS on a New Cluster (Recommended)

If you are deploying a new Hammerspace cluster that will use TLS from the start, complete setup in this order to minimize disruption:

  1. Install Hammerspace. Do not add third-party backing stores yet. See the Hammerspace 5.3 Installation and Licensing Guide.

  2. Enable TLS using the procedure in this document.

  3. Configure third-party backing stores and clients. See the Hammerspace 5.3 Configuration Guide.

  4. Add or assimilate data from the configured backing stores. See the Assimilation Overview.