Encrypting PXC Traffic¶
Percona XtraDB Cluster supports encryption for all traffic involved in cluster operation.
This refers to communication between client applications and cluster nodes. To secure client connections, you need to generate and use SSL keys and certificates.
The following example shows
for server nodes and client instances to use SSL:
[mysqld] ssl-ca=ca.pem ssl-cert=server-cert.pem ssl-key=server-key.pem [client] ssl-ca=ca.pem ssl-cert=client-cert.pem ssl-key=client-key.pem
This refers to full data transfer that usually occurs when a new node (JOINER) joins the cluster and receives data from an existing node (DONOR).
For more information, see State Snapshot Transfer.
The following SST methods are available:
This SST method does not support encryption. Avoid using this method if you need to secure traffic between DONOR and JOINER nodes.
This SST method dumps data from DONOR and imports it to JOINER. Encryption in this case is performed using the SSL certificates configured for secure MySQL client-server communication.
Here is how to perform secure SST using
Ensure that the DONOR node is configured for SSL encryption (both
[client]sections). For more information, see Securing Client-Server Communication Traffic.
Create an SSL user on the DONOR node.
mysql> GRANT USAGE ON *.* TO 'sslsst' REQUIRE SSL;
Specify the DONOR superuser credentials in the
Start the JOINER node without Galera library (
--wsrep_provider=none) and create an SSL user with the same name and grants as on the DONOR node.
Configure SSL encryption on JOINER node with the same parameters as DONOR (both
Restart JOINER node with Galera library.
If you do everything correctly,
mysqldump will connect to DONOR using SSL user,
generate a dump file, and import it to JOINER node.
For more information, see the relevant section in Galera Cluster documentation.
This is the default SST method. It uses Percona XtraBackup to perform non-blocking transfer of files. For more information, see Percona XtraBackup SST Configuration.
Encryption mode for this method is selected using the
Depending on the mode you select, other options will be required:
encrypt=0is the default value, meaning that encryption is disabled.
encrypt=1enables built-in XtraBackup encryption.
This mode has been deprecated.
[sst] encrypt=1 encrypt-algo=AES256 encrypt-key=A1EDC73815467C083B0869508406637E
In this example, you can set
For more information, see Encrypted Backups.
encrypt=2enables SST encryption based on OpenSSL with the certificate authority (
tca) and certificate (
This mode has been deprecated.
[sst] encrypt=2 tcert=/path/to/server.pem tca=/path/to/server.crt
For more information, see Securing Traffic Between two Socat Instances Using SSL <http://www.dest-unreach.org/socat/doc/socat-openssltunnel.html>.
encrypt=3enables SST encryption based on OpenSSL with the key (
tkey) and certificate (
This mode has been deprecated.
[sst] encrypt=3 tcert=/path/to/server.pem tkey=/path/to/server.key
Certificate verification is not performed in this mode, meaning that the validity of the joining nodes is not checked.
encrypt=4enables SST encryption based on SSL files generated by MySQL.
This is the recommended mode.
[sst] encrypt=4 ssl-ca=ca.pem ssl-cert=server-cert.pem ssl-key=server-key.pem
For more information, see http://dev.mysql.com/doc/refman/5.6/en/creating-ssl-files-using-openssl.html
The following procedure shows how to generate the
To generate the CA certificate:
openssl genrsa 2048 > ca-key.pem openssl req -new -x509 -nodes -days 3600 -key ca-key.pem -out ca.pem
To generate the server certificate, remove passphrase, and sign it:
openssl req -newkey rsa:2048 -days 3600 -nodes -keyout server-key.pem -out server-req.pem openssl rsa -in server-key.pem -out server-key.pem openssl x509 -req -in server-req.pem -days 3600 -CA ca.pem -CAkey ca-key.pem -set_serial -1 -out server-cert.pem
(Optional) To generate the client certificate, remove passphrase, and sign it:
openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem -out client-req.pem openssl rsa -in client-key.pem -out client-key.pem openssl x509 -req -in client-req.pem -days 3600 -CA ca.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem
There are two ways to deploy SSL files across the cluster:
- (Preferred) Use the same files for all machines in the configuration. Generate the files on one machine (or use the MySQL-generated files), and copy the files to each node in the cluster. Follow steps (1) and (2) in the previous procedure to manually generate the files.
- (Alternative) Generate one CA file with separate server certificates
signed by that one CA file.
Do step (1) to generate the CA file
and then do step (2) for each server using the same CA file.
So each server will have different
server-cert.pemfiles, but they will all share the same
Whatever method you use to generate the certificate and key files, the
Common Namevalue used for the server and client certificates/keys must each differ from that value used for the CA certificate. Otherwise, the certificate and key files will not work for servers compiled using OpenSSL.
The easiest way to do this is to give the CA file a common name (CN) as follows:
openssl req -new -x509 -nodes -days 3600 -key ca-key.pem -out ca.pem -subj “/CN=my_cluster_name”
SSL clients require DH parameters to be at least 1024 bits,
due to the logjam vulnearability
However, versions of
socat earlier than 1.7.3 use 512-bit parameters.
dhparams.pem file of required length is not found during SST
in the data directory,
it is generated with 2048 bits, which can take several minutes.
To avoid this delay, create the
dhparams.pem file manually
and place it in the data directory before joining the node to the cluster:
openssl dhparam -out dhparams.pem 2048
IST refers to transferring only missing transactions from DONOR to JOINER node. Write-set replication is the main workload in Percona XtraDB Cluster whenever a transaction is performed on one node, it is replicated to all other nodes. Service messages ensure that all nodes are synchronized.
All of this traffic is transferred via the same underlying communication
channel used by Galera (
Securing this channel will ensure that IST traffic, write-set replication,
and service messages are encypted.
To enable SSL for all internal node processes, define the paths to the key, certificate and certificate authority files using the following parameters:
To set these parameters, use the
For more information, see Index of wsrep provider options.
You must use the same server key and certificate files on all nodes, preferably those used for Securing Client-Server Communication Traffic.
The following example shows how to upgrade certificates used for securing IST traffic, write-set replication, and service messages, assumig there are two nodes in the cluster:
Restart Node 1 with a
socket.ssl_cathat includes both the new and the old certificates in a single file.
For example, you can merge contents of
cat old-ca.pem > upgrade-ca.pem && cat new-ca.pem >> upgrade-ca.pem
wsrep_provider_optionsvariable similar to the following:
Restart Node 2 with the new
Restart Node 1 with the new