Hi all, here is a new post following the blog series on the last MySQLvGroup Replication labs release which already presented: 1) the new features; 2) most asked questions; 3) summary of behaviour and configuration changes; and 4) the performance improvements.
On this blog post I will provide a closer look on the security improvements.

Secure Connections

Following the industry standards, Group Replication supports secure connections along the complete stack:

1. client connection to MySQL server
2. distributed recovery connection, through group_replication_recovery_ssl_* options
3. connections between group members

The secure connections support between group members is now in place. Admin can configure it using the option group_replication_ssl_mode, which can be set to the value of:

• DISABLED: Establish an unencrypted connection, the default value.
• REQUIRED: Establish a secure connection if the server supports secure connections.
• VERIFY_CA: Like REQUIRED, but additionally verify the server TLS certificate against the configured Certificate Authority (CA) certificates.
• VERIFY_IDENTITY: Like VERIFY_CA, but additionally verify that the server certificate matches the host to which the connection is attempted.

On Group Replication start, the plugin reads the server SSL configuration and uses it to configure its encryption on connections between group members.
More precisely, the following server configuration is reused: @@ssl_cert, @@ssl_key, @@ssl_ca, @@ssl_capath, @@ssl_crl, @@ssl_crlpath, @@ssl_cipher, @@tls_version.

On a MySQL server already configured to use secure connections, the admin only needs to set group_replication_ssl_mode value to also have secure connections between group members. With this approach, we reuse all the options and technologies that the server already implements, thus avoiding new options and technologies.

For details on how to configure the server to use secure connections, please read the manual.

IP Whitelisting

Through the option group_replication_ip_whitelist the admin can specify which hosts are allowed to connect to the group.
In order to make the group even more secure, we introduced this option aiming to avoid that non-authorized external entities had access to the group, that is, have a built-in configurable firewall .

By default it is set to the value AUTOMATIC, which allows connections from private subnetworks active on the host. That is, active interfaces on the host will be scanned and those with addresses on private subnetworks will be automatically added to the allowed list.

Admin can specify the allowed hosts using a comma separated list of IPv4 addresses or subnet CIDR notation. Example:

Note that address 127.0.0.1 is always allowed to connect, even when not specified on group_replication_ip_whitelist option.

Recovery credentials

In previous versions of Group Replication you could set the user and password in your server settings or configuration file. To avoid this need of having a password exposed in the configuration file, we leveraged the CHANGE MASTER structure and reused it for this purpose.

For that reason we removed the options:

Now, to configure the user and password that recovery needs to fetch the information from the other members, the admin shall execute a command in the form of:

Note that this comes at a cost, as you cannot configure a server to run group replication when it starts for the first time. You need to start the server, configure the recovery user and password and only then you can make a full use of group_replication_start_on_boot.

Conclusion

Go to http://labs.mysql.com/ and try the new preview release of MySQL Group Replication and send us your feedback.

As with all labs releases, we are not recommending that this software be used in production as there are likely still a number of bugs which need to be fixed. If you do encounter any issues, please file a bug under the ‘MySQL Server: Group Replication’ category so that we may investigate further.