Sign in
Menu
Sign up
Docs
Operational rulesRule catalog

Ignore secret rotation

For platform engineers deciding whether to apply lifecycle_ignore_secret_rotation: what it changes, how to enable it, and how to check it worked.

Adds ignore_changes for the database credential attribute on RDS instances and Aurora clusters. A rotated or regenerated password stops showing as a diff on every plan.

What this rule does

Adds a lifecycle { ignore_changes = [...] } block to each matching resource. Terraform and OpenTofu will ignore external changes to the listed attributes on subsequent plans.

Ignored attributes: password Adds a lifecycle { ignore_changes = [...] } block to each matching resource. Terraform and OpenTofu will ignore external changes to the listed attributes on subsequent plans.

Ignored attributes: master_password

Affected resources

ResourceServiceWhy
aws_db_instanceAmazon RDSpassword, set from a value that changes between plans
aws_rds_clusterAmazon Auroramaster_password, set from a value that changes between plans

Before and after

Before (a module without the change):

resource "aws_db_instance" "this" {
  # ... resource configuration ...

  tags = var.tags
}

After (with Ignore secret rotation applied):

resource "aws_db_instance" "this" {
  # ... resource configuration ...

  tags = var.tags

  lifecycle {
    ignore_changes = [password]
  }
}

Before (a module without the change):

resource "aws_db_instance" "this" {
  # ... resource configuration ...

  tags = var.tags
}

After (with Ignore secret rotation applied):

resource "aws_db_instance" "this" {
  # ... resource configuration ...

  tags = var.tags

  lifecycle {
    ignore_changes = [master_password]
  }
}

The only change is the rule transformation. All existing arguments, outputs, and module behavior remain identical.

The example above is illustrative. To see this rule run for real, open it in the Rules Playground: it applies lifecycle_ignore_secret_rotation to a reviewed upstream module that declares the resources this rule targets, and shows the diff the registry would serve. No account needed.

Why this rule exists

A regenerated random_password, a rotated Secrets Manager or Vault data source, or a variable supplied differently per runner gives Terraform a new value on every plan. Each plan proposes resetting the database password, and an apply that goes through resets it for real.

The fix is ignore_changes on the credential attribute, and a lifecycle block cannot be passed into an upstream module as a variable.

RepositoryIssueTitle
hashicorp/terraform#27360A method to override configuration and meta arguments within a module
hashicorp/terraform#24188Support for dynamic blocks and meta-arguments
hashicorp/terraform-provider-aws#19583Provider produced inconsistent final plan / an invalid new value for .tags_all

Limitations this rule answers

Per-module pages under Workarounds where this rule is the answer, each with the native workaround first and the diff the rule makes:

Default configuration

These are the values the rule ships with. Parameters never travel in a module source URL, so a rule named there runs with exactly these defaults. Your organization sets them per rule, in its Baseline or in a ruleset.

ParameterTypeDefaultDescription
db_instance_ignore_changeslist(string)["password"]Credential attributes on RDS instances. Override to [] to contribute nothing to the merged set
db_instance_resource_typeslist(string)["aws_db_instance"]Resource types whose credential attribute is named password
rds_cluster_ignore_changeslist(string)["master_password"]Credential attributes on Aurora clusters. Override to [] to contribute nothing to the merged set
rds_cluster_resource_typeslist(string)["aws_rds_cluster"]Resource types whose credential attribute is named master_password

The HCL this rule is written in, with its parameters and the transformers it runs, is published at lifecycle_ignore_secret_rotation.

How to enable

On a framework host, add the rule on top of your organization's Baseline with ?add_rules= in the HTTPS module source:

module "rds_aurora" {
  source = "https://soc2.compliance.tf/terraform-aws-modules/rds-aurora/aws?version=x.y.z&add_rules=lifecycle_ignore_secret_rotation"
}

On your organization's host, an org admin adds the rule to the Baseline, which reaches every module served from that host, or to a named ruleset that a module selects with ?ruleset=:

module "rds_aurora" {
  source = "https://bobthecorp.compliance.tf/terraform-aws-modules/rds-aurora/aws?version=x.y.z&ruleset=<ruleset-name>"
}

Replace x.y.z with the release you use and bobthecorp with your organization's alias. Which parameters each host accepts, and which it refuses with a 400, is on Rulesets in the console.

How to check it worked

Read compliancetf-manifest.json in the module you received. Its entry for this rule carries an outcome: enforced means the change was made, not_applicable means nothing matched - no resource of a targeted type, or the module already carried the identical change. Do not infer enforcement from a successful terraform init; a rule that changes nothing also inits cleanly.

Known limits

  • Only password on aws_db_instance and master_password on aws_rds_cluster. Other engines and resources are not touched.
  • Does not rotate anything and does not manage the secret. It only stops Terraform from writing the attribute back.
  • Each attribute list is a parameter; an organization can set one to [] to contribute nothing for that resource type.
  • Only .tf and .tofu files are read. Modules written in JSON syntax (.tf.json, .tofu.json) are left untouched.
  • Only the module's own directory and its first-level modules/* submodules are processed. Modules that this module calls by source URL are separate downloads and are handled on their own request.
  • Works with Terraform 1.x and OpenTofu 1.6 and later. The rule reads ordinary HCL, and anything it changes stays ordinary HCL.

Break-glass path

On a framework host, add ?rules=-lifecycle_ignore_secret_rotation to the module source URL and run terraform init; the source changed, so Terraform installs a fresh copy without this rule. When you are done, remove the override and run terraform init again to restore it. On your organization's host the parameter is refused with a 400 rather than ignored. The rule comes from the organization's configuration: a Baseline rule applies to every module served from the bare organization form, so an admin disables it for the duration of the operation, or keeps it out of the Baseline and in a ruleset that only the modules needing it select. On a project environment the posture is the bound snapshot and its waivers. See Baseline rules and rulesets.

Failure modes

ScenarioResult
Rule targets a module with no matching resource typesNo-op. Module is delivered unchanged and the manifest records not_applicable.
You change the password in Terraform on purposeThe change is ignored on plan. Rotate through the database or the secret store, or take the rule off that module for the operation.
The resource already carries an ignore_changes listThe list is kept and the attribute is merged in.

On this page

Ask AI about this

Help improve this page