aws_vpc_endpoint policy being seen as "modified" on every terraform run

[nwalke]

I have an aws_vpc_endpoint configured with a policy and any time I run terraform plan or apply, it wants to modify the endpoint. Here's my configuration:

resource "aws_vpc_endpoint" "private-s3" {
    vpc_id = "${aws_vpc.main.id}"
    service_name = "com.amazonaws.us-west-2.s3"
    route_table_ids = ["${aws_route_table.priv1.id}", "${aws_route_table.priv2.id}"]
    policy = <<POLICY
{
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::${var.client}-codedeploy"
        },
}
POLICY
}

Since I am not altering the policy between each plan or apply, I would assume that it would not modify the resource.

[stack72]

@nwalke by any chance is the change showing that SID was added or the policy reordered?

I was looking at a similar issue with @jen20 a week or so back and we found that the AWS API will actually reorder the contents of a policy

[nwalke]

Different runs of plan show the exact same policy. If I actually run an apply, it shows the exact same policy block and doesn't mention anything else changing.

[catsby]

Can you share the plan output (minus any secrets)?
I can't seem to get a valid VPC Endpoint Policy ... I tried what you have and I get error saying it's not valid (I changed Resource to Resource: *)

[nwalke]

@catsby I may have redacted too much in my first post for it to be valid. Here's my plan output: https://gist.github.com/nwalke/901bb7059b83e30d1592

[catsby]

nvm, found my issue.
The issue here seems to be missing Sid and Version.

Here's the plan I got after initial apply:

~ aws_vpc_endpoint.private-s3
    policy: "{\"Statement\":[{\"Action\":\"*\",\"Effect\":\"Allow\",\"Principal\":\"*\",\"Resource\":\"*\",\"Sid\":\"\"}],\"Version\":\"2008-10-17\"}" => "{\"Statement\":[{\"Action\":\"*\",\"Effect\":\"Allow\",\"Principal\":\"*\",\"Resource\":\"*\"}]}"

Which breaks down to these, in the state:

{
  "Statement": [
    {
      "Action": "*",
      "Effect": "Allow",
      "Principal": "*",
      "Resource": "*",
      "Sid": ""
    }
  ],
  "Version": "2008-10-17"
}

and what it's trying to change it to (matching the config):

{
  "Statement": [
    {
      "Action": "*",
      "Effect": "Allow",
      "Principal": "*",
      "Resource": "*"
    }
  ]
}

So, AWS is adding the Sid and the Version. So, changing your resource to this:

resource "aws_vpc_endpoint" "private-s3" {
    vpc_id = "${aws_vpc.default.id}"
    service_name = "com.amazonaws.us-west-2.s3"
    route_table_ids = ["${aws_route_table.priv1.id}", "${aws_route_table.priv2.id}"]
    policy = <<POLICY
{
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "*",
            "Resource": "*",
            "Sid":""
        }
  ],
  "Version": "2008-10-17"
}
POLICY
}

breaks the plan loop. Note that I have Resource: * there, you'll need to swap that out with your value.

Hope that helps!

[catsby]

Ah, so in your case, the thing I notice is missing Version and Sid again

[nwalke]

Do I need to add the Sid field for every statement?

[stack72]

@nwalke yes, that then makes it a valid Policy according to AWS API

[nwalke]

That did the trick. Thanks guys!

[apparentlymart]

Hmmm... I've not seen this particular validation issue on other IAM policy attributes. Does the AWS API do different IAM policy normalization for different objects? If so, that's a rather awkward constraint that #3124 didn't consider. 😞

[stack72]

@apparentlymart yes. Different types of systems have different policy structure requirements (from experience) - S3 bucket policy acted completely differently for me than IAM policies

[ghost]

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.