Replication with Secure Connections

You are viewing an old version of this article. View the current version here.

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;

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.