このコンテンツは選択した言語では利用できません。
Chapter 22. 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 betweenglusterdand 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.cafile 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.cafile 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.pemfiles 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 betweenglusterdof all servers and the connection between clients, and contains any configuration required by the Certificate Authority. Theglusterdservice 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.
22.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 22.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
# openssl genrsa -out /etc/ssl/glusterfs.key 2048
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
Generate client-side certificate authority lists
From the first server, concatenate the/etc/ssl/glusterfs.pemfiles from all servers into a single file calledglusterfs.ca, and place this file in the/etc/ssldirectory on all clients.For example, running the following commands fromserver1creates a certificate authority list (.cafile) that contains the certificates (.pemfiles) of two servers, and copies the certificate authority list (.cafile) 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
Generate server-side
glusterfs.cafilesFrom the first server, append the certificates (/etc/ssl/glusterfs.pemfiles) from all clients to the end of the certificate authority list (/etc/ssl/glusterfs.cafile) generated in the previous step.For example, running the following commands fromserver1appends the certificates (.pemfiles) of three clients to the certificate authority list (.cafile) onserver1, and then copies that certificate authority list (.cafile) 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
Verify server certificates
Run the following command in the/etc/ssldirectory 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 isglusterfs.pem: OK.Note
This process does not work for self-signed client certificates.
Procedure 22.2. Preparing a Common Certificate Authority certificate
Perform the following steps on each server and client you wish to authorize.
Generate a private key
# openssl genrsa -out /etc/ssl/glusterfs.key 2048
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
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.pemfile, and the certificates of the Certificate Authority in the form of a.cafile.Place the
.pemfile provided by the Certificate AuthorityEnsure that the.pemfile is calledglusterfs.pem. Place this file in the/etc/ssldirectory of this server only.Place the
.cafile provided by the Certificate AuthorityEnsure that the.cafile is calledglusterfs.ca. Place the.cafile in the/etc/ssldirectory of all servers.Verify your certificates
Run the following command in the/etc/ssldirectory 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 isglusterfs.pem: OK.
