Skip to main content
  1. Docs
  2. Secrets & Configuration
  3. Providers
  4. Rotators
  5. mysql

mysql

    The mysql rotator enables you to rotate user credentials for a MySQL database in your Environment.

    There are 2 methods to use this rotator:

    • Direct Connect rotation - when your database is publicly accessible
    • Connector rotation - when your database is in a private network. This method requires you setup a rotation connector in your network. Note: Connector-based rotation is only available for Enterprise and Business Critical customers.

    Prerequisites

    Example

    Best practice is to have 2 separate environments, one with managing credentials that is restricted to admins only, and one with the rotator itself.

    Credentials Environment

    Omit awsLogin property and everything under it if using Direct Connect rotation - you don’t need it. For Connector rotation, ensure you have working aws-login credentials setup with the connector.

    values:
      managingUser:
        username: managing_user # Replace with your username value
        # Replace ciphertext below with your password, keeping fn::secret to encrypt it, like so "fn::secret: <password>"
        password:
          fn::secret:
            ciphertext: ZXNjeAAAAAEAAAEAFatkojHgMRjHuWIwKbPqplpSUoKCrtLUCwtU0rhJuhtOa6eUBM/kxRgB/rp9
      awsLogin:
        fn::open::aws-login:
          oidc:
            duration: 1h
            roleArn: arn:aws:iam::1234567890:role/... # Role that has permissions to rotate your credentials, setup as part of the aws-lambda rotation connector
            sessionName: pulumi-esc-secret-rotator
    

    Rotator Environment

    Omit connector property if using Direct Connect rotation - you don’t need it. For Connector rotation, ensure you fill in the correct lambdaArn created when setting up the connector.

    values:
      dbRotator:
        fn::rotate::mysql:
          inputs:
            database:
              connector:
                awsLambda:
                  login: ${environments.rotatorExample.managingCredentials.awsLogin} # An implicit import from the above environment (assuming it's called rotatorExample/managingCredentials)
                  lambdaArn: arn:aws:lambda:aws-region:111111111111:function:PulumiEscSecretRotatorLambda-Function-xxxxxxx
              database: rotator_example_db
              host: rotator-example-mysql.cluster-xxxxxxxxxxxx.aws-region.rds.amazonaws.com
              port: 3306
              managingUser: ${environments.rotatorExample.managingCredentials.managingUser} # An implicit import from the above environment (assuming it's called rotatorExample/managingCredentials)
            rotateUsers:
              username1: user1
              username2: user2
    

    Note the 2 usernames inside the rotateUsers field - these are the users whose passwords will be rotated by the managing user. Once rotated, the usernames and their corresponding password will be stored in the state object. We need 2 users to ensure no apps using these credentials ever go down - while one of the users is being rotated, the other will be used and vice versa.

    State

    If you have existing users that you want to use right away, you can provide the state object directly under the fn::rotate::mysql rotator. Otherwise, the state object will be filled after 2 rotations.

    The users are cycled in the following manner: when username1 is the current user, username2 is previous and vice versa. During a rotation, previous user’s password is changed and its credentials are put into current user, with the other user moved to previous. Your apps should always use the current credentials, this way after a rotation, these credentials are still valid, just stored in the previous user, and your app can switch on the next configuration retrieval. One thing you have to be mindful of is to not rotate your secrets more frequently than your apps update their configuration - this will lead to them attempting to use credentials that are already rotated out.

    state:
      current:
        password:
          fn::secret: <password>
        username: user1
      previous:
        password:
          fn::secret: <password>
        username: user2
    

    When you open the environment after a rotation, you should see output similar to the following:

    {
      "dbRotator": {
        "current": {
          "username": "user1",
          "password": "[secret]"
        },
        "previous": {
          "username": "user2",
          "password": "[secret]"
        }
      }
    }
    

    Schema reference

    Reference schemas last updated on 2026-07-11, synced automatically from the Pulumi Cloud ESC API.

    Inputs

    • database object required
      The database configuration
    • connector object optional
      Configuration for connecting to the database
    • awsLambda object required
      Configuration for the AWS Lambda
    • lambdaArn string required
      The ARN of the rotator lambda
    • login AWSLogin required
      The credentials to use to invoke the lambda.
    • database string required
      The database name.
    • host string required
      The host name of the database.
    • managingUser object required
      The credentials of the user managing the db.
    • password string required
      Managing user password
    • username string required
      Managing user username
    • port number required
      The port number of the database.
    • rotateUsers object required
      Users to rotate
    • username1 string required
      Name of user to rotate
    • username2 string required
      Name of user to rotate

    State

    • current object optional
    • password string required
      Previous user’s password
    • username string required
      Name of previous user to rotate
    • previous object optional
    • password string required
      Previous user’s password
    • username string required
      Name of previous user to rotate

    Outputs

    • current object optional
    • password string required
      Previous user’s password
    • username string required
      Name of previous user to rotate
    • previous object optional
    • password string required
      Previous user’s password
    • username string required
      Name of previous user to rotate

    Troubleshooting

    SymptomLikely causeResolution
    Rotation fails to connect to the databaseThe host or port is wrong, or the database is in a private network without a connector.Verify host and port. For databases in a private network, configure a rotation connector and set database.connector.
    Rotation fails with a permissions or authentication errorThe managingUser may lack the privileges needed to change the rotated users’ passwords.Grant the managing user the privileges described in database user setup, then rotate again.
    Applications fail to authenticate after a rotationApps may be reading the previous credentials, or rotation may run more frequently than apps refresh their configuration.Configure applications to read current, and ensure the rotation schedule is less frequent than the application configuration refresh interval.