feat: Ephemeral password support

[artem-hatchenko]

Description

This update adds support for ephemeral master passwords (master_password_wo) in RDS/Aurora clusters.
With this option, the master password is write-only and never stored in the Terraform state.

Motivation

Since "manage_master_user_password" has annoying behavior with enabled rotation by default, and "master_password" stores the value in state, this solution provides an alternative.

How Has This Been Tested?

Tested with a few options:

Option 1

manage_master_user_password = false
master_password = false
master_password_wo = true

Result: Deploy successful and connection with "wo" password works

Option 2

manage_master_user_password = false
master_password = true
master_password_wo = true

Result: Conflicting configuration arguments (expected)

Option 3

manage_master_user_password = true
master_password = false
master_password_wo = true

Result: Conflicting configuration arguments (expected)

Usage

Generate a password via ephemeral, put result into Secret Manager, and retrieve version of the secret.

ephemeral "random_password" "db_password" {
  length           = 16
  override_special = "!#$%&*()-_=+[]{}<>:?"
}

resource "aws_secretsmanager_secret" "db_password" {
  name = "db_password"
}

resource "aws_secretsmanager_secret_version" "db_password" {
  secret_id                = aws_secretsmanager_secret.db_password.id
  secret_string_wo         = ephemeral.random_password.db_password.result
  secret_string_wo_version = 1
}

ephemeral "aws_secretsmanager_secret_version" "db_password" {
  secret_id = aws_secretsmanager_secret_version.db_password.secret_id
}

Pass necessary variables into module:

manage_master_user_password = false
master_password_wo          = ephemeral.aws_secretsmanager_secret_version.db_password.secret_string
master_password_wo_version  = aws_secretsmanager_secret_version.db_password.secret_string_wo_version

[bryantbiggs]

see #509 (comment)

[komaspieler]

Can I ask why this is considered a breaking change for the module? The parameter has been available for a while in the AWS provider and adding support for it in the module won't break any deployments that currently rely on either having the password managed by AWS or use master_password (or am I missing something?). What will break if this is merged?

[bryantbiggs]

its forcing users to upgrade to a new major version of the provider - plus, if you read what I linked, it will force users to use a quite new version of Terraform and also break support for OpenTofu (from what I am told) since OpenTofu does not support write-only arguments

[komaspieler]

The write-only arguments are already present in the currently referenced version requirement of the provider: https://registry.terraform.io/providers/hashicorp/aws/5.89.0/docs/resources/rds_cluster

Opentofu must therefore be able to somehow deal with them, I guess?

Is there a timeline for when you plan to update the terraform version requirement? I'm primarily asking to evaluate whether a fork is worth the effort - I really want to get rid of secrets in the state ^^'

[github-actions]

This PR has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this PR will be closed in 10 days

[garyhampson]

This is exactly what I'm looking for. Thanks @artem-hatchenko for raising this.

[remiflament]

Hello @bryantbiggs Do you have a public link (milestones, roadmap,...) that show which PRs/features will be include in a future breaking change v10 ? Thanks

[bryantbiggs]

milestone added - it is not exhaustive; it just captures known open issues and PRs that would be candidates for that release