Manage RDS password in Terraform in a sane way

database.tf

resource "random_password" "db_master_pass" {
  length            = 40
  special           = true
  min_special       = 5
  override_special  = "!#$%^&*()-_=+[]{}<>:?"
  keepers           = {
    pass_version  = 1
  }
}

resource "aws_db_instance" "mysql_db" {
  username                            = "mysql_user"
  password                            = random_password.db_master_pass.result
  ...
}

secret.tf

resource "aws_secretsmanager_secret" "db-pass" {
  name = "db-pass-${terraform.workspace}"
}

resource "aws_secretsmanager_secret_version" "db-pass-val" {
  secret_id     = aws_secretsmanager_secret.db-pass.id
  secret_string = random_password.db_master_pass.result
}

I know this is an old gist, but I just want to leave this here for anyone stumbling across this: The random_string resource does not provide cryptographically secure randomness and will be displayed in the console output.

For passwords you should use the random_password resource (https://registry.terraform.io/providers/hashicorp/random/latest/docs/resources/password)

Some syntax has changed since I wrote this gist too. I've updated it 👍

Is there any specific reason that you don't force the DB instance to depend on the secret like this?

resource "aws_db_instance" "mysql_db" {
  username                            = "mysql_user"
  password                            = aws_secretsmanager_secret_version.db-pass-val.secret_string
  ...
}

Is there any specific reason that you don't force the DB instance to depend on the secret like this?

resource "aws_db_instance" "mysql_db" {
  username                            = "mysql_user"
  password                            = aws_secretsmanager_secret_version.db-pass-val.secret_string
  ...
}

I don't think so, though these days I'm doing a lot to avoid secrets in terraform state at all.

No problem. I thought about it a little bit later and determined that there could be some advantages to shaping the graph one way versus another, allowing certain destroy/create actions to be smaller in scope for example. I've noticed that people don't really pay too much attention to the overall structure of the graph unless they have a problem, so I'm really just being a Terraform nerd 😆

Regarding secrets in terraform state, IMO it's unavoidable. Treat state itself as a secret. Lock those S3 buckets down.

You also have to account for potential secrets leakage in your plans though. We've started building modules (like this one) that create secrets with a lambda so they're never in TF state. There's varying levels of native support for Secrets Manager though of course.

Just when I think I'm right about something, I get shown something far more clever than I could've imagined 😂