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

  1. Generate and sign certificates for each server and client

    Perform the following steps on each server and client.

    1. Generate a private key for this machine

      # openssl genrsa -out /etc/ssl/glusterfs.key 2048

    2. 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. 
      # openssl req -new -x509 -key /etc/ssl/glusterfs.key -subj "/CN=COMMONNAME" -days 365 -out /etc/ssl/glusterfs.pem

  2. 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. 
    # 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

  3. 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 previous 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. 
    # 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

  4. 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. 
    # openssl verify -verbose -CAfile glusterfs.ca glusterfs.pem
    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.

  1. Generate a private key

    # openssl genrsa -out /etc/ssl/glusterfs.key 2048

  2. 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. 
    # openssl req -new -sha256 -key /etc/ssl/glusterfs.key -subj '/CN=<COMMONNAME>' -days 365 -out glusterfs.csr

  3. 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.

  4. 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.

  5. 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.

  6. 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. 
    # openssl verify -verbose -CAfile glusterfs.ca glusterfs.pem
    Your certificate is correct if the output of this command is glusterfs.pem: OK.