aws-samples/aws-cudos-framework-deployment

CID Dashboards Terraform module continuously drifts due to S3 object etag value on cloudformation template file.

mcooknu opened this issue · 1 comments

The CID Dashboards module continuously drifts when applied in Terraform.

github.com/aws-samples/aws-cudos-framework-deployment//terraform-modules/cid-dashboards

It seems the etag of the S3 template file/object always changes because the bucket is using KMS encrypted files.
It seems etags and KMS encryption on s3 objects is incompatible.

From https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_object

[etag](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_object#etag) - (Optional) Triggers updates when the value changes. The only meaningful value is filemd5("path/to/file") (Terraform 0.11.12 or later) or ${md5(file("path/to/file"))} (Terraform 0.11.11 or earlier). This attribute is not compatible with KMS encryption, kms_key_id or server_side_encryption = "aws:kms", also if an object is larger than 16 MB, the AWS Management Console will upload or copy that object as a Multipart Upload, and therefore the ETag will not be an MD5 digest (see source_hash instead).

Can anything be done in this module to prevent this drift where there has to be encrypted S3 objects?

  # module.cid_dashboards.aws_cloudformation_stack.cid will be updated in-place
  ~ resource "aws_cloudformation_stack" "cid" {
        id                 = "arn:aws:cloudformation:us-east-1:REDACTED:stack/Cloud-Intelligence-Dashboards/75aREDACTEDe73af72a9c1"
        name               = "Cloud-Intelligence-Dashboards"
      ~ outputs            = {
          - "CUDOSDashboardURL"            = "https://us-east-1.quicksight.aws.amazon.com/sn/dashboards/cudos"
          - "CostIntelligenceDashboardURL" = "https://us-east-1.quicksight.aws.amazon.com/sn/dashboards/cost_intelligence_dashboard"
          - "KPIDashboardURL"              = "https://us-east-1.quicksight.aws.amazon.com/sn/dashboards/kpi_dashboard"
        } -> (known after apply)
        tags               = {
            "Environment"      = "Production"
        }
      ~ template_url       = "https://cudos-cur-gdo-common.s3.us-east-1.amazonaws.com/cudos-cfn.yml?etag=083733e6REDACTED9f64cbe0aa7" -> (known after apply)
        # (6 unchanged attributes hidden)
    }

  # module.cid_dashboards.aws_s3_object.template will be updated in-place
  ~ resource "aws_s3_object" "template" {
      ~ etag                   = "083733e6REDACTED64cbe0aa7" -> "c9e154137b1eREDACTEDf67d4b59"
        id                     = "cudos-cfn.yml"
        tags                   = {}
      ~ version_id             = "RcVKNvmdOKfREDACTED7nBpHyYwiXJz" -> (known after apply)
        # (11 unchanged attributes hidden)
    }

If I dont add etag to the S3 bucket object that is the cloudfront template file... then I am met with this error after the first successful apply

module.cid_dashboards.aws_s3_object.template: Modifications complete after 1s [id=cudos-cfn.yml]
╷
│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for module.cid_dashboards.aws_cloudformation_stack.cid to include new values learned so far during apply,
│ provider "registry.terraform.io/hashicorp/aws" produced an invalid new value for .template_url: was
│ cty.StringVal("https://cudos-cur-gdo-common.s3.us-east-1.amazonaws.com/cudos-cfn.yml?etag=91e3348affREDACTEDffeac83285dc"), but
│ now cty.StringVal("https://cudos-cur-gdo-common.s3.us-east-1.amazonaws.com/cudos-cfn.yml?etag=aee9a93caREDACTEDee22d2421").
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵

Hello, @mcooknu. Thanks for bringing this to our attention. I've confirmed this bug in the Terraform module and am currently working on a fix.