20.6. Authorizing a New Client

Procedure 20.10. Authorizing a new client using a CA-signed certificate

1. Generate a key for the client

   Run the following command on the client.

   # 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 Certificate Authority list in the form of a .ca file.

4. Add provided certificate file on the client

   Place the .pem file provided by the Certificate Authority in the /etc/ssl directory on the client. Ensure that the .pem file is called glusterfs.pem.

5. Add the Certificate Authority list to the client

   Copy the /etc/ssl/glusterfs.ca file from an existing client to your new client.

   # scp existingclient/etc/ssl/glusterfs.ca newclient:/etc/ssl/glusterfs.ca

6. Verify your certificate

   Run the following command in the /etc/ssl directory 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.

7. Configure management encryption, if used

   On the client, create the /var/lib/glusterd directory, and create a new /var/lib/glusterd/secure-access file. This file can be empty if you are using the default settings.

   # touch /var/lib/glusterd/secure-access

   Your Certificate Authority may require changes to the SSL certificate depth setting, transport.socket.ssl-cert-depth, in order to work correctly. To edit this setting, add the following line to the secure-access file, replacing n with the certificate depth required by your Certificate Authority.

   echo "option transport.socket.ssl-cert-depth n" > /var/lib/glusterd/secure-access

8. Update the list of servers and clients to allow

   Run the following command from any server to specify the common names of servers and clients that are allowed to access the volume. The common names provided must be exactly the same as the common name specified when you created the glusterfs.pem file for that server or client.

   # gluster volume set volname auth.ssl-allow 'server1,server2,client1,client2,client3'

   Note

   The gluster volume set command does not append to existing values of the options. To append the new name to the list, get the existing list using gluster volume info command, append the new name to the list and set the option again using gluster volume set command.
   You can also use the default value of *, which indicates that any TLS authenticated machine can mount and access the volume.

9. Start the volume

   # gluster volume start volname

10. Verify

    Verify that the volume can be mounted from the new client. The process for mounting a volume depends on the protocol your client is using.
    The following command mounts a volume using the native FUSE protocol. Ensure that this command works on authorized clients, and does not work on unauthorized clients.

    # mount -t glusterfs server1:testvolume /mnt/glusterfs

Procedure 20.11. Authorizing a new client using a self-signed certificate

1. Generate a key for the client

   Run the following command on the client.

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

2. Generate a self-signed certificate for the client

   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

3. Add the Certificate Authority list to the client

   Copy the /etc/ssl/glusterfs.ca file from an existing client to your new client. Run the following command from the new client.

   # scp existingclient:/etc/ssl/glusterfs.ca /etc/ssl/glusterfs.ca

4. Generate new server glusterfs.ca files

   On any server, append the value of the new client's /etc/ssl/glusterfs.pem file to the end of the server's /etc/ssl/glusterfs.ca file.
   Place the updated /etc/ssl/glusterfs.ca file in the /etc/ssl directory of all servers in the trusted storage pool.
   For example, running the following commands on any server updates the glusterfs.ca file with the .pem file from the new client, and then copies that glusterfs.ca file to all servers.

   # ssh user@newclient cat /etc/ssl/glusterfs.pem >> /etc/ssl/glusterfs.ca
   # scp /etc/ssl/glusterfs.ca server1:/etc/ssl/glusterfs.ca
   # scp /etc/ssl/glusterfs.ca server2:/etc/ssl/glusterfs.ca

5. Configure management encryption on the new client, if used

   On the client, create the /var/lib/glusterd directory, and create a new /var/lib/glusterd/secure-access file. This file can be empty if you are using the default settings.

   # touch /var/lib/glusterd/secure-access

   Your Certificate Authority may require changes to the SSL certificate depth setting, transport.socket.ssl-cert-depth, in order to work correctly. To edit this setting, add the following line to the secure-access file, replacing n with the certificate depth required by your Certificate Authority.

   echo "option transport.socket.ssl-cert-depth n" > /var/lib/glusterd/secure-access

6. Update the list of servers and clients to allow

   Run the following command from any server to specify the common names of servers and clients that are allowed to access the volume. The common names provided must be exactly the same as the common name specified when you created the glusterfs.pem file for that server or client.

   # gluster volume set volname auth.ssl-allow 'server1,server2,client1,client2,client3'

   Note

   The gluster volume set command does not append to existing values of the options. To append the new name to the list, get the existing list using gluster volume info command, append the new name to the list and set the option again using gluster volume set command.
   You can also use the default value of *, which indicates that any TLS authenticated machine can mount and access the volume.

7. Start the volume

   Run the following command from any server to start the volume.

   # gluster volume start volname

8. If management encryption is used, restart glusterd on all servers

   For Red Hat Enterprise Linux 7 based installations:

   # systemctl start glusterd

   For Red Hat Enterprise Linux 6 based installations:

   # service glusterd start

   Important

   Red Hat Gluster Storage is not supported on Red Hat Enterprise Linux 6 (RHEL 6) from 3.5 Batch Update 1 onwards. See Version Details table in section Red Hat Gluster Storage Software Components and Versions of the Installation Guide

9. Verify

   Verify that the volume can be mounted from the new client. The process for mounting a volume depends on the protocol your client is using.
   The following command mounts a volume using the native FUSE protocol. Ensure that this command works on authorized clients, and does not work on unauthorized clients.

   # mount -t glusterfs server1:testvolume /mnt/glusterfs