How to create Aurora Serverless database cluster with secret manager in Terraform

Question

I've been reading this page: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/rds_cluster

The example there is mainly for the provisioned database, I'm new to the serverless database, is there an Terraform example to create a serverless Aurora database cluster (SQL db), using the secret stored in the secret manager?

Many thanks.

Answer 1

I'm guessing you want to randomize the master_password? You can do something like this:

master_password = random_password.DatabaseMasterPassword.result

The SSM parameter can be created like so:

resource "aws_ssm_parameter" "SSMDatabaseMasterPassword" {
  name  = "database-master-password"
  type  = "SecureString"
  value = random_password.DatabaseMasterPassword.result
}

The random password can be defined like so:

resource "random_password" "DatabaseMasterPassword" {
  length           = 24
  special          = true
  override_special = "!#$%^*()-=+_?{}|"
}

Answer 2

The accepted answer will just create the Aurora RDS instance with a pre-set password -- but doesn't include Secrets Manager. It's a good idea to use Secrets Manager, so that your database and the applications (Lambdas, EC2, etc) can access the password from Secrets Manager, without having to copy/paste it to multiple locations (such as application configurations).

Additionally, by terraforming the password with random_password it will be stored in plaintext in your terraform.tfstate file which might be a concern. To resolve this concern you'd also need to enable Secrets Manager Automatic Secret Rotation.

Automatic rotation is a somewhat advanced configuration with Terraform. It involves:

• Deploying a Lambda with access to the RDS instance and to the Secret
• Configuring the rotation via the aws_secretsmanager_secret_rotation resource.

AWS provides ready-to-use Lambdas for many common rotation scenarios. The specific Lambda will vary depending on database engine (MySQL vs. Postgres vs. SQL Server vs. Oracle, etc), as well as whether you'll connecting to the database with the same credentials that you're rotating.

For example, when the secret rotates the process is something like:

• Invoke the rotation lambda, Secrets Manager will pass the name of the secret as a parameter
• The Lambda will use the details within the secret (DB Host, Post, Username, Password) to connect to RDS
• The Lambda will generate a new password and run the "Update password" command, which can vary based on DB Engine
• The Lambda will update the new credentials to Secrets Manager

For all this to work you'll also need to think about the permissions Lambda will need -- such as network connectivity to the RDS instance and IAM permissions to read/write secrets.

As mentioned it's somewhat advanced--but results in Secrets Manager being the only persistent location of the password. Once setup it works quite nicely though, and your apps can securely retrieve the password from Secrets Manager (one last tip -- it's ok to cache the secret in your app to reduce Secrets Manager calls but be sure to flush that cache on connection failures so that your apps will handle an automatic rotation).