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

Permadiff on google_org_policy_policy resource #12363

Open
matalo33 opened this issue Aug 23, 2022 · 6 comments
Open

Permadiff on google_org_policy_policy resource #12363

matalo33 opened this issue Aug 23, 2022 · 6 comments

Comments

@matalo33
Copy link

matalo33 commented Aug 23, 2022

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
  • Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment.
  • If an issue is assigned to the modular-magician user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

1.2.6

Affected Resource(s)

  • google_org_policy_policy

Terraform Configuration Files

resource "google_org_policy_policy" "vm_external_ip_access" {
  name   = "organizations/${local.google_organization_id}/policies/constraints/compute.vmExternalIpAccess"
  parent = "organizations/${local.google_organization_id}"

  spec {
    rules {
      deny_all = "TRUE"
    }

    rules {
      allow_all = "TRUE"
      condition {
        expression = "resource.matchTagId('tagKeys/123', 'tagValues/456')"
        title      = "Allow when compute-external-ip tag is set to allowed"
      }
    }
  }
}

Expected behaviour

No changes

Actual behaviour

permadiff - the ordering of the two rules are continuously swapped in each plan & apply

  # google_org_policy_policy.vm_external_ip_access will be updated in-place
  ~ resource "google_org_policy_policy" "vm_external_ip_access" {
        id     = "organizations/999/policies/compute.vmExternalIpAccess"
        name   = "organizations/999/policies/constraints/compute.vmExternalIpAccess"
        # (1 unchanged attribute hidden)

      ~ spec {
            # (4 unchanged attributes hidden)

          ~ rules {
              - allow_all = "TRUE" -> null
              + deny_all  = "TRUE"

              - condition {
                  - expression = "resource.matchTagId('tagKeys/123', 'tagValues/456')" -> null
                  - title      = "Allow when compute-external-ip tag is set to allowed" -> null
                }
            }
          ~ rules {
              + allow_all = "TRUE"
              - deny_all  = "TRUE" -> null

              + condition {
                  + expression = "resource.matchTagId('tagKeys/123', 'tagValues/456')"
                  + title      = "Allow when compute-external-ip tag is set to allowed"
                }
            }
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Steps to Reproduce

  1. terraform plan
  2. terraform apply

b/300616619

@matalo33 matalo33 added the bug label Aug 23, 2022
@edwardmedia edwardmedia self-assigned this Aug 23, 2022
@matalo33
Copy link
Author

I slept on this and realised I can get the same result with only one rule. This will apply the deny rule UNLESS the tag is present.

resource "google_org_policy_policy" "vm_external_ip_access" {
  name   = "organizations/${local.google_organization_id}/policies/constraints/compute.vmExternalIpAccess"
  parent = "organizations/${local.google_organization_id}"

  spec {
    rules {
      deny_all = "TRUE"
      condition {
        expression = "!resource.matchTagId('tagKeys/123', 'tagValues/456')"
        title      = "Deny unless compute-external-ip tag is set to allowed"
      }
    }
  }
}

But unless I was doing something very wrong beforehand this still feels like a possible bug in the resource. Having multiple rules is permitted and their ordering should not matter, so far as I understand it

@edwardmedia edwardmedia added the tpgtools Issues related to the tpgtools generator label Aug 28, 2022
@slevenick
Copy link
Collaborator

Filed b/244225718

@edwardmedia edwardmedia removed the tpgtools Issues related to the tpgtools generator label Aug 30, 2022
@edwardmedia edwardmedia removed their assignment Aug 30, 2022
@nphilbrook
Copy link
Contributor

Can confirm we have started noticing this on our policies as well.

@LiuVII
Copy link

LiuVII commented Sep 20, 2023

Does the condition for this policy constraint even work for you?
With a policy defined like that (well, I have a different id and value for tag ofc), I'm getting errors for VMs that have the tag defined when trying to assign an external IP that says that the policy denies external IP and also checking the effective policy there are no conditions mentioned.

modular-magician added a commit to modular-magician/terraform-provider-google that referenced this issue Nov 22, 2024
[upstream:161220adfef1dbc0001daaad10c29a87d71ee39e]

Signed-off-by: Modular Magician <[email protected]>
modular-magician added a commit that referenced this issue Nov 22, 2024
[upstream:161220adfef1dbc0001daaad10c29a87d71ee39e]

Signed-off-by: Modular Magician <[email protected]>
@gm-ons
Copy link

gm-ons commented Dec 3, 2024

I've seen this issue recently when testing tag based conditional policy on boolean org constraints.
Terraform Version 1.9.7
GCP provider 6.7.0

@Ludovic-Emo-Pyl-Tech
Copy link

@gm-ons We are also encountering the issue with permadiff when using tag-based conditional policies on boolean organization constraints. Terraform consistently attempts to add an empty condition block to the non-tag rule, which causes unexpected behavior.

Looking forward to any insights or potential workarounds.

~ rules {
# (1 unchanged attribute hidden
+ condition {}
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants