23.6. Authorizing a New Client

Follow this section to allow a new client to access a storage pool that uses network encryption.

23.6.1. Certificate Signed by a Common Certificate Authority

Follow this section to authorize a new client to access a trusted storage pool that uses network encryption signed by a common Certificate Authority.

Procedure 23.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

23.6.2. Self-signed Certificates

Prerequisites

  • Because self-signed certificates are not automatically generated and updated, the trusted storage pool must be offline for this process. Schedule an outage window for volumes, applications, clients, and other end users before beginning this process.
Follow this section to authorize a new client to access a trusted storage pool that uses network encryption with self-signed certificates.

Procedure 23.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
  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