_This issue was originally opened by @rhealitycheck as hashicorp/terraform#17452. It was migrated here as a result of the provider split. The original body of the issue is below._
Terraform v0.11.2
+ provider.aws v1.8.0
+ provider.template v1.0.0
resource "aws_sqs_queue" "test_queue" {
name = "testProdQueue"
}
data "aws_iam_policy_document" "test_queue_policy" {
statement {
effect = "Allow"
principals {
identifiers = ["${var.account_id}"]
type = "AWS"
}
actions = [
"sqs:SendMessage",
"sqs:ReceiveMessage",
"sqs:DeleteMessage"
]
resources = ["${aws_sqs_queue.test_queue.arn}"]
}
}
resource "aws_sqs_queue_policy" "test_queue_policy" {
policy = "${data.aws_iam_policy_document.test_queue_policy.json}"
queue_url = "${aws_sqs_queue.test_queue.id}"
}
output "test_sqs_id" {
value = "${aws_sqs_queue.test_queue.id}"
}
I expect the plan to complete and to get a list of outputs.
I get the following error but the queue policy is actually generated and applied to my queue in AWS. I would expect that either the queue policy fails to generate and then is not applied in AWS or the policy generates and is attached and the terraform apply completes successfully. The mixed behavior is very strange.
Error: Error applying plan:
1 error(s) occurred:
* aws_sqs_queue_policy.test_queue_policy: 1 error(s) occurred:
* aws_sqs_queue_policy.test_queue_policy: SQS attribute Policy not updated
This happens when I terraform apply
@rhealitycheck can you try changing your policy principal identifiers from ["${var.account_id}"] to ["arn:aws:iam::${var.account_id}:root"] to see if that works? This resource is trying to ensure the policy has been written by verifying its equivalent to the Terraform configuration and its likely AWS is converting that particular value from the short AWS account ID form to the long ARN form.
I can confirm it works with the full ARN for the account ("arn:aws:iam::${var.account_id}:root"), so that is a workaround for your situation. I think ideally, the policy equivalence library would probably mark them as equivalent.
oh yay! that works! It's strange because a few weeks ago (probably terraform version ago) I was able to use just the account number instead of the arn. This is probably better practice anyway but was just a little confusing because the error message was so vague and the resource was applied anyway. Thanks for the help @bflad!
In previous AWS provider versions, the resource was having eventual consistency issues in our acceptance testing as sometimes updates would not propagate through SQS and it would show a difference in the policy attribute after a read (marking it needing to be re-applied). For regular Terraform users, this could mean for example that a policy might not be updated in time to accept new SNS subscriptions in the same Terraform run, requiring a second apply. The logic is in there to try and wait until the updates are propagated but "inequivalent" policies due to AWS normalizing the formatting/values are obviously a problem since you can't see why it might have happened without looking at the Terraform debug logs.
We could probably add the found and expected policies to the error or simply just bypass reporting this condition as an error even after the timeout.
I submitted the account ID vs root IAM ARN issue upstream to the policy equivalence library. I'm not sure when I'll have time to address it myself though. https://github.com/jen20/awspolicyequivalence/issues/3
@bflad I'm hitting the same issue here and the "workaround" doesn't appear to be working. I'm getting the SQS attribute Policy not updated error when applying the following config:
resource "aws_sqs_queue" "loggly" {
name = "tf-loggly"
message_retention_seconds = 345600
}
resource "aws_sqs_queue_policy" "loggly" {
queue_url = "${aws_sqs_queue.loggly.id}"
policy = <<POLICY
{
"Version": "2008-10-17",
"Id": "PolicyExample",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::${var.account_id}:root"
]
},
"Action": "SQS:SendMessage",
"Resource": "${aws_sqs_queue.loggly.arn}",
"Condition": {
"ArnLike": {
"aws:SourceArn":"arn:aws:s3:*:*:${module.audit.logging_bucket_name}"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS":"arn:aws:iam::${var.account_id}:root"
},
"Action": "SQS:*",
"Resource": "${aws_sqs_queue.loggly.arn}"
}
]
}
POLICY
}
Currently running Terraform 0.10.8 and 1.19.0 of the AWS provider. Any ideas?
Still seeing this issue on Terraform 0.11.7 and AWS provider 1.15.
I've tried using the above suggestion and using Heredoc instead of data.aws_iam_policy_document, both results in the same error.
Similar and possibly related issue with sqs_queue policies.
With this code:
data "aws_iam_policy_document" "example" {
statement {
actions = [
"sqs:*",
]
principals {
type = "*"
identifiers = ["*"]
}
resources = [
"${aws_sqs_queue.example.arn}",
]
condition {
test = "ForAllValues:ArnEquals"
variable = "aws:SourceArn"
values = [
"${aws_sns_topic.example.arn}"
]
}
}
depends_on = [
"aws_sns_topic.example",
"aws_sqs_queue.example",
]
}
resource "aws_sqs_queue_policy" "example" {
queue_url = "${aws_sqs_queue.example.id}"
policy = "${data.aws_iam_policy_document.example.json}"
}
Every plan states that a change to sqs_policy is necessary but when apply the 0 changes are applied.
The change appear as:
policy: "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Sid\":\"\",\"Effect\":\"Allow\",\"Principal\":\"*\",\"Action\":\"sqs:*\",\"Resource\":\"arn:aws:sqs:region:acct-id:example\",\"Condition\":{\"ForAllValues:ArnEquals\":{\"aws:SourceArn\":\"arn:aws:sns:region:acct-id:example"}}}]}" => "${data.aws_iam_policy_document.example.json}"
Terraform v0.11.7
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!
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!