How to implement single-user secret rotation using Amazon RDS admin credentials

You might have security or compliance standards that prevent a database user from changing their own credentials and from having multiple users with identical permissions. AWS Secrets Manager offers two rotation strategies for secrets that contain Amazon Relational Database Service (Amazon RDS) credentials: single-user and alternating-user.

In the preceding scenario, neither single-user rotation nor alternating-user rotation would meet your security or compliance standards. Single-user rotation uses database user credentials in the secret to rotate itself (assuming the user has change-password permissions). Alternating-user rotation uses Amazon RDS admin credentials from another secret to create and update a _clone user credential, which means there are two valid user credentials with identical permissions.

In this post, you will learn how to implement a modified alternating-user solution that uses Amazon RDS admin user credentials to rotate database credentials while not creating an identical _clone user. This modified rotation strategy creates a short lag between when the password in the database changes and when the secret is updated. During this brief lag before the new password is updated, database calls using the old credentials might be denied. Test this in your environment to determine if the lag is within an acceptable range.

Walkthrough

In this walkthrough, you will learn how to implement the modified rotation strategy by modifying the existing alternating-user rotation template. To accomplish this, you need to complete the following:

• Configure alternating-user rotation on the database credential secret for which you want to implement the modified rotation strategy.
• Modify your AWS Lambda rotation function template code to implement the modified rotation strategy.
• Test the modified rotation strategy on your database credential secret and verify that the secret was rotated while also not creating a _clone user.

To configure alternating-user rotation on the database credential secret

1. Follow this AWS Security Blog post to set up alternating-user rotation on an Amazon RDS instance.
2. When configuring rotation for the database user secret in the Secrets Manager console, clear the checkbox for Rotate immediately when the secret is stored. The next rotation will begin on your schedule in the Rotation schedule tab. Make sure that no _clone user is created by the default alternating-user rotation code through your database’s user tables.

Figure 1: Clear the checkbox for Rotate immediately when the secret is stored

To modify your Lambda function rotation Lambda template to implement the modified rotation strategy

1. In the Secrets Manager console, select the Secrets menu from the left pane. Then, select the new database user secret’s name from the Secret name column.
   

   Figure 2: Select the new database user secret

2. Select the Rotation tab on the Secrets page, and then choose the link under Lambda rotation function.
   

   Figure 3: Select the Lambda rotation function

3. From the rotation Lambda menu, Download select Download function code.zip.
   

   Figure 4: Select Download function code .zip from Download

4. Unzip the .zip file. Open the lambda_function.py file in a code editor and make the following code changes to implement the modified rotation strategy.

   The following code changes show how to modify a rotation function for the MySQL alternating-user rotation code template. You must make similar changes in the CreateSecret and SetSecret steps of the alternating-user rotation code template for your database’s engine type.

   To make the needed changes, remove the lines of code that are in grey italic and add the lines of code that are bold.

   Consider using AWS Lambda function versions to enable reverting your Lambda function to previous iterations in case this modified rotation strategy goes wrong.

   In create_secret()

   The following code suggestion removes the creation of _clone-suffixed usernames.

   Remove:

   -- # Get the alternate username swapping between the original user and the user with _clone appended to it
   -- current_dict['username'] = get_alt_username(current_dict['username'])

   In set_secret()

   The following code suggestions remove the creation of _clone-suffixed usernames and subsequent checks for such usernames in conditional logic.

   Keep:

   # Get username character limit from environment variable
   username_limit = int(os.environ.get('USERNAME_CHARACTER_LIMIT', '16'))

   Remove:

   -- # Get the alternate username swapping between the original user and the user with _clone appended to it
   -- current_dict['username'] = get_alt_username(current_dict['username'])

   Keep:

   # Check that the username is within correct length requirements for version

   Remove:

   -- if current_dict['username'].endswith('_clone') and len(current_dict['username']) > username_limit:

   Add:

   ++ if len(current_dict[‘username’]) > username_limit:

   Keep:

   raise ValueError("Unable to clone user, username length with _clone appended would exceed %s character
   s" % username_limit)
   # Make sure the user from current and pending match

   Remove:

   -- if get_alt_username(current_dict['username']) != pending_dict['username']:

   Add:

   ++ if current_dict['username'] != pending_dict['username']:

   Remove:

   -- def get_alt_username(current_username):
   --   """Gets the alternate username for the current_username passed in
   --
   --   This helper function gets the username for the alternate user based on the passed in current username.
   --
   --   Args:
   --       current_username (client): The current username
   --
   --   Returns:
   --      AlternateUsername: Alternate username
   --
   --   Raises:
   --      ValueError: If the new username length would exceed the maximum allowed
   --
   --   """
   --   clone_suffix = "_clone"
   --   if current_username.endswith(clone_suffix):
   --       return current_username[:(len(clone_suffix) * -1)]
   --   else:
   --       return current_username + clone_suffix
   --

   The following code suggestions remove the logic of creating a new _clone user within the database, and rotates the existing user’s password.

   Keep:

   with conn.cursor() as cur:

   Remove:

   --   cur.execute("SELECT User FROM mysql.user WHERE User = %s", pending_dict['username'])
   --   # Create the user if it does not exist
   --   if cur.rowcount == 0:
   --      cur.execute("CREATE USER %s IDENTIFIED BY %s", (pending_dict['username'], pending_dict['password']))
   -- 
   --   # Copy grants to the new user
   --   cur.execute("SHOW GRANTS FOR %s", current_dict['username'])
   --   for row in cur.fetchall():
   --       grant = row[0].split(' TO ')
   --       new_grant_escaped = grant[0].replace('%', '%%')  # % is a special character in Python format strings.
   --       cur.execute(new_grant_escaped + " TO %s", (pending_dict['username'],))

   Keep:

       # Get the version of MySQL
       cur.execute("SELECT VERSION()")
       ver = cur.fetchone()[0]

   Remove:

   --   # Copy TLS options to the new user
   --   escaped_encryption_statement = get_escaped_encryption_statement(ver)
   --   cur.execute("SELECT ssl_type, ssl_cipher, x509_issuer, x509_subject FROM mysql.user WHERE User = %s", current_dict['username'])
   --   tls_options = cur.fetchone()
   --   ssl_type = tls_options[0]
   --   if not ssl_type:
   --       cur.execute(escaped_encryption_statement + " NONE", pending_dict['username'])
   --   elif ssl_type == "ANY":
   --       cur.execute(escaped_encryption_statement + " SSL", pending_dict['username'])
   --   elif ssl_type == "X509":
   --       cur.execute(escaped_encryption_statement + " X509", pending_dict['username'])
   --   else:
   --       cur.execute(escaped_encryption_statement + " CIPHER %s AND ISSUER %s AND SUBJECT %s", (pending_dict['username'], tls_options[1], tls_options[2], tls_options[3]))

   Keep:

       # Set the password for the user and commit
       password_option = get_password_option(ver)
       cur.execute("SET PASSWORD FOR %s = " + password_option, (pending_dict['username'], pending_dict['password']))
       conn.commit()
       logger.info("setSecret: Successfully set password for %s in MySQL DB for secret arn %s." % (pending_dict['username'], arn))

5. Re-zip the folder with the local code changes. From the rotation Lambda menu, under the Code tab, choose Upload from and select .zip file. Upload the new .zip file.
   

   Figure 5: Use Upload from to upload the new .zip file as the Code source

To test the modified rotation strategy

1. During the next scheduled rotation for the new database user secret, the modified rotation code will run. To test this immediately, select the Rotation tab within the Secrets menu and choose Rotate secret immediately in the Rotation configuration section.
   

   Figure 6: Choose Rotate secret immediately to test the new rotation strategy

2. To verify that the modified rotation strategy worked, verify the sign-in details in both the secret and the database itself.
   1. To verify the Secrets Manager secret, select the Secrets menu in the Secrets Manager console and choose Retrieve secret value under the Overview tab. Verify that the username doesn’t have a _clone suffix and that there is a new password. Alternatively, make a get-secret-value call on the secret through the AWS Command Line Interface (AWS CLI) and verify the username and password details.
      

      Figure 7: Use the secret details page for the database user secret to verify that the value of the username key is unchanged

   2. To verify the sign-in details in the database, sign in to the database with admin credentials. Run the following database command to verify that no users with a _clone suffix exist: SELECT * FROM mysql.user;. Make sure to use the commands appropriate for your database engine type.
   3. Also, verify that the new sign-in credentials in the secret work by signing in to the database with the credentials.

Clean up the resources

• Follow the Clean up the resources section from the AWS Security Blog post used at the start of this walkthrough.

Conclusion

In this post, you’ve learned how to configure rotation of Amazon RDS database users using a modified alternating-users rotation strategy to help meet more specific security and compliance standards. The modified strategy ensures that database users don’t rotate themselves and that there are no duplicate users created in the database.

You can start implementing this modified rotation strategy through the AWS Secrets Manager console and Amazon RDS console. To learn more about Secrets Manager, see the Secrets Manager documentation.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on AWS Secrets Manager re:Post or contact AWS Support.

Want more AWS Security news? Follow us on X.