I'm currently working on setting up a password rotation strategy for an AWS Aurora/MySQL based application.

My plan was to use a strategy like this...

  • Application usernames/passwords stored in AWS SSM encrypted parameters.
  • Application servers have access to retrieve only their credentials from SSM. Restricted by environment (staging, production etc.)
  • Lambda configured to run periodically to change passwords in MySQL and store the new values in SSM. Lambda to authenticate with the database using AWS IAM roles, rather than using a password.

The last bit is the bit I'm not sure about. This configuration would require the lambda role/user to have permission to change the passwords for all of the other application users.

Is this a reasonable way to do it, from a security perspective? Since the lambda mysql user will use an IAM role rather than a password, this should retrict it's use to only authorised roles.

The alternative would be to not have a special db user for the lambda to login, but rather to have the lambda function retreive each users credentials from SSM, and then login as each user to change it's password.

Either way the lambda is going to need to have access to each user.

Assuming I can carefully retrieve access to the "lambda_user" in MySQL, are there any other glaring issues with having a user have authority to change other users passwords?

Also, just to clarify, these are application users, not regular human type users who will be using these credentials.

  • Secrets Manager has a canned solution for this. Aug 17, 2020 at 12:44
  • I looked at the secrets manager built-in credential rotation. It seemed overly complex to setup and configure etc. I wasn't able to get it to work for some reason. I might revisit this at some stage. At the moment the SSM parameters approach is working for us. Aug 18, 2020 at 5:45

1 Answer 1


This is the best-practice way to do it, for exactly the reasons you outline. By having the Lambda use a role for authentication instead of credentials, you minimize the number of secrets you keep around, which is definitely a good thing. There are only 2 things worth pointing out:

  1. You can now use CloudFormation to automate the provisioning and deployment of a special purpose Lambda for just this. As a result you can do this with relative ease. I'm not personally a big fan of CloudFormation but I would use it here anyway.

  2. Switching to the metadata V2 endpoints can provide some additional security from SSRF found in your infrastructure as well as other forms of break-in, although that won't be very relevant in this use-case.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .