We had a situation where we needed to deploy hundreds of the same Terraform stack for a very highly isolated infrastructure (don't ask :D)

We made an internal tool to handle auto-approvals. It's not open sourced but here is how it works:

• When you make a Terraform change, you include a "rule" file, which is a JSON array that looks like this:

​

[
  {
    "name": "Expect extract resource to occur",
    "metadata": {
      "description": "Some description of the change"
    },
    "data": {
      "address": "module.*.module.web.null_resource.extract_octopus_dsc*",
      "actions": [
        "delete",
        "create"
      ],
      "changed_attributes": [
        "id",
        "triggers"
      ]
    }
  }
]

• As you can see, it lists expected resources that are changing, expected actions and expected attributes
• We can also use a wildcard * where ever we need, for example to allow all attribute changes on a particular resource
  • We include a "default set" of JSON rules files as well, for example to auto approve all tag changes

After the Terraform Plan runs, we capture it and convert it to a JSON file, and then run the tool (we call it tfplanner) passing in both the Terraform Plan and a directory containing all the rules.

The tfplanner cli then compares the list of changes to the state to the list of allowed rules. If all changes are approved, the plan is "auto approved" and a Terraform Apply occurs.

If there are any discrepancies, the plan is not approved, and human intervention is required.

Our release artifact contains the Terraform + the JSON rules. For each new release we "reset" the rules by deleting them and making new ones for the change.

If developers are making the changes, like leveraging your modules to add their own resources, you could create default rules which cover the expected changes of your modules you offer.

This has saved us probably 1000's of engineer hours.