aws_cloudformation_stack indefinitely reapplies changes in NoEcho parameters

[hashibot]

This issue was originally opened by @mtb-xt as hashicorp/terraform#4335. It was migrated here as part of the provider split. The original body of the issue is below.

---

If a cloudformation template contains a parameter with NoEcho set to true (like a password), the parameter value is shown as asterisks "****".

Terraform 0.6.8 detects this as a parameter change and tries to reapply it on every 'plan' or 'apply':

aws_cloudformation_stack.redshift-prod: Modifying...
  parameters.MasterUserPassword: "****" => "lolmegapassword"

[hashibot]

This comment was originally opened by @radeksimko as hashicorp/terraform#4335 (comment). It was migrated here as part of the provider split. The original comment is below.

---

Thanks for this report too. 😃

A solution could be ignoring changes in NoEcho parameters coming from AWS, the only difficult part is in decoding the whole template as this attribute isn't available from the API directly.

[hashibot]

This comment was originally opened by @radeksimko as hashicorp/terraform#4335 (comment). It was migrated here as part of the provider split. The original comment is below.

---

This project may be helpful here:
https://github.com/awslabs/aws-cfn-go-template

[hashibot]

This comment was originally opened by @bobzoller as hashicorp/terraform#4335 (comment). It was migrated here as part of the provider split. The original comment is below.

---

Perhaps this is silly but it might also save someone from a headache: Don't be like me and try to work around this by adding:

lifecycle {
  ignore_changes = ["parameters.Password"]
}

All it means is that the next apply will write the **** value back to AWS (instead of your secret).

[hashibot]

This comment was originally opened by @dylanvaughn as hashicorp/terraform#4335 (comment). It was migrated here as part of the provider split. The original comment is below.

---

Maybe if the parameter name ends in NoEcho then that tells Terraform to ignore it? i.e. MasterDbPasswordNoEcho

I could implement this in a PR if it seems like an acceptable solution.

[hashibot]

This comment was originally opened by @dylanvaughn as hashicorp/terraform#4335 (comment). It was migrated here as part of the provider split. The original comment is below.

---

I ended up doing a slightly different approach of just checking if the old value of the parameter coming from AWS is **** - see hashicorp/terraform#11707

[joshma]

Any chance this issue can get some love? We have close to a hundred cloudformation templates (long story...) and each plan results in a long list of no-ops :(

[arturopie]

We are having a similar issues. I can imagine this might be a difficult bug to fix. We are debating whether to continue using bash to manage our cloudformation templates

[dan-petty]

Also, parameter values being sent to a NoEcho parameter should be marked as sensitive by the aws provider so they are not output in the terminal.

[jufemaiz]

Any love @hashibot ?

[pauldraper]

Previous efforts to solve this: #9304 #11707

The best solution is to add a "use previous value" option. I thought there was an open PR for this, but can't find it now.

Currently, I set the parameter to empty, then add ignore_changes = ["paramters.MyParam"]. I can't update the CloudFormation stack with Terraform, but I can at least see the differences.

[nijave]

Something like this scribd/terraform-aws-datadog@647e8e9 is potentially a decent workaround depending on the stack you're working with

(also still an issue)

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[dan-petty]

So it's fixed?

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.