Configuring TLS

Some network communication in BeeGFS now defaults to using TLS encryption, for example communication between the beegfs command-line utility and server services like Management or Remote. The recommended option to configure TLS is providing each server service a TLS certificate and private key it should use to encrypt network traffic. The following sections document different options to configure TLS depending on the options available in your environment.

Note

When the following sections refer to a “client” this is not referring to the BeeGFS client module, but rather tools like the beegfs command-line interface, or other services like BeeGFS Sync that need to establish connections to other server services. These tools and services may happen to be installed on a node that is also a BeeGFS client.

Using CA-Signed Certificates

Generating and using a certificate signed by a Certificate Authority for a server service

The process to generate certificates signed by a Certificate Authority (CA) depends on your organization and CA. By default servers expect a certificate and corresponding key to be present at the following paths:

tls-cert-file = /etc/beegfs/cert.pem
tls-key-file = /etc/beegfs/key.pem

These paths can be overridden by specifying the associated key in the command line flags or configuration file used to start the service.

Configuring clients to use certificates signed by a Certificate Authority

If your TLS certificate is already trusted by all machines in your organization, you do not need to distribute a certificate to each machine. Instead configure clients to use the system certificate pool by specifying tls-cert-file = "" in their command line flags or configuration file.

Using Self-Signed Certificates

Generating and using a Self-Signed Certificate for a server service

There are multiple ways to generate a self-signed certificate, here is one option using openssl:

  1. Install openssl using your distribution’s package manager or by downloading it directly.

  2. Create a san.cnf configuration file updating the [ alt_names ] section to include all DNS names and/or IPs where the server is accessible (no other changes are required).

    • For simple test cases where all services/clients are on the same machine the file below could be used without modification.

[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = req_ext
x509_extensions    = v3_ca # The extensions to add to the self signed cert

[ req_distinguished_name ]
commonName                  = Common Name (eg, fully qualified host name)
commonName_default          = localhost

[ req_ext ]
subjectAltName = @alt_names

[ v3_ca ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1   = localhost
IP.1    = 127.0.0.1

  1. Run the following command to generate the certificate and key, modifying the -days to reflect how long you wish the certificate to be valid for. Generally you will want these certificates to be valid for the life of the system, otherwise you will need to plan to regenerate them before they expire. Once these certificates expire, communication between some components will not be possible. Note updating TLS certificates will typically require restarting services to complete.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout key.pem -out cert.pem -config san.cnf

  1. Move the certificate and key files to the appropriate paths. By default servers expect a certificate and corresponding key to be present at the following paths:

tls-cert-file = /etc/beegfs/cert.pem
tls-key-file = /etc/beegfs/key.pem

These paths can be overridden by specifying the associated key in the command line flags or configuration file used to start the service.

Configuring clients to use a Self-Signed Certificate

By default clients expect a self-signed certificate to exist at /etc/beegfs/cert.pem. This path can be optionally overridden by specifying tls-cert-file=<path> in their command line flags or configuration file.

Alternatively you could disable TLS server verification by setting tls-disable-verification. While traffic is still encrypted this does not protect against man-in-the-middle attacks where a rogue server spoofs the identity of the actual server.

Disabling TLS

This is discouraged but can be done by setting tls-disable on all clients and servers. Keep in mind potentially sensitive information about the internal file system structure and configuration will be transmitted in clear text over the network, which might be a concern if gRPC traffic is being routed through a network that is not fully trusted.

Note because BeeGFS components may connect to multiple other components (for example BeeGFS Remote connects to the Management and Sync nodes), you may need to set tls-disable in multiple places for each component’s configuration. This makes it possible to disable TLS for some components and leave it enabled for others, providing flexibility in deploying the overall system.