Encrypting Communications#

The ICE ClusterWare™ platform provides an internal cluster certificate authority that can provide signed certificates to secure communications between head nodes as well as between head nodes and compute nodes. If you prefer to provide your own certificates or certificate authority, Apache can be configured to use those certificates and compute nodes can verify those signatures during communications. Apache configuration files are located in /opt/scyld/clusterware/conf/httpd/. The Apache VirtualHost definition can be found in vhost.conf. The proxy definition in that file needs to be included into the HTTPS VirtualHost. For details about how to properly enable HTTPS on the Apache server, see the documentation provided by your distro.

Once HTTPS is enabled, the ~/.scyldcw/settings.ini file of any existing ClusterWare tool installation should be updated. In ~/.scyldcw/settings.ini, update the protocol of the client.base_url variable to use https. It should be safe to leave HTTP enabled for localhost-only access and, in that case, local tool installations can continue to use the original localhost-based URL.

The internal cluster certificate authority is implemented using a certificate stored in the backend database, accessible to all head nodes, and can be used to sign certificates used by assorted services on the head node by executing:

/opt/scyld/clusterware/bin/generate_head_certs

The scyld-install script runs this command during installation or updates to generate separate certificates for supported services on the head node. The keys and certificates are stored in /opt/scyld/clusterware/ca_certs/ along with the CA public key.

Communication between devices in your cluster happens with different levels of encryption and authentication. The following diagram illustrates the use of TLS in communications involving head and compute nodes with all possible configurations:

Two compute nodes and two head nodes with etcd are arranged in a square. The head nodes are connected with an arrow labeled 3. The compute nodes are connected with an arrow labeled 1. The two etcd are connected with an arrow labeled 1. Head and compute nodes are connected with arrows labeled 2.

  1. TLS off - not encrypted

    • Between compute nodes: Communication between compute nodes while chain booting is not encrypted; however, the compute nodes do confirm the size and checksum of the received files based on information from the head node.

    • Between etcd on head nodes: Communication between etcd on one head node and etcd on another head node is not encrypted or authenticated. All communication between etcd should occur on a secure network.

  2. TLS on - encrypted, but not authenticated by default

  3. TLS on - encrypted and authenticated

    Between head nodes: All backend communication between head nodes is encrypted and authenticated.

Configure Encrypted Communication between Head and PXE Compute Nodes#

By default, communication between ClusterWare head and PXE compute nodes is encrypted using SSL/TLS. Leaving this on is highly recommended for security. If necessary, you can turn off SSL/TLS by setting head.prefer_ssl = False in the /opt/scyld/clusterware/conf/base.ini file on the head node(s). When this is enabled, compute nodes send node status information back to the ClusterWare platform over HTTPS, but do not authenticate the head node.

Configure Encrypted Communication between Head and Diskful Compute Nodes#

To enable TLS encryption for diskful compute nodes, modify the base_url in /etc/clusterware/node.sh to use HTTPS. The sslverify option in the same file defaults to "no", but if the cluster CA certificate is installed on the diskful node, setting sslverify=yes in node.sh enables host authentication.

See Installing the clusterware-node Package for details about the node.sh file.

Configure Client Authentication between Head and Compute Nodes#

To enable encryption with client authentication, enable one-time Certificate Signing Requests (CSR) for specific nodes using the following command:

scyld-clusterctl certs enable -i <nodes>

where <nodes> is a comma-separated list of node IDs.

Reboot all specified nodes after running the command.

This functionality requires a TPM on each compute node because the compute nodes create a private key in their TPM on boot and use it to sign a CSR. The CSR is sent to the head node. If CSR signing is enabled for a specific node, the head node responds with a signed client certificate. The node stores the signed client certificate in non-volatile TPM storage.

If the client finds a client certificate in its TPM on the same or subsequent boots, it uses that certificate and the private key in the TPM to authenticate itself to the server. Successful authentication to the server results in an encrypted TLS connection with client authentication.

Note that future releases will allow encryption with host authentication by automating the process of adding the cluster CA certificate to compute nodes booting via UEFI.