MySQL has InnoDB data encryption, and Galera Cluster has supported it since it appeared in the main server. The one thing that was not covered was the encryption of the Galera Cache (the galera.cache file).
Here is a simple extract from the binlog.000001 files.
strings binlog.* |grep Custom |wc -l 10000 strings galera.cache |grep Custom |wc -l 10000
strings galera.cache|tail -10 Customer9100 Customer9099 Customer9098 Customer9097 Customer9096 Customer9095 Customer9094 Customer9093 Customer9092 Customer9091
You need to edit your /etc/my.cnf to include:
early-plugin-load=keyring_file.so keyring_file_data=/var/lib/mysql-keyring/keyring
Note that in this example we are using the keyring_file plugin, which stores keyring data in a file on the local server host. This is not intended for regulatory compliance. You need to use a key management server that protects encryption keys in key vaults or hardware security modules to be compliant with PCI/FIPS/etc. You can read more at: Using the keyring_file File-Based Keyring Plugin.
Once edited, restart the MySQL server.
You can turn on encryption via: SET GLOBAL default_table_encryption=ON; and then create a database as such: CREATE DATABASE encrypted DEFAULT ENCRYPTION='Y';
Now we repeat the input above into the encrypted table.
strings binlog.* |grep Custom |wc -l 20000 strings galera.cache |grep Custom |wc -l 20000
strings galera.cache|tail -10 Customer9100 Customer9099 Customer9098 Customer9097 Customer9096 Customer9095 Customer9094 Customer9093 Customer9092 Customer9091
And if we look carefully at the .ibd files, for the unencrypted we see:
strings new/customers.ibd |tail Customer9100 Customer9099 Customer9098 Customer9097 Customer9096 Customer9095 Customer9094 Customer9093 Customer9092 Customer9091
and for the encrypted we see:
strings encrypted/customers.ibd |tail <\Hn fYJp E*/FE :-hL 04<H8 Ulc7l Yz/$( 11:5 o:9C(v >3*i
But as you already know, the above data can be “leaked” via the gcache. Actually, as currently configured, it can also be leaked via the binlog, correct? This is why we turn on binary log encryption by adding the following to the my.cnf: binlog_encryption=on. Read more at: Encrypting Binary Log Files and Relay Log Files.
Once that is done and the server is restarted, here are some comparisons. This is before encryption:
strings binlog.000002 |tail Customer9100 Customer9099 Customer9098 Customer9097 Customer9096 Customer9095 Customer9094 Customer9093 Customer9092 Customer9091
This is after encryption:
strings binlog.000003 |tail 2@fL.WL& aM:m V1;Q >Qsb ajV- M`s&' 2dle anM4 p8d2 \8^7
Even-though the encryption for the binary log is turned on, sadly, the gcache is still visible. Never fear, as we have told you before how to do the Upgrading from Galera Cluster to Galera Cluster Enterprise Edition (EE). As mentioned, Galera Cluster Enterprise Edition (EE) has the ability for the Gcache to be encrypted at rest.
For posterity, we can now see it state, Server version: 8.0.32 Galera Cluster Enterprise for MySQL.
Now, if we look at the /var/lib/mysql directory, we’ll notice not only is the binlog encrypted, but also instead of just the galera.cache, you will also see files like gcache.page.000000 and so on.
Simple running of strings through it all:
strings galera.cache
Version: 2
GID: 3247c1e5-e028-11ed-aa04-ff3a3e20b974
synced: 0
0,10,5,3247c1e5-e028-11ed-aa04-ff3a3e20b974:1,1,-1,0,1
324702b5-e028-11ed-95d0-76a770401b68
gee2
AUTO
bO?/
8.0.32
ALTER USER 'root'@'localhost' IDENTIFIED BY 'MyNewPass1!'
0,10,5,3247c1e5-e028-11ed-aa04-ff3a3e20b974:2,-1,-1,0,0
strings gcache.page.000000
W#hE
2}vq
)Xx$A
}/[T
strings gcache.page.000001
XzP&
7&]
Low/8b:
!.[:4
?wt@5
u+6PR
#_N{
E]zjY
+l:J
!$E{o
G5gv
Ergo, no longer is anything visible in the data directory, and you now have successfully setup data encryption at rest with Galera Cluster Enterprise Edition (EE). Find out more by contacting your friendly Galera Cluster sales advisor, and happy keeping your data safe!