Chapter 20. Configuring Network Encryption in Red Hat Gluster Storage Network encryption is the process of converting data into a cryptic format or code so that it can be securely transmitted on a network. Encryption prevents unauthorized use of the data. Red Hat Gluster Storage supports network encryption using TLS/SSL. When network encryption is enabled, Red Hat Gluster Storage uses TLS/SSL for authentication and authorization, in place of the authentication framework that is used for non-encrypted connections. The following types of encryption are supported: I/O encryption Encryption of the I/O connections between the Red Hat Gluster Storage clients and servers. Management encryption Encryption of management ( glusterd ) connections within a trusted storage pool, and between glusterd and NFS Ganesha or SMB clients. Network encryption is configured in the following files: /etc/ssl/glusterfs.pem Certificate file containing the system's uniquely signed TLS certificate. This file is unique for each system and must not be shared with others. /etc/ssl/glusterfs.key This file contains the system's unique private key. This file must not be shared with others. /etc/ssl/glusterfs.ca This file contains the certificates of the Certificate Authorities (CA) who have signed the certificates. The glusterfs.ca file must be identical on all servers in the trusted pool, and must contain the certificates of the signing CA for all servers and all clients. All clients should also have a .ca file that contains the certificates of the signing CA for all the servers. Red Hat Gluster Storage does not use the global CA certificates that come with the system, so you need to either create your own self-signed certificates, or create certificates and have them signed by a Certificate Authority. If you are using self-signed certificates, the CA file for the servers is a concatenation of the relevant .pem files of every server and every client. The client CA file is a concatenation of the certificate files of every server. /var/lib/glusterd/secure-access This file is required for management encryption. It enables encryption on the management ( glusterd ) connections between glusterd of all servers and the connection between clients, and contains any configuration required by the Certificate Authority. The glusterd service of all servers uses this file to fetch volfiles and notify the clients with the volfile changes. This file must be present on all servers and all clients for management encryption to work correctly. It can be empty, but most configurations require at least one line to set the certificate depth ( transport.socket.ssl-cert-depth ) required by the Certificate Authority. 20.1. Preparing Certificates To configure network encryption, each server and client needs a signed certificate and a private key. There are two options for certificates. Self-signed certificate Generating and signing the certificate yourself. Certificate Authority (CA) signed certificate Generating the certificate and then requesting that a Certificate Authority sign it. Both of these options ensure that data transmitted over the network cannot be accessed by a third party, but certificates signed by a Certificate Authority imply an added level of trust and verification to a customer using your storage. Procedure 20.1. Preparing a self-signed certificate Generate and sign certificates for each server and client Perform the following steps on each server and client. Generate a private key for this machine Generate a self-signed certificate for this machine The following command generates a signed certificate that expires in 365 days, instead of the default 30 days. Provide a short name for this machine in place of COMMONNAME . This is generally a hostname, FQDN, or IP address. Generate client-side certificate authority lists From the first server, concatenate the /etc/ssl/glusterfs.pem files from all servers into a single file called glusterfs.ca , and place this file in the /etc/ssl directory on all clients. For example, running the following commands from server1 creates a certificate authority list ( .ca file) that contains the certificates ( .pem files) of two servers, and copies the certificate authority list ( .ca file) to three clients. Generate server-side glusterfs.ca files From the first server, append the certificates ( /etc/ssl/glusterfs.pem files) from all clients to the end of the certificate authority list ( /etc/ssl/glusterfs.ca file) generated in the step. For example, running the following commands from server1 appends the certificates ( .pem files) of three clients to the certificate authority list ( .ca file) on server1 , and then copies that certificate authority list ( .ca file) to one other server. Verify server certificates Run the following command in the /etc/ssl directory on the servers to verify the certificate on that machine against the Certificate Authority list. Your certificate is correct if the output of this command is glusterfs.pem: OK . Note This process does not work for self-signed client certificates. Procedure 20.2. Preparing a Common Certificate Authority certificate Perform the following steps on each server and client you wish to authorize. Generate a private key Generate a certificate signing request The following command generates a certificate signing request for a certificate that expires in 365 days, instead of the default 30 days. Provide a short name for this machine in place of COMMONNAME . This is generally a hostname, FQDN, or IP address. Send the generated glusterfs.csr file to your Certificate Authority Your Certificate Authority provides a signed certificate for this machine in the form of a .pem file, and the certificates of the Certificate Authority in the form of a .ca file. Place the .pem file provided by the Certificate Authority Ensure that the .pem file is called glusterfs.pem . Place this file in the /etc/ssl directory of this server only. Place the .ca file provided by the Certificate Authority Ensure that the .ca file is called glusterfs.ca . Place the .ca file in the /etc/ssl directory of all servers. Verify your certificates Run the following command in the /etc/ssl directory on all clients and servers to verify the certificate on that machine against the Certificate Authority list. Your certificate is correct if the output of this command is glusterfs.pem: OK .

Commands:
openssl genrsa -out /etc/ssl/glusterfs.key 2048
openssl req -new -x509 -key /etc/ssl/glusterfs.key -subj "/CN= COMMONNAME " -days 365 -out /etc/ssl/glusterfs.pem
cat /etc/ssl/glusterfs.pem > /etc/ssl/glusterfs.ca ssh user@server2 cat /etc/ssl/glusterfs.pem >> /etc/ssl/glusterfs.ca scp /etc/ssl/glusterfs.ca client1:/etc/ssl/glusterfs.ca scp /etc/ssl/glusterfs.ca client2:/etc/ssl/glusterfs.ca scp /etc/ssl/glusterfs.ca client3:/etc/ssl/glusterfs.ca
ssh user@client1 cat /etc/ssl/glusterfs.pem >> /etc/ssl/glusterfs.ca ssh user@client2 cat /etc/ssl/glusterfs.pem >> /etc/ssl/glusterfs.ca ssh user@client3 cat /etc/ssl/glusterfs.pem >> /etc/ssl/glusterfs.ca scp /etc/ssl/glusterfs.ca server2:/etc/ssl/glusterfs.ca
openssl verify -verbose -CAfile glusterfs.ca glusterfs.pem
openssl genrsa -out /etc/ssl/glusterfs.key 2048
openssl req -new -sha256 -key /etc/ssl/glusterfs.key -subj '/CN=<COMMONNAME>' -days 365 -out glusterfs.csr
openssl verify -verbose -CAfile glusterfs.ca glusterfs.pem