Terraform-provider-aws: aws_kms_key is being modified on every run

[hashibot]

_This issue was originally opened by @FransUrbo as hashicorp/terraform#10467. It was migrated here as part of the provider split. The original body of the issue is below._

---

Terraform Version

0.7.13

Affected Resource(s)

• aws_kms_key

Terraform Configuration Files

resource "aws_kms_key" "my_kms_key" {
  description                 = "My KMS Key"
  enable_key_rotation         = "true"
  policy                      = <<HEREDOC
{
    [my policy]
}
HEREDOC
}

Expected Behavior

Creating the resource on the first run, nothing on subsequent runs.

Actual Behavior

Resource is modified every time, even though no changes to it have been done.

module.core-main.aws_kms_key.my_kms_key: Modifying...
  policy: "{[my policy]\n}\n"
module.core-main.aws_kms_key.my_kms_key: Modifications complete

Steps to Reproduce

1. terraform apply

[PLaRoche]

Any progress on this? I'm hitting this issue now with Terraform v0.11.2

[erindatkinson]

we are hitting this as well on 0.11.2

[bflad]

Can someone please provide example configurations (with sensitive information redacted)? We'll need to see the policy structures to determine why the resource wants to change them. Thanks!

[FransUrbo]

It doesn't happen for me any more, but that's because I specifically changed the "order of things" in the policy.

Looking at what TF wanted to do and what my policy looked like, I rearranged all the values and lines so that mine looked like what TF wanted to do and that stoped this from happening again. Now I just copy-and-paste stuff, so I haven't had this in a very long time.

But I'm seeing the same problem in many different policy documents. TF is very picky of the order and if you don't get that right, TF wants to modify the record.

[bflad]

We have implemented in some resources within the provider, but not all, ways to prevent most policy equivalency issues. I'd suggest providing specific examples for specific resources (new issues if they aren't this aws_kms_key resource).

"order of things" in the policy

This sounds like an attribute is missing DiffSuppressFunc: suppressEquivalentAwsPolicyDiffs, (or even the partial fix of suppressEquivalentJsonDiffs)

[shulima]

FWIW, I've just run into this problem with aws_kms_key and the culprit turned out to be an omitted Version key. Without it, the policy was recreated every run. Explicitly adding Version fixed the issue.

[thnee]

We are getting the same problem, even when using aws_iam_policy_document.

When comparing the documents verbatim there are plenty of differences to the order of all the keys in each Statement object, but that should generally be handled by the DiffSupressFun as I understand it?

If it is true that the diff supression function should apply in general, and I am still seeing this issue, perhaps the problem is that the order of the items in the Principal list is different? That's the only reason I can think of, after comparing the documents manually line by line.

Hashicorp, please confirm:

• Which diff supression function applies when using policy = "${data.aws_iam_policy_document.my_document.json}" on an aws_kms_key?
• Exactly how does that function work for the different aspects of the document?
  
  
  
  • How does it deal with different order of items in Action?
  
  
  • How does it deal with different order of items in Principal?
  
  
  • How does it deal with different order of items in Resource?
  
  
  • How does it deal with different order of keys in each Statement?
  
  
  • How does it deal with different order of keys in the root level object?
  
  

These things need to be clarified and documented if we are going to stand a chance to deal with this. Otherwise it's like boxing blindfolded. Our policy is 200 lines long, all I know is that some part is considered different, but not which part..

$ terraform --version
Terraform v0.11.8
+ provider.aws v1.32.0

[github-actions[bot]]

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!

[hashibot[bot]]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!