Security considerations for upgrading from Aurora MySQL version 3 to version 8.4

When migrating from Aurora MySQL version 3 (MySQL 8.0-compatible) to Aurora MySQL version 8.4, several important security-related changes require careful planning and consideration. This guide outlines the key security changes and provides recommendations for a smooth migration.

Authentication policy (new in 8.4)

Aurora MySQL version 3 (compatible with MySQL 8.0) uses the default_authentication_plugin parameter to configure the default authentication plugin used when creating database users. In Aurora MySQL version 8.4, this parameter is replaced with the authentication_policy parameter, set to *:caching_sha2_password by default.

Supported values in Aurora MySQL:

The upgrade precheck deprecatedDefaultAuth warns if your source cluster has default_authentication_plugin set to mysql_native_password. Review this warning and configure the authentication_policy parameter on your target cluster parameter group when upgrading.

Master user behavior

New clusters

The master user is created with the authentication plugin set by the authentication_policy parameter at cluster creation time. If you use the default parameter group, the master user is created with caching_sha2_password authentication plugin. If you use a custom parameter group with the authentication_policy parameter set to *:mysql_native_password, the master user is created with mysql_native_password authentication plugin.

Master user password reset

When you reset the master user password – via the AWS Management Console, CLI (modify-db-cluster --master-user-password), or API – Aurora uses the current default plugin defined by the authentication_policy parameter at the time of reset.

Secrets Manager and password rotation

When using AWS Secrets Manager to manage your master user password, if you update the value of the authentication_policy parameter, the next password rotation will set the master user's authentication plugin to match the new authentication_policy parameter value.

Database users created after upgrade

Existing database users that use the mysql_native_password authentication plugin continue to work after upgrade. Database users that you create after upgrade without specifying an IDENTIFIED WITH clause use the authentication plugin defined by the authentication_policy parameter. When the parameter is at its default value of *:caching_sha2_password, new users are created with the caching_sha2_password authentication plugin.

To change the default authentication plugin for all new users, update the value of authentication_policy. For more information about supported values, see Authentication policy (new in 8.4).

To create a user with a different authentication plugin than the default, specify it explicitly in the CREATE USER statement:

CREATE USER 'username'@'host' IDENTIFIED WITH authentication-plugin BY 'password';

Encryption and TLS changes

To require TLS for all user connections to your Aurora MySQL DB cluster, use the require_secure_transport DB cluster parameter. By default, this parameter is set to ON in Aurora MySQL version 8.4.

Aurora MySQL version 8.4 enforces stricter cryptographic standards aligned with the latest security requirements on the ssl_ciphers (TLS 1.2) and tls_ciphersuites (TLS 1.3) DB cluster parameters. For more information, see Security with Amazon Aurora MySQL.

To prevent connection disruptions, verify the TLS configurations for your MySQL client and your target DB cluster before migration.

Password validation component migration

Aurora MySQL version 8.4 introduces the aurora_enable_validate_password_component cluster parameter to enable or disable the validate_password component, removing the need to manually install or uninstall it. If you had previously installed the validate_password plugin and have since enabled the component after upgrading, only the component is effective – the plugin is ignored.

Starting from Aurora MySQL version 8.4, if you had previously installed the validate_password plugin through the INSTALL PLUGIN command, you can migrate to the validate_password component by enabling the parameter aurora_enable_validate_password_component and then remove the plugin through the UNINSTALL PLUGIN command on your writer instance.

If you previously installed the validate_password component manually using INSTALL COMPONENT 'file://component_validate_password', ensure you set the aurora_enable_validate_password_component parameter in your target DB cluster parameter group when upgrading. After upgrading, the component will no longer be listed in the mysql.component table. You can use the aurora_enable_validate_password_component global variable to verify the status of the component.

On the first DB engine startup after upgrade, you will see the following message in your MySQL error log if you had previously installed the component manually:

Component 'file://component_validate_password' is being removed from mysql.component table.
validate_password component can be enabled/disabled through 'aurora_enable_validate_password_component' cluster parameter.

The upgrade precheck auroraValidatePasswordPluginCheck warns if the validate_password plugin is installed on your source cluster. This warning does not block the upgrade, but you should plan to transition to the component after upgrading.

New dynamic privileges

Aurora MySQL version 8.4 supports the following new privileges:

These privileges are automatically granted to the Master user account privileges for your master user accounts on upgrade.

Protected user enforcement for rdsproxyadmin

Starting in Aurora MySQL version 8.4.7, rdsproxyadmin is a protected user. The engine rejects CREATE, DROP, RENAME, GRANT, REVOKE, and SET PASSWORD operations against rdsproxyadmin at any host. For the full list of rejected operations and example errors, see Reserved users in Aurora MySQL.

Aurora MySQL version 3 does not reserve the rdsproxyadmin name. If you created a database user named rdsproxyadmin in version 3 (rather than letting the system create it when you register a proxy target), review this section before upgrading to version 8.4.

Before you upgrade

If you created an rdsproxyadmin user in your version 3 cluster, rename or drop the account before you upgrade to version 8.4. You can use a version 3 connection to run one of the following statements:

-- Rename the existing account to a non-reserved name
RENAME USER 'rdsproxyadmin'@'host' TO 'new_user'@'host';

-- Or drop the account if it is no longer needed
DROP USER 'rdsproxyadmin'@'host';

Update any applications or stored credentials that reference the old user name before starting the upgrade.

If you don't rename or drop the user before upgrading

If you upgrade a cluster that already has an rdsproxyadmin user that you created, the upgrade completes successfully. The account is preserved with its existing password and privileges, and you can still connect to the cluster as rdsproxyadmin by using the original password.

However, after the upgrade, you can't modify the account. If you try to drop, rename, change privileges on, or change the password for rdsproxyadmin, the statement returns an error.

If you want to remove the account after the upgrade, or reclaim the rdsproxyadmin name for RDS Proxy to use, contact AWS Support. AWS Support can remove a pre-existing rdsproxyadmin user carried forward from version 3.