As we have mentioned in one of our previous blog posts, clone plugin is a nice addition to MySQL as it allows users to easily provision nodes with data while not even leaving MySQL CLI. In the previous blog we have explained how to provision a new node to join the MySQL replication cluster. We haven’t used SSL in that example, that’s why we are back to clone plugin and this time we would like to show how to set up the SSL for data in transit encryption. This is one of the reasons, and quite a good one, to use SSL. Another reason is that cloning will not work for encrypted tables unless the transfer is encrypted as well. This is because the data, while cloned, is unencrypted – it is decrypted on the donor, transferred over the network in a non-encrypted format and then encrypted again on the recipient. Without SSL protecting data in transit, whole encryption is compromised as data could have been sniffed while on the network.
How to run a clone process using SSL?
If we are talking only about executing the clone process, it is very straightforward. We have to set the donor list and then run the CLONE INSTANCE command using REQUIRE SSL:
MySQL localhost:3306 ssl SQL > SET GLOBAL clone_valid_donor_list='192.168.10.157:3306,192.168.10.158:3306,192.168.10.159:3306'; Query OK, 0 rows affected (0.0018 sec) MySQL localhost:3306 ssl SQL > CLONE INSTANCE FROM 'donor'@192.168.10.157:3306 IDENTIFIED BY 'somepass' REQUIRE SSL; Query OK, 0 rows affected (1 min 1.2289 sec)
If SSL is configured, it will work just fine. More interesting will be to see how we should set up both donor and receiver nodes to make sure that SSL is enabled and used.
How to configure MySQL SSL for the clone process?
The short version is that both donor and receiver should be configured to use SSL. Donor – server-side, for the receiver it should be configured as a client. After all, this is what it is. During the cloning process we connect as MySQL user (‘donor’ in our case) from receiver to donor instance. It is pretty much the same as if we would connect from an application to the donor node. The long version is below.
How to configure SSL on a donor node?
First of all, MySQL 8.0 comes with SSL enabled by default – encrypted connections from clients are accepted but not enforced. The rest that has to be done is to configure MySQL:
ssl_ca=ca.pem
ssl_cert=server-cert.pem
ssl_key=server-key.pem
Those entries should be added in the [mysqld] section and they should point to SSL certificates and keys. What is nice, if you do not have those keys, MySQL 8.0 will generate it for you. Quite handy for those, who do not care about using keys signed by CA, even though such keys allow for higher security by setting ssl-mode to VERIFY_CA or VERIFY_IDENTITY, when additional sanity checks are performed on top of encrypting the data to avoid attacks like man-in-the-middle.
You can also add the require_secure_transport directive and have it enabled. It will change the default behavior of allowing any kind of connection to allowing only SSL/TLS-enabled connections. Once the keys are ready, one way or the other, you can proceed to configure the receiver node.
How to configure SSL on a receiver node?
As per documentation, we should configure SSL client certificates and define them in the configuration file as:
clone_ssl_ca=/path/to/ca.pem
clone_ssl_cert=/path/to/client-cert.pem
clone_ssl_key=/path/to/client-key.pem
In the real setup we have found those not set up:
MySQL localhost:3306 ssl SQL > SHOW GLOBAL VARIABLES LIKE 'clone_ssl%'; +----------------+-------+ | Variable_name | Value | +----------------+-------+ | clone_ssl_ca | | | clone_ssl_cert | | | clone_ssl_key | | +----------------+-------+ 3 rows in set (0.0009 sec)
We still have been able to run the clone process with REQUIRE SSL in the command and require_secure_transport=ON on the donor just fine. To make sure it is indeed using encrypted connection we have used tcpdump to collect the data:
root@vagrant:~# tcpdump -i eth1 -w tcpdump.out port 3306 and host 192.168.10.157 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes ^C809486 packets captured 816021 packets received by filter 6535 packets dropped by kernel
Analysis of the tcpdump output clearly showed that the data is indeed encrypted. Still, we would recommend to stick to the documentation and prepare the clone_ssl_% configuration variables properly before attempting to send the data using clone plugin.
This is it for today’s very short blog post. We hope it was informative one and it will help at least some of you to secure your data while in transit during the clone process.
