A GlusterFS volume that still accepts clear-text native traffic exposes file data and management handshakes to anyone who can observe the storage network. Enabling TLS makes clients, bricks, and the glusterd management path use certificate-backed connections instead of allowing mixed encrypted and unencrypted sessions.
GlusterFS reads its local identity from /etc/ssl/glusterfs.pem, /etc/ssl/glusterfs.key, and /etc/ssl/glusterfs.ca. The client.ssl and server.ssl volume options secure the native I/O path, while /var/lib/glusterd/secure-access controls TLS for management traffic used by peers and by clients when they fetch volume files during a mount.
Every server and native client must have trusted certificate material before the switch. GlusterFS rejects mixed TLS and non-TLS connections, so plan a maintenance window, keep clocks synchronized for certificate validation, restart affected daemons, and remount clients after the options are enabled. NFS and Samba exports backed by the volume need their own client-facing encryption controls.
Related: How to restrict GlusterFS client access
Related: How to improve GlusterFS security
$ sudo gluster volume list volume1
Replace volume1 with the volume that will require encrypted native client and brick traffic.
$ sudo ls -l /etc/ssl/glusterfs.pem /etc/ssl/glusterfs.key /etc/ssl/glusterfs.ca -rw-r--r-- 1 root root 1139 Jun 16 01:09 /etc/ssl/glusterfs.pem -rw------- 1 root root 1704 Jun 16 01:09 /etc/ssl/glusterfs.key -rw-r--r-- 1 root root 1139 Jun 16 01:09 /etc/ssl/glusterfs.ca
Keep /etc/ssl/glusterfs.key private to the local host. Anyone with the private key can claim that node or client identity.
$ sudo openssl verify -CAfile /etc/ssl/glusterfs.ca /etc/ssl/glusterfs.pem /etc/ssl/glusterfs.pem: OK
If the certificate uses an intermediate CA, set the matching certificate depth before rollout.
Tool: SSL Matcher (Certificate, CSR, and Key)
$ sudo openssl x509 -in /etc/ssl/glusterfs.pem -noout -subject -issuer -dates subject=CN=node1.gluster.local issuer=CN=GlusterFS Storage CA notBefore=Jun 16 00:00:00 2026 GMT notAfter=Jun 16 23:59:59 2027 GMT
Certificate verification fails when node or client clocks fall outside the certificate validity window.
$ sudo mkdir -p /var/lib/glusterd
$ sudo touch /var/lib/glusterd/secure-access
Keep any existing option transport.socket.ssl-cert-depth line in this file when the CA chain requires it.
$ sudo ls -l /var/lib/glusterd/secure-access -rw-r--r-- 1 root root 0 Jun 16 01:09 /var/lib/glusterd/secure-access
$ sudo systemctl restart glusterd
Restarting glusterd can interrupt peer operations and client reconnects while encrypted management connections are established.
$ sudo gluster volume set volume1 client.ssl on volume set: success
Clients without the correct /etc/ssl/glusterfs.* files can fail to mount or reconnect after this option is enabled.
$ sudo gluster volume set volume1 server.ssl on volume set: success
Existing non-TLS native connections are rejected after the encrypted path is enforced.
$ sudo gluster volume get volume1 client.ssl Option Value ------ ----- client.ssl on
$ sudo gluster volume get volume1 server.ssl Option Value ------ ----- server.ssl on
$ sudo mount -t glusterfs node1.gluster.local:/volume1 /mnt/volume1
Unmount and remount existing native clients during the same maintenance window so they fetch encrypted volume files and reconnect with the local certificate.
$ df -h /mnt/volume1 Filesystem Size Used Avail Use% Mounted on node1.gluster.local:/volume1 20G 8.0G 11G 43% /mnt/volume1