Encrypting PXC Traffic¶
Percona XtraDB Cluster supports encryption for all traffic involved in cluster operation.
Securing Client-Server Communication Traffic¶
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 my.cnf
configuration
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
For more information, see the relevant sections about SSL certificates in Galera Cluster Documentation. and MySQL Server Documentation.
Securing SST Traffic¶
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:
rsync
, mysqldump
, and xtrabackup
.
rsync¶
This SST method does not support encryption. Avoid using this method if you need to secure traffic between DONOR and JOINER nodes.
mysqldump¶
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 mysqldump
:
Ensure that the DONOR node is configured for SSL encryption (both
[mysqld]
and[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
wsrep_sst_auth
variable.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
[mysqld]
and[client]
sections).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.
xtrabackup¶
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 encrypt
option.
Depending on the mode you select, other options will be required:
encrypt=0
is the default value, meaning that encryption is disabled.encrypt=1
enables built-in XtraBackup encryption.Note
This mode has been deprecated.
[sst] encrypt=1 encrypt-algo=AES256 encrypt-key=A1EDC73815467C083B0869508406637E
In this example, you can set
encrypt-key-file
instead ofencrypt-key
.For more information, see Encrypted Backups.
encrypt=2
enables SST encryption based on OpenSSL with the certificate authority (tca
) and certificate (tcert
) files.Note
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=3
enables SST encryption based on OpenSSL with the key (tkey
) and certificate (tcert
) files.Note
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=4
enables SST encryption based on SSL files generated by MySQL.Note
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
ca.pem
,server-cert.pem
, andserver-key.pem
files.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.pem
files, but they will all share the sameca.pem
file.
Note
Whatever method you use to generate the certificate and key files, the
Common Name
value 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”
Note
SSL clients require DH parameters to be at least 1024 bits,
due to the logjam vulnearability
<https://en.wikipedia.org/wiki/Logjam_(computer_security)>.
However, versions of socat
earlier than 1.7.3 use 512-bit parameters.
If a 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
Securing IST Traffic, Write-Set Replication, and Service Messages¶
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 (gcomm
).
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 wsrep_provider_options
variable.
wsrep_provider_options="socket.ssl=yes;socket.ssl_key=/path/to/server-key.pem;socket.ssl_cert=/path/to/server-cert.pem;socket.ssl_ca=/path/to/cacert.pem"
For more information, see Index of wsrep provider options.
Note
You must use the same server key and certificate files on all nodes, preferably those used for Securing Client-Server Communication Traffic.
Upgrading Certificates¶
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_ca
that includes both the new and the old certificates in a single file.For example, you can merge contents of
old-ca.pem
andnew-ca.pem
intoupgrade-ca.pem
as follows:cat old-ca.pem > upgrade-ca.pem && cat new-ca.pem >> upgrade-ca.pem
Set the
wsrep_provider_options
variable similar to the following:wsrep_provider_options=socket.ssl=yes;socket.ssl_ca=/path/to/upgrade-ca.pem;socket.ssl_cert=path/to/old-cert.pem;socket.ssl_key=/path/to/old-key.pem
Restart Node 2 with the new
socket.ssl_ca
,socket.ssl_cert
, andsocket.ssl_key
.wsrep_provider_options=socket.ssl=yes;socket.ssl_ca=/path/to/upgrade-ca.pem;socket.ssl_cert=/path/to/new-cert.pem;socket.ssl_key=/path/to/new-key.pem
Restart Node 1 with the new
socket.ssl_ca
,socket.ssl_cert
, andsocket.ssl_key
.wsrep_provider_options=socket.ssl=yes;socket.ssl_ca=/path/to/upgrade-ca.pem;socket.ssl_cert=/path/to/new-cert.pem;socket.ssl_key=/path/to/new-key.pem
Contact Us
For free technical help, visit the Percona Community Forum.To report bugs or submit feature requests, open a JIRA ticket.
For paid support and managed or professional services, contact Percona Sales.