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

"terraform refresh" not picking up changes to policy text #47

Closed
hashibot opened this issue Jun 13, 2017 · 7 comments
Closed

"terraform refresh" not picking up changes to policy text #47

hashibot opened this issue Jun 13, 2017 · 7 comments
Labels
bug Addresses a defect in current functionality.

Comments

@hashibot
Copy link

This issue was originally opened by @jgross206 as hashicorp/terraform#3517. It was migrated here as part of the provider split. The original body of the issue is below.


If a Terraform-managed policy is modified via Web console, the changes are not picked up on terraform refresh so they are not corrected on next terraform apply

Repro:

  • create a new configuration with the following in policies.tf:
provider "aws" {
  # access_key and secret_key should be set using "aws configure"
  region = "us-west-2"
}

resource "aws_iam_policy" "test" {
  name  = "test-policy"
  description = "A test policy"
  policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "glacier:ListVaults",
        "glacier:DescribeVault",
        "glacier:GetVaultNotifications",
        "glacier:ListJobs",
        "glacier:DescribeJob",
        "glacier:GetJobOutput"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}
EOF
}
  • run terraform plan then terraform apply. The policy should be created.
  • log in to the web console and modify the policy text, e.g. change "Allow" to "Deny"
  • go back to the terminal and run terraform refresh
  • Expected: the change should be noticed and updated into the state file. The next terraform apply should change the policy back to the one existing in our .tf file.
  • Actual: no changes are detected. Subsequent terraform plan terraform apply succeed but the policy in AWS does not match the policy in source.

Happy to provide any more information needed.

@hashibot hashibot added the bug Addresses a defect in current functionality. label Jun 13, 2017
@hashibot
Copy link
Author

This comment was originally opened by @mroark1m as hashicorp/terraform#3517 (comment). It was migrated here as part of the provider split. The original comment is below.


I can confirm this issue, seeing the same thing.

@hashibot
Copy link
Author

This comment was originally opened by @mattpminer as hashicorp/terraform#3517 (comment). It was migrated here as part of the provider split. The original comment is below.


I can confirm as well.

@hashibot
Copy link
Author

This comment was originally opened by @jgross206 as hashicorp/terraform#3517 (comment). It was migrated here as part of the provider split. The original comment is below.


In fact, this issue is even worse. If a "terraform apply" of a modified AWS policy fails

(e.g. with

  • aws_iam_policy.datadog: Error updating IAM policy [REDACTED]: MalformedPolicyDocument: Syntax errors in policy.
    status code: 400, request id: [REDACTED]
    )

Then subsequent "terraform plan" will say "No changes. Infrastructure is up-to-date." even though the infrastructure is decidedly not up-to-date.

@hashibot
Copy link
Author

This comment was originally opened by @Ehekatl as hashicorp/terraform#3517 (comment). It was migrated here as part of the provider split. The original comment is below.


confirm this problem as well
I have two s3 policy and one never change, but another one change every time as mentioned in #4948
how could it be...

@artburkart
Copy link
Contributor

artburkart commented Jun 18, 2017

I no longer see this for aws_iam_policy behavior in the latest version of the provider.
I used this:

resource "aws_iam_policy" "policy" {
  name        = "test_policy"
  path        = "/"
  description = "My test policy"

  policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:Describe*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}
EOF
}

Went into Console and changed "Allow" to "Deny", then did a terraform plan. Here is my output:

~ aws_iam_policy.policy
    policy: "{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Action\": [\n                \"ec2:Describe*\"\n            ],\n            \"Effect\": \"Deny\",\n            \"Resource\": \"*\"\n        }\n    ]\n}" => "{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Action\": [\n        \"ec2:Describe*\"\n      ],\n      \"Effect\": \"Allow\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n"

It wants to change "Deny" back to "Allow". And just to make sure there isn't any diffing problem here, I change my tf conf to say "Deny" instead of "Allow" and the terraform plan comes back clean.

If I'm not mistaken, I believe it was fixed by @tomwilkie when they implemented the aws_iam_policy import functionality here: hashicorp/terraform#9398 (comment). In that PR, the code starts taking the policy version into account and reading the policy back from AWS, which is the reason I think the diff wasn't getting picked up originally.

I believe this also addresses @jgross206 because I can't seem to repro it.
As for @Ehekatl's comment, if it still exists, then it should be reported in a different issue, since it doesn't use the same terraform resource.

@radeksimko
Copy link
Member

Hi everyone,
@artburkart is right - I just verified this issue doesn't exist anymore (i.e. was fixed) in the latest provider version. It's very likely it was fixed a while back, so please try upgrading and let us know if the problem persists.

With that I'm closing this issue.
Thanks for reporting it.

@ghost
Copy link

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

@ghost ghost locked and limited conversation to collaborators Apr 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Addresses a defect in current functionality.
Projects
None yet
Development

No branches or pull requests

3 participants