Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't use heredoc with AWS SQS policy #4273

Closed
b-ryan opened this issue Dec 11, 2015 · 11 comments
Closed

Can't use heredoc with AWS SQS policy #4273

b-ryan opened this issue Dec 11, 2015 · 11 comments

Comments

@b-ryan
Copy link
Contributor

b-ryan commented Dec 11, 2015

When I use a heredoc, the policy always appears to have changed. Example:

resource "aws_sqs_queue" "test" {
  name = "test"

  policy = <<EOF
{
    "Version": "2012-10-17",
    "Id": "test",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {"AWS": "*"},
            "Action": "SQS: SendMessage",
            "Resource": "arn:aws:sqs:us-east-1:blahblah:test",
            "Condition": {
                "ArnEquals": {
                    "aws: SourceArn": "sns_arn"
                }
            }
        }
    ]
}
EOF
}

After creating this, terraform tells me the policy needs to change in the next plan. This appears to be due to this policy containing newline characters and spaces. I think AWS strips all whitespace characters from the policy. Doing aws sqs get-queue-attributes --attribute-names Policy --queue-url https://... gives me a policy without any whitespace characters.

I assume the fix here would be to strip whitespace from the resource.

@jen20
Copy link
Contributor

jen20 commented Dec 14, 2015

Hi @b-ryan! Thanks for reporting this - I have a feeling we are missing normalisation of the JSON as is applied in several other resources with policies - for example

- should be a straightforward fix!

@b-ryan
Copy link
Contributor Author

b-ryan commented Dec 14, 2015

Hi @jen20 -- thanks. I thought a function like that might exist. I'll try to fix this if I have some time.

@mmlb
Copy link

mmlb commented Jan 12, 2016

Chiming in that this doesn't just apply to heredoc type vars. I have a queue policy that looks like

policy = "${replace(file("some-policy-file.json"), "@ENV@", "${var.env}")}"

that also hits this.

@r39132
Copy link

r39132 commented Feb 17, 2016

Hi Folks!
This bug has been a constant irritant for our company. We use terraform (and ansible) to setup/deploy all of our infrastructure. A large part of that is setting up data pipelines based on SNS/SQS. Every time we do a terraform apply, all of our SQS pipelines break. This is a major bug!
-s

@aflury
Copy link

aflury commented Feb 17, 2016

+1 (Disclosure: I work with @r39132 ).

It seems like the fix is simple. I came up with the exact fix that @chancefeick did before noticing that he had already done so.

@rsutton1
Copy link

👍 on this (disclosure: I work with @b-ryan )

I'm currently seeing this bug when trying to get my policy in Terraform to match the policy currently in AWS. The policies are the same, however Terraform shows a policy change just because the whitespace is off. It looks like there's no way to get the whitespace to match without changing Terraform.

I set the policy in Terraform to be the same as the AWS policy, yet Terraform is giving a diff in the plan because it thinks they're different. I copied the Terraform output for the current policy and the new policy into a text file to see the difference and I see this:

$ diff current.txt new.txt
25a26
> 

As thediff shows, the only difference is that Terraform policies include an extra line break at the end. I tried to add that linebreak to the policy through the AWS console UI, but when I try to save the policy AWS automatically removes the linebreak at the end.

If Terraform could normalize JSON in the same way as AWS, this problem would be fixed.

@scheffield
Copy link

Hey there, this issue seems to be fixed since 0.6.15 (#5888). It does not occur for me anymore.

@b-ryan b-ryan closed this as completed Jun 6, 2016
@dmangot
Copy link

dmangot commented Jun 6, 2016

We're on 0.6.16 and it still tells us it's going to change the policy every single time. Maybe there is something different about what we're doing. It happens on our SQS queues.

@sepulworld
Copy link

This still appears to be an issue. On 0.6.16 and it still looks to modify SNS resources with EOF of JSON

@djosephsen
Copy link

We're still having this issue in 0.7.11. I spent some time poking at it this week and I think there are two reasons we're experiencing it.

First, terraform doesn't seem to be normalizing the json it creates from aws_iam_policy_document data sources. This is causing newline characters and indentation to creep into the schema.Resource's json field.

Second, terraform doesn't seem to be respecting the schema options on policy documents during diffing. Ie, adding DiffSuppressFunc: suppressEquivalentAwsPolicyDiffs and other options to the json schema field in the schema.Resource returned by dataSourceAwsIamPolicyDocument() doesn't affect the diff output, so terraform is showing false positives with respect to things like fields being out of order and etc when it should be using suppressEquivalentAwsPolicyDiffs to compare those fields.

I have a working fix for the first problem, which is to wrap the output of dataSourceAwsIamPolicyDocumentRead in normalizeJsonString(), and I'll PR that tonight. I'm not really sure what to do about the second problem though and I'd super-appreciate some guidance from someone who understands the diffing code-paths and might know off the top of their head what happens internally when an iam policy generated from a policy_document in the local config is compared to json gleaned from the aws api.

Thanks!

@ghost
Copy link

ghost commented Apr 18, 2020

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.

@ghost ghost locked and limited conversation to collaborators Apr 18, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

10 participants