Replication with Secure Connections
By default, MariaDB Replication transmits data unencrypted. Even if you secure MariaDB using TLS system variables as described in Securing Connections for Client and Server, the slaves continue to retrieve replication traffic from the master without encryption. While this may be acceptable when the nodes are running on a private network, it does pose certain security risks when they are running in different data centers and accessible from the public internet.
To secure replication data both master and slaves require secure connections to be enabled, (verify that the have_ssl
system variable returns YES
on each). In the event that either the master or the slave returns NO
or DISABLED
, they either default to unencrypted traffic or, (when REQUIRE
clause has been set for the replication user), the master enforces encryption and the connection fails.
Securing Replication
In order to secure replication, configure the TLS system variables on the master server as you would when securing a standalone instance of MariaDB. For more information on how this is done, see Securing Connections for Client and Server. In creating the replication users for the account, use REQUIRE
clauses to define the level of TLS authentication you want for master-slave replication traffic.
Once you have enabled and secured the master server, you can reconfigure the slaves to use TLS options in replication. There are two methods available to do this: reconfiguring replication on a running server with CHANGE MASTER
statement, or updating the configuration file.
Changing the Master
Using a CHANGE MASTER
statement, you can set or modify the various replication options on a running server. Relevant options are MASTER_SSL
, MASTER_SSL_CA
, MASTER_SSL_CAPATH
, MASTER_SSL_CERT
, MASTER_SSL_KEY
, MASTER_SSL_CRL
, MASTER_SSL_CRLPATH
and MASTER_SSL_CIPHER
. For more information on their meaning, see the MASTER_SSL_*
documentation.
In order to enable TLS replication options, you first need to stop the slave (in the event that replication is currently rerunning),
STOP SLAVE;
Then, issue a CHANGE MASTER
statement to configure replication to use TLS. For instance,
CHANGE MASTER TO MASTER_HOST='masterNode', MASTER_USER='replUser', MASTER_PASSWORD='replUserPasswrd', MASTER_SSL=1, MASTER_SSL_CA = '/path/to/ca/ca.pem', MASTER_SSL_CAPATH = '/path/to/ca/', MASTER_SSL_CERT = '/path/to/client-cert.pem', MASTER_SSL_KEY = '/path/to/client-key.pem';
Once you've changed the master, you can restart the slave.
START SLAVE;
The slave now uses TLS to secures its connections with the master.
Configuration
In cases where you don't mind restarting the server or are setting it up for the first time, you may find it more convenient to configure TLS options for replication through the my.cnf
configuration file. In order to do this, you first need to configure the replication client to use TLS. This involves setting the same TLS system variables you use to secure the server, but instead of the [mysqld]
unit, you set them on the [client]
unit.
[client] ssl_ca = ca.pem ssl_ca_path = /path/to/ca ssl_cert = client-cert.pem ssl_key = client-key.pem
With the appropriate client system variables set, stop the server. When you start it, use the --skip-slave-start
option. This prevents the slave from attempting to initiate replication before you've finished configuring it to secure its connections.
Once the server is back online, use the CHANGE MASTER
statement to configure the slave for replication. To enable TLS connections, use the MASTER_SSL
option in this statement.
CHANGE MASTER TO MASTER_HOST='masterNode', MASTER_USER='replUser', MASTER_PASSWORD='replUserPasswd', MASTER_SSL=1;
This statement configures the slave to connect to the given master server and to secure the connection using the TLS with the default certificates as defined in the configuration file. You can now start replication.
START SLAVE;