This section introduces how to protect the security of the connection between the members of the combined group from the two aspects of the IP whitelist copied from the group and the secure socket (SSL) support.
5.1. Whitelist of IP addresses for group replication
The MGR plug-in has a system variable group_replication_ip_whitelist, which is used to determine from which host incoming group communication system connections can be accepted. Suppose that the system variable is set in Server S1, and then S1 is used to boot the group. After that, Server S2 is used as the joiner node. When S2 tries to establish a group communication connection with S1, S1 checks before accepting S2's group communication connection request Whether the setting of the system variable group_replication_ip_whitelist allows S2 access, if allowed, accept the group communication connection request of S2, otherwise reject the group communication connection request of S2.
If the whitelist is not explicitly specified, S1's group communication engine (XCom) will automatically scan the active network card interfaces on the host where S1 is located, and generate corresponding subnet addresses (including IPV4) based on the IP addresses configured on these active network card interfaces And IPV6 address). Based on these generated subnet addresses, a whitelist setting for group replication is automatically created. The automatically generated IP whitelist address may include the following ranges:
IPv4 (在RFC 1918中定义的IPV4地址的划分)
# A类地址
10/8 (IP范围：10.0.0.0-10.255.255.255)
# B类地址
172.16/12 (IP范围：172.16.0.0-172.31.255.255)
# C类地址
192.168/16 (IP范围：192.168.0.0-192.168.255.255) -
IPv6 ( 在RFC 4193 和 RFC 5156中定义的IPV6地址的划分)
# 唯一的本地地址前缀（范围）
fc00:/7
# 本地链路的单播地址前缀（范围）
fe80::/10
# 本地(localhost)IPv4地址
127.0.0.1 - localhost for IPv4
# 本地(localhost)IPv6地址
::1 - localhost for IPv6
The whitelist address information automatically added for the host will be recorded in the MySQL error log.
From the IP range described in the above code snippet, we can see that the automatically generated whitelist addresses are all private network addresses (even if the host is configured with a public network IP address, the whitelist of the public network address network will not be generated). The private address is only allowed to be accessed within the private network, not on the public network. Because, if you want to use the public network address as a whitelist, you need to use the system variable group_replication_ip_whitelist to explicitly specify the range of public network addresses you want to allow open access. In addition, once the system variable group_replication_ip_whitelist specifies a value, the whitelist is automatically generated The function of is invalid. Any address not specified in the system variable group_replication_ip_whitelist is not allowed to access. Therefore, any IP address range that you want to allow access to, you need to specify explicitly.
If a server is an active member of the group, it is not allowed to dynamically modify the whitelist address. You must first execute the STOP GROUP_REPLICATION statement to stop group replication and let it actively leave the group. After the whitelist is configured, execute the START GROUP_REPLICATION statement to restart it. Apply to join the group. Otherwise, an error will be reported: ERROR 3093 (HY000): The IP whitelist cannot be set while Group Replication is running.
If you want to explicitly specify the whitelist address, you can use the following valid string specifications:
Single IPV4 address: for example, 198.51.100.44
IPv4 address with CIDR notation: For example, 192.0.2.21/24 can be understood as an address with a subnet mask.
IPv6 address (IPV6 address support was introduced in MySQL 8.0.14): For example, 2001:db8:85a3:8d3:1319:8a2e:370:7348
IPv6 address with CIDR symbol (IPV6 address support was introduced in MySQL 8.0.14): For example, 2001:db8:85a3:8d3::/64
Host name: For example, example.org
Host name with CIDR notation: For example, www.example.com/24
Before MySQL 8.0.14, hostnames could only be resolved to IPv4 addresses. Starting from MySQL 8.0.14, hostnames can be resolved to IPv4 addresses or IPv6 addresses or both. If the host name resolves to both IPv4 and IPv6 addresses, the IPv4 address is always preferred for group replication connections. You can use CIDR notation in combination with hostnames or IP addresses to whitelist blocks of IP addresses with specific network prefixes (ie, whitelist IP address ranges with subnet masks), but make sure The specified subnet contains all the IP addresses you wish to allow access.
To modify the whitelist settings, you need to restart group replication. If there are multiple whitelist addresses, use commas to separate them, as follows:
# 先停止组复制
mysql> STOP GROUP_REPLICATION;
# 修改白名单地址
mysql> SET GLOBAL group_replication_ip_whitelist="192.0.2.21/24,198.51.100.44,203.0.113.0/24,2001:db8:85a3:8d3:1319:8a2e:370:7348,example.org,www.example.com/24";
# 重新启动组复制
mysql> START GROUP_REPLICATION;
The whitelist must contain the IP address or host name specified in the system variable group_replication_local_address of each member. This address is not the same as the SQL protocol host and port of MySQL Server (the address and port specified by the system variable group_replication_local_address are used for group communication between group members, not for external business access).
To successfully join the replication group, the IP address of the given server to be added to the group needs to be allowed to initiate group communication requests in the whitelist of the seed members requesting to join the group. Usually, the adaptation is performed according to the IP set by the system variable group_replication_group_seeds of the seed member (ie the boot member of the group), but it can also be set according to the value specified by the system variable group_replication_group_seeds of any member in the group, for example: The members mix IPV4 and IPV6 addresses, so it is recommended to configure the IPV4 and IPV6 protocol addresses of the network that all members may use for group communication into the whitelist to avoid the possibility of being refused connection when the server applies to join the group. It happened. For more information on managing mixed IPv4 and IPv6 replication groups, see "4.5. Configuring groups that support IPv6 and mixed IPv6 and IPv4 addresses".
When the replication group is reconfigured (for example, when a new primary node is elected or a member leaves the group), the group members will re-establish the connection between them. If the whitelist address configuration of all members in the group is inconsistent, after the reconfiguration of the group, a member may be allowed to join the group before the reconfiguration of the group but cannot rejoin the group after the reconfiguration (for example: there are 3 in the group) Members S1, S2, S3, when S3 leaves the group and reconfigures the group, due to the inconsistency of the whitelist, S2 does not allow S1 access, S3 allows S1 access, but now S3 is no longer in the group, which will lead to S3 After leaving the group, S1 and S2 cannot form a new group). To avoid this completely, it is recommended to set a consistent whitelist among all members in the group.
For the whitelist setting of the host name, name resolution will be performed only when another server initiates a connection request. Unresolved hostnames will not be used for whitelist verification, and warning messages will be written to the MySQL error log.
Note: The host name is used as a whitelist, and the security is not as good as the IP address. Unless it is necessary, it is not recommended to use external components to implement name resolution (unless you can control the security of external components). If there is a temporary need, you can consider using local Implementation of /etc/hosts parsing record in the host
5.2. Group Copy Secure Socket Layer (SSL) support
We can use SSL to protect the communication connection between group members and the connection for distributed recovery. This section will introduce how to configure SSL connection.
5.2.1. Configure SSL for group communication
Secure sockets can be used for group communication connections between group members. The system variable group_replication_ssl_mode of the MGR plug-in controls whether SSL is enabled for the group communication connection, and specifies the security mode for the group communication connection. The default setting is DISABLED, which means SSL is not used. The system variable has the following valid values:
| value | description |
|---|---|
| DISABLED | Establish an unencrypted connection (default), that is, do not enable SSL |
| REQUIRED | If a secure connection is supported between group members, a secure connection is established |
| VERIFY_CA | Similar to REQUIRED, but to verify the server TLS certificate according to the configured certificate authority (CA) certificate |
| VERIFY_IDENTITY | Similar to VERIFY_CA, but also verify that the server certificate matches the host (group member) trying to connect |
The remaining SSL-related configuration of the replicated group communication connection is configured through the SSL system variables of MySQL Server. These SSL system variables are as follows:
| Server configuration options (system variables) | description |
|---|---|
| ssl_key | The path name of the SSL private key file in PEM format. On the client side, it is used to specify the client private key file (for example: the ssl_key option of the mysql command line client); on the server side, it is used to specify the server’s private key file |
| ssl_cert | The path name of the SSL public key certificate file in PEM format. On the client, it is used to specify the client's public key certificate file; on the server, it is used to specify the server's public key certificate file |
| ssl_ca | Pathname of the certificate authority (CA) certificate file in PEM format |
| ssl_capath | The path name of the directory containing the trusted SSL certificate authority (CA) certificate file in PEM format |
| ssl_crl | The path name of the file containing the certificate revocation list in PEM format |
| ssl_crlpath | The path name of the directory containing the certificate revocation list file in PEM format |
| ssl_cipher | List of ciphers allowed in the handshake for encrypted connections |
| tls_version | List of TLS protocols allowed by the server for encrypted connections |
| tls_ciphersuites | TLSv1.3 cipher suite allowed by the server for encrypted connection |
Important matters:
Starting from MySQL 8.0.16, MySQL Server supports the TLSv1.3 protocol, provided that MySQL is compiled with OpenSSL 1.1.1 or higher. However, for group replication, TLSv1.3 is supported starting from MySQL 8.0.18. In MySQL 8.0.16 and MySQL 8.0.17, only MySQL Server supports TLSv1.3, but the group communication engine does not support TLSv1.3 protocol, so group replication cannot use TLSv1.3 protocol in these two versions.
Please ensure the continuity of the TLS protocol list specified in the system variable tls_version (for example: TLSv1, TLSv1.1, TLSv1.2). If there are any blanks in the protocol list (for example, if you specify TLSv1, TLSv1.2, and omit TLS 1.1), group replication may not be able to establish a group communication connection.
If the TLSv1.3 protocol is used for distributed recovery in group replication, at least one encryption algorithm suite (or "cipher suite") with TLSv1.3 version enabled by default is required in the group replication group members, otherwise the distributed recovery will fail .
In the replication group, OpenSSL is used to negotiate the highest TLS protocol version supported by all members. If a newly added server is configured to only support TLSv1.3 (tls_version=TLSv1.3), if the existing members of the group do not support TLSv1.3 (for example: set tls_version=TLSv1,TLSv1.1,TLSv1 .2), the new server cannot join the group (because the TLS protocol version used by all members in the group is lower than the TLS version of the new server). To connect the newly applied server to the group, the system variable tls_version of the newly applied server must be modified to support the lower version (for example: tls_version=TLSv1,TLSv1.1,TLSv1.2,TLSv1.3), the modification is complete After that, try to reapply to join the group again. In this case, OpenSSL uses a lower TLS protocol version to establish a connection between the server applying to join the group and the existing members of the group. The existing members in the group still continue to use the highest supported TLS protocol version.
If you only modify the TLS version of the existing members of the group, but do not restart the group replication, the TLS version of the established connection between the existing members of the group will not change (it does not affect the connection between existing members).
If you want to use the TLSv1.3 version, you may need to upgrade the MySQL Server version of the existing members of the group to MySQL 8.0.18 and above, and then modify the TLS version to support TLSv1.3 (for example: tls_version =TLSv1,TLSv1.1,TLSv1.2,TLSv1.3).
Starting from MySQL 8.0.16, the tls_version system variable can be dynamically modified (that is, the TLS protocol version list can be modified online). Note that for group replication, the ALTER INSTANCE RELOAD TLS statement will reconfigure the SSL context of MySQL Server according to the current value of the system variable tls_version, but will not change the SSL context of the group communication connection when the group replication is running. To make the new system variable tls_version configuration effective for group replication, you must use the STOP GROUP_REPLICATION and START GROUP_REPLICATION statements to restart group replication.
To enable SSL support for MySQL Server, you can configure it as follows:
[mysqld]
# 为MySQL Server配置好SSL相关的系统变量
ssl_ca = "cacert.pem"
ssl_capath = "/.../ca_directory"
ssl_cert = "server-cert.pem"
ssl_cipher = "DHE-RSA-AEs256-SHA"
ssl_crl = "crl-server-revoked.crl"
ssl_crlpath = "/.../crl_directory"
ssl_key = "server-key.pem"
# 为组复制激活SSL，设置为REQUIRED时，如果组成员之间支持安全连接，则建立安全连接
group_replication_ssl_mode= REQUIRED
5.2.2. Configure SSL for Distributed Recovery
When a server applies to join the group, it will use a combination of remote cloning operations (if available) and asynchronous replication connections to perform distributed recovery. Both of these methods of state transfer need to set up replication users for distributed recovery, as described in "2.1.3. User Credentials". The copy user used when applying to join the group needs to be created in the existing members of the group before the application to join the group (if you need to use SSL, you need to configure SSL in advance), you can use the following statement to create a copy user and enable SSL.
donor> SET SQL_LOG_BIN=0;
donor> CREATE USER 'rec_ssl_user'@'%' REQUIRE SSL;
donor> GRANT replication slave ON *.* TO 'rec_ssl_user'@'%';
donor> GRANT BACKUP_ADMIN ON *.* TO 'rec_ssl_user'@'%';
donor> SET SQL_LOG_BIN=1;
Assuming that an SSL-enabled replication user has been configured in all members of the group, you can use the following statement to configure the use of this user for the recovery channel of group replication. When the group replication is started, the replication recovery channel will use these Credentials to connect other group members as follows:
new_member> CHANGE MASTER TO MASTER_USER="rec_ssl_user" FOR CHANNEL "group_replication_recovery";
To configure a secure distributed recovery connection, use the distributed recovery SSL system variables dedicated to group replication. These variables correspond to the Server SSL system variable values used for group communication connections, but they are only applicable to distributed recovery connections. By default, distributed recovery connections do not use SSL. Even if SSL is activated for group communication connections, these Server SSL system variables will not be applied to distributed recovery connections. The SSL system variables dedicated to group replication must be configured separately to take effect.
If the remote cloning operation is used as part of the distributed recovery, the group replication will automatically configure the SSL system variables of the clone plug-in to match the settings of the distributed recovery SSL system variables.
The dedicated SSL system variables for distributed recovery are as follows:
group_replication_recovery_use_ssl: When set to ON, group replication will use SSL for distributed recovery connections, including both remote cloning and binary log-based state transfers.
group_replication_recovery_ssl_ca: The path name of the certification authority (CA) file used for distributed recovery connections. Group replication will be automatically configured as the value of the SSL system variable clone_ssl_ca of the clone plugin according to the value of this system variable.
group_replication_recovery_ssl_capath: The path name of the directory containing trusted SSL certificate authority (CA) certificate files.
group_replication_recovery_ssl_cert: The path name of the SSL public key certificate file used for distributed recovery connections. Group replication will be automatically configured as the value of the SSL system variable clone_ssl_cert of the clone plug-in based on the value of this system variable.
group_replication_recovery_ssl_key: The path name of the SSL private key file used for distributed recovery connections. Group replication will be automatically configured as the value of the SSL system variable clone_ssl_key of the clone plugin according to the value of this system variable.
group_replication_recovery_ssl_verify_server_cert: Make the distributed recovery connection check the server's common name value in the certificate sent by the donor node. Setting this system variable to ON is equivalent to setting the system variable group_replication_ssl_mode to VERIFY_IDENTITY.
group_replication_recovery_ssl_crl: The path name of the file containing the certificate revocation list.
group_replication_recovery_ssl_crlpath: The path name of the directory containing the certificate revocation list.
group_replication_recovery_ssl_cipher: A list of allowed encryption algorithms for distributed recovery connections. You can specify a single or multiple (multiple algorithms are separated by colons).
An example of configuring SSL for distributed recovery connections for group replication is as follows:
new_member> SET GLOBAL group_replication_recovery_use_ssl=1;
new_member> SET GLOBAL group_replication_recovery_ssl_ca= '.../cacert.pem';
new_member> SET GLOBAL group_replication_recovery_ssl_cert= '.../client-cert.pem';
new_member> SET GLOBAL group_replication_recovery_ssl_key= '.../client-key.pem';
| About the author
Luo Xiaobo·Database Technology Expert
One of the authors of "A Thousand Golden Recipes-MySQL Performance Optimization Pyramid Rule". Familiar with MySQL architecture, good at overall database tuning, like to specialize in open source technology, and keen on the promotion of open source technology, have done many public database topic sharing online and offline, and published nearly 100 database-related research articles.
Further reading
Group Replication Monitoring | A Comprehensive Understanding of MySQL 8.0 Group Replication
Group Replication Background | A Comprehensive Understanding of MySQL 8.0 Group Replication
The full text is over.
Enjoy MySQL 8.0 :)
Zhishutang's new course K8S is online
Scan the code to start a new learning journey