Percona XtraDB Cluster for MySQL and encrypted Galera replication

Percona XtraDB Cluster for MySQL and encrypted Galera replication

PREVIOUS POST
NEXT POST

Few people realize that Galera/Percona XtraDB (PXC) replication can be encrypted via SSL for secure transfer of your replicated data.  Setting this up is actually quite easy to do and probably will look familiar to a lot of people.

Setting up SSL and Galera

Create and propagate a single key/cert pair

First, we create a private key/cert pair:

Note that we are creating a certificate with a very long expiration time. If you use the default expiration of 1 year, your cluster will fail on the first state change after the expiration date has past.

Note also that we currently need to use the same cert and key on every node, so our next step is to copy these files to all our other nodes.  Technically you should probably do this over a secure channel between the nodes via ssh or similar:

Once we have the files on all nodes, let’s put them into /etc/mysql so they are in a common place with correct permissions:

These are just examples of how you might do it.  Just take care to not expose your private key and keep it secure as possible while still getting it copied amongst your nodes.

Configuring Galera

The configuration here is quite easy:

We simply configure the wsrep provider with our certificate and key files on all our nodes.

However, it’s not possible to have a mixed cluster where some have SSL and some do not.  This is best configured when you are setting up a new cluster, but if you need to add this on a production system, you’ll unfortunately need to rebootstrap the cluster and take a [brief] outage.

In my case, I have an existing non-SSL cluster, so to re-bootstrap, I simply:

There should be no need for SST in this case: each node was shutdown cleanly, and brought back up cleanly. As soon as the first node is restarted with SSL enabled, all future nodes must also have it enabled.

Other SSL options

It is also possible to set the following options (though they seem to have sane defaults to me):

  • socket.ssl_cipher = AES128-SHA by default
  • socket.ssl_compression = yes by default

Other questions

Will IST be encrypted if I set the above settings?

Yes, according to Codership, IST transfers use the same socket settings as regular group communication (gcomm).

Will SST be encrypted?

No, none of the default methods currently support SSL.  However, SST is scriptable, so this technically shouldn’t be that difficult to add.  We’d welcome some open source contribution in this space for encrypted versions of (or just enhancements to) the current SST scripts.

PREVIOUS POST
NEXT POST

Share this post

Comments (9)

  • Raghavendra Reply

    Xtrabackup 2.1 supports encryption — https://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/encrypted_backups_innobackupex.html#encrypted-backups-ibk

    So, it should be possible to add encrypted backups.

    Another interesting possibility is to use compact backups — https://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/compact_backups_innobackupex.html#compact-backups-ibk — for faster SST.

    May 13, 2013 at 4:10 am
  • Raghavendra Reply May 13, 2013 at 4:17 am
  • marc castrovinci Reply

    I’ve got this running now but being a skeptic, is there a way to ensure its actually using ssl and didn’t fail silently? Pretty much options other then “have ssl” and wsrep_provider_options showing the correct output

    July 12, 2013 at 4:53 pm
  • marc castrovinci Reply

    Found it in the logs:

    130713 3:15:24 [Note] WSREP: SSL handshake successful, remote endpoint ssl://**.**.**.**:4567 local endpoint ssl://**.**.**.**:43622 cipher: AES128-SHA compression: zlib compression

    July 12, 2013 at 11:18 pm
  • Jason Heiss Reply

    Are there plans to add settings for validating the remote cert against a certificate authority? As it stands this appears to get you encryption but no authentication that you’re actually talking to the other cluster members that you expect. The equivalent settings in the standard percona/mysql SSL setups are ssl-ca and ssl-capath.

    September 30, 2013 at 8:34 am
  • Jay Janssen Reply

    @Jason: good question. I’d suggest filing a feature request as a bug/blueprint here: https://bugs.launchpad.net/percona-xtradb-cluster

    September 30, 2013 at 8:44 am
  • Jason Heiss Reply

    I dug around in the galera code and found that they have an socket.ssl_ca parameter, it just wasn’t documented. I’ve submitted a patch to galera to document the parameter.

    November 7, 2013 at 3:33 am
  • Marc Castrovinci Reply

    For all who find this later. Jason mentioned the socket.ssl_ca parameter. It is always set but defaults to whatever is set in socket.ssl_cert.

    So if you have generated a CA for your self signed cert, be sure to update the option.

    July 16, 2014 at 10:33 am
  • Darren Clark Reply

    On Ubuntu 14.04 LTS on starting the mysql error log reported:

    [ERROR] WSREP: could not use private key file ‘/etc/mysql/key.pem’: Invalid argument

    On investigating further it appeared that specify a date after 2038 can cause key issues, specifying less days fixed the issue.

    November 13, 2014 at 4:26 pm

Leave a Reply