3.2 Setting up Transport Layer Security (TLS)

The software described in this documentation is either no longer supported or is in extended support.
Oracle recommends that you upgrade to a current supported release.

3.2 Setting up Transport Layer Security (TLS)

Gluster supports Transport Layer Security (TLS) using the OpenSSL library to authenticate Gluster nodes and clients. TLS encrypts communication between nodes in the trusted storage pool, and between client systems accessing the pool nodes. This is achieved through the use of private keys and public certificates.

Gluster performs mutual authentication in all transactions. This means that if one side of a connection is configured to use TLS then the other side must use it as well. Every node must either have a copy of the public certificate of every other node in the pool, or it must have a copy of the signing CA certificate that it can use to validate the certificates presented by each of the nodes in the pool. Equally, client systems accessing any node in the pool must have a copy of that node's certificate or the signing CA certificate, and the node needs a copy of a certificate for the accessing client.

TLS is enabled as a setting on the Gluster volume and can also be enabled for management communication within the pool.

Configuring TLS for your Gluster deployment is optional but recommended for better security.

In production environments, it is recommended you use certificates that are properly signed by a Certificate Authority (CA). This improves validation security and also reduces the complexity of configuration. However, it is not always practical, particularly if you have numerous clients accessing the pool. This section describes configuration for environments where certificates are signed by a CA and for when certificates are self-signed.

To configure TLS on nodes in a Gluster pool:

Generate a private key on each node within the pool. You can do this using the openssl tool:
```
# openssl genrsa -out /etc/ssl/glusterfs.key 2048
```
Create either a self-signed certificate, or a certificate signing request (CSR) using the key that you have created.
To use self-signed certificates:
1. To create a self-signed certificate, do:
```
# openssl req -new -x509 -days 365 -key /etc/ssl/glusterfs.key -out /etc/ssl/glusterfs.pem
```
2. When you have generated a self-signed certificate on each node in the storage pool, concatenate the contents of each of these files into a single file. This file should be written to /etc/ssl/glusterfs.ca on each node in the pool. Each node uses this file to validate the certificates presented by other nodes or clients that connect to it. If the public certificate for another participatory node or client is not present in this file, the node is unable to verify certificates and the connections fail.
To use CA-signed certificates:
1. If you intend to get your certificate signed by a CA, create a CSR by running:
```
# openssl req -new -sha256 -key /etc/ssl/glusterfs.key -out /etc/ssl/glusterfs.csr
```
2. If you generated a CSR and obtained the signed certificate back from your CA, save this file to /etc/ssl/glusterfs.pem.
3. Save the CA certificate for your CA provider to /etc/ssl/glusterfs.ca on each node in the pool. Each node uses this file to validate the certificates presented by other nodes or clients that connect to it. If the public certificate for another participatory node or client cannot be verified by the CA signing certificate, attempts to connect by the client or node fail.
Configure TLS encryption for management traffic within the storage pool. To do this, create an empty file at /var/lib/glusterd/secure-access on each node in the pool. Do the same on any client system where you intend to mount a Gluster volume:
```
# touch /var/lib/glusterd/secure-access
```
Enable TLS on the I/O path for an existing Gluster volume by setting the client.ssl and server.ssl parameters for that volume. For example, to enable TLS on a volume named myvolume, do:
```
# gluster volume set myvolume client.ssl on
# gluster volume set myvolume server.ssl on
```
These parameters enable TLS validation and encryption on client traffic using the Gluster native client and on communications between nodes within the pool. Note that TLS is not automatically enabled on non-native file sharing protocols such as SMB by changing these settings.
Restart the glusterd service on each of the nodes where you have enabled secure access for management traffic within the pool for these changes to take effect.
```
# systemctl restart glusterd
```