RDS DB instance disable secret rotation

[Viriathus1]

Description

RDS db instances allow the storing of master passwords in secrets manager through this flag manage_master_user_password. By default, secrets manager rotates this secret every 7 days however historically there's been an issue with modifying the rotation rules and disabling rotation outright. The former has been resolved here #34180 and elaborated here #32405. This pr will resolve the latter by providing a flag disable_master_user_password_rotation to disable password rotation in secrets manager.

Relations

Closes #37779
Relates #33462

References

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/db_instance
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/secretsmanager_secret_rotation
https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/secretsmanager#Client.CancelRotateSecret

Output from Acceptance Testing

% make testacc TESTS=TestAccRDSInstance_ManageMasterPassword_basic PKG=rds
make: Verifying source code with gofmt...
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go1.23.7 test ./internal/service/rds/... -v -count 1 -parallel 20 -run='TestAccRDSInstance_ManageMasterPassword_basic'  -timeout 360m -vet=off
2025/05/30 13:37:36 Initializing Terraform AWS Provider...
=== RUN   TestAccRDSInstance_ManageMasterPassword_basic
=== PAUSE TestAccRDSInstance_ManageMasterPassword_basic
=== CONT  TestAccRDSInstance_ManageMasterPassword_basic
--- PASS: TestAccRDSInstance_ManageMasterPassword_basic (338.04s)
PASS
ok      github.com/hashicorp/terraform-provider-aws/internal/service/rds   338.179s

% make testacc TESTS=TestAccRDSInstance_ManageMasterPassword_disableRotation PKG=rds
make: Verifying source code with gofmt...
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go1.23.7 test ./internal/service/rds/... -v -count 1 -parallel 20 -run='TestAccRDSInstance_ManageMasterPassword_disableRotation'  -timeout 360m -vet=off
2025/05/30 12:06:07 Initializing Terraform AWS Provider...
=== RUN   TestAccRDSInstance_ManageMasterPassword_disableRotation
=== PAUSE TestAccRDSInstance_ManageMasterPassword_disableRotation
=== CONT  TestAccRDSInstance_ManageMasterPassword_disableRotation
--- PASS: TestAccRDSInstance_ManageMasterPassword_disableRotation (465.86s)
PASS
ok      github.com/hashicorp/terraform-provider-aws/internal/service/rds   466.026s

% make testacc TESTS=TestAccRDSInstance_ManageMasterPassword_changeDisableRotationFlag PKG=rds
make: Verifying source code with gofmt...
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go1.23.7 test ./internal/service/rds/... -v -count 1 -parallel 20 -run='TestAccRDSInstance_ManageMasterPassword_changeDisableRotationFlag'  -timeout 360m -vet=off
2025/05/30 11:43:48 Initializing Terraform AWS Provider...
=== RUN   TestAccRDSInstance_ManageMasterPassword_changeDisableRotationFlag
=== PAUSE TestAccRDSInstance_ManageMasterPassword_changeDisableRotationFlag
=== CONT  TestAccRDSInstance_ManageMasterPassword_changeDisableRotationFlag
--- PASS: TestAccRDSInstance_ManageMasterPassword_changeDisableRotationFlag (566.37s)
PASS
ok      github.com/hashicorp/terraform-provider-aws/internal/service/rds   566.542s

[github-actions]

Community Guidelines

This comment is added to every new Pull Request to provide quick reference to how the Terraform AWS Provider is maintained. Please review the information below, and thank you for contributing to the community that keeps the provider thriving! 🚀

Voting for Prioritization

• Please vote on this Pull Request by adding a 👍 reaction to the original post to help the community and maintainers prioritize it.
• Please see our prioritization guide for additional information on how the maintainers handle prioritization.
• Please do not leave +1 or other comments that do not add relevant new information or questions; they generate extra noise for others following the Pull Request and do not help prioritize the request.

Pull Request Authors

• Review the contribution guide relating to the type of change you are making to ensure all of the necessary steps have been taken.
• Whether or not the branch has been rebased will not impact prioritization, but doing so is always a welcome surprise.

[github-actions]

✅ Thank you for correcting the previously detected issues! The maintainers appreciate your efforts to make the review process as smooth as possible.

[aristosvo]

Hi @Viriathus1 ! Just curiosity, what is the exact win here over using the write-only arguments and ephemeral resources?

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

resource "aws_secretsmanager_secret" "example" {
  name = "example"
}

locals {
  version = 1
}

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

resource "aws_db_instance" "test" {
  instance_class      = "db.t3.micro"
  allocated_storage   = "5"
  engine              = "postgres"
  username            = "example"
  skip_final_snapshot = true
  password_wo         = ephemeral.random_password.db_password.result
  password_wo_version = local.version
}

I think this use-case is served way better by using the write-only arguments and ephemeral resources than implementing it in the resource. This is creating unpredictable behavior, which is not really visible for the user. Issues are hard to validate as it interferes with the management of a password AWS is supposed to manage. Besides that, it is mixing calls to different services in one resource.

Happy to hear your thoughts!

[ross-c-swyftx]

I am wary of adding a feature for disabling the secret rotation off a flag as I think it conflates two resources that should be managed separately.

Some issues I see:

1. There's no reversal process to reenable rotation with the flag.
2. The CreateDBInstance/CreateDBCluster API does not expose a flag for disabling secrets rotation directly, by design.
3. If it's a managed master password, rotation is implied.
4. It introduces a new client into the RDS resources for SecretsManager which previously was unneeded/unnecessary as they are technically orthogonal concerns from an API perspective.

Just my thoughts, I see you've put in some effort here though!

[Viriathus1]

Hi @aristosvo and @ross-c-swyftx (fellow aussie), I don't agree that the PR would cause unpredictable behaviour given that it wouldn't interfere with password management unless explicitly opted in. The only case I suppose it's unpredictable is that it currently wouldn't re-enable rotation if the flag is removed or set to false in an update and that's an easy enough update. The current default is not visible to the user at all even in the RDS console unless you go directly to secrets manager and seek it out.

This brings me to the other point being that rotation should be assumed when using this integration. I believe there are enough issues and support for the notion that most users only become aware of this condition after they've been caught out by it. The existence of a rotation schedule would only be implied if it exposed setting the rotation schedule as well but it doesn't. Another way to bring awareness would be to include it as a gotcha in the documentation reference. In terms of what the API is designed to do I would just say that I don't believe that silently enforcing a default of 7 day rotation would be broadly applicable to most users. The sensible default in my opinion would be no rotation with the option to set a rotation schedule if desired.

These two services became tightly coupled when AWS provided this integration between RDS and Secrets Manager but I do agree though that mixing calls to different clients in the one service is inelegant and I'm happy for a code owner to shut it down for that reason alone. With all that being said, @aristosvo I like your solution and I actually wasn't aware of ephemeral resources until you commented which I suppose shame on me but I'll be recommending your solution going forward for this use case. I'll still leave the PR up in case the community prefers this approach.

[aristosvo]

Hi @Viriathus1 ! Thanks for your response. I must say I might've been a bit too harsh in the first comment of myself, as I must admit that the issue is certainly something that affects a lot of people.

The biggest problems here seem to be indeed familiarity with the exact feature (rotation after 7 days etc) and the wish to do this but without rotation.

I think we might be able to provide a solution to both by improving the documentation with:

• The example on ephemeral resources/write-only arguments
• Clarification on the working of managed master user passwords

WDYT?