Seeing drift while running terraform apply for firewall rules

[asagrati]

Confirmation

• My issue isn't already found on the issue tracker.
• I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

Hello team,
our Terraform configuration for smooch.io zone, 1f78bac08ff99d5ef8455537f554870e id, has some cloudflare_firewall_rule like attached one, but when we run terraform plan we see the priority being changed to null (for it and any other ones), for example:

cloudflare_firewall_rule.rule-number will be updated in-place

~ resource "cloudflare_firewall_rule" "rule-number" {
id = "e823cbe16e324f308c85f16c3fc137d6"

• priority = 5000 -> null

(6 unchanged attributes hidden)

}

This behaviour seems to be happening using both 4.6 and 4.17 versions of the provider. I wonder if there’s anything that changed since this does not happen for other zones that use an older provider version?
Let us know if you need anything else from us.
Thank you,
Alessandro

Affected resource(s)

cloudflare_firewall_rule

Terraform configuration files

resource "cloudflare_firewall_rule" "rule-name" {
  zone_id     = local.cloudflare_zone_id
  description = "Challenge okhttp/3.8.0 UA on whatever root path /"
  filter_id   = cloudflare_filter.rule-name.id
  action      = "challenge"
}

Link to debug output

Gist

Panic output

No response

Expected output

We assumed rule priority wouldn't change

Actual output

cloudflare_firewall_rule.rule-number will be updated in-place

~ resource "cloudflare_firewall_rule" "rule-number" {
id = "e823cbe16e324f308c85f16c3fc137d6"

• priority = 5000 -> null

(6 unchanged attributes hidden)

}

Steps to reproduce

The steps to reproduce are simply to run a terraform plan on file that contains cloudflare_firewall_rule: it will try to modify the priority even though the value was not changed

Additional factoids

No response

References

No response

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[github-actions]

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.

This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

[jacobbednarz]

thanks for the issue and sorry to hear you're hitting an issue.

looking at your debug output, you can see the API is responding with the priority field in the API response.

GET /client/v4/zones/1f78bac08ff99d5ef8455537f554870e/firewall/rules/e823cbe16e324f308c85f16c3fc137d6 HTTP/1.1
Host: api.cloudflare.com
User-Agent: terraform-provider-cloudflare/4.17.0 terraform-plugin-sdk/2.29.0 terraform/1.4.6
Authorization: Bearer [redacted]
Content-Type: application/json
Accept-Encoding: gzip
 
2023/10/26 10:08:20 
HTTP/2.0 200 OK
Cf-Cache-Status: DYNAMIC
Cf-Ray: 81c135f319f353a0-LHR
Content-Type: application/json; charset=UTF-8
Date: Thu, 26 Oct 2023 08:08:20 GMT
Server: cloudflare
Set-Cookie: __cflb=0H28vgHxwvgAQtjUGUSTLLCMLmdTy1vPqraVkK6ugLD; SameSite=Lax; path=/; expires=Thu, 26-Oct-23 10:38:21 GMT; HttpOnly
Set-Cookie: __cfruid=dc407b86b1c6ee4ab0db8b9bf06f48cf4dfb462e-1698307700; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
Vary: Accept-Encoding
X-Envoy-Upstream-Service-Time: 45

{
  "result": {
    "id": "e823cbe16e324f308c85f16c3fc137d6",
    "paused": false,
    "description": "Challenge okhttp/3.8.0 UA on huobiglobal root path /",
    "action": "challenge",
    "ref": "675668ff6cb9404bbf099ba2a727b578",
    "priority": 5000,
    "filter": {
      "id": "4a51f612436946688fc2460a5e419b05",
      "expression": "(http.host eq \"huobiglobal.zendesk.com\" and http.request.uri.path eq \"/\" and http.user_agent eq \"okhttp/3.8.0\")\n",
      "paused": false,
      "description": "Challenge okhttp/3.8.0 UA on huobiglobal root path /"
    },
    "created_on": "2023-06-16T14:08:52Z",
    "modified_on": "2023-10-16T09:09:09Z"
  },
  "success": true,
  "errors": [],
  "messages": []
}

which aligns with what terraform is saying your configuration has drifted from (because you've not defined it).

# cloudflare_firewall_rule.rule-number will be updated in-place
~ resource "cloudflare_firewall_rule" "rule-number" {
id = "e823cbe16e324f308c85f16c3fc137d6"
- priority = 5000 -> null
# (6 unchanged attributes hidden)
}

to me, this suggests you (or someone with access to your zone) has either swapped the rules into priority mode or you've gone over the threshold for implicitly firewall rules and now all firewall rules will be explicitly prioritised - see https://developers.cloudflare.com/firewall/cf-firewall-rules/order-priority/ for an overview of this process.

this isn't a bug with the provider and you'll need to rectify this in your configuration. you can either 1) revert the change to using an ordered list (if you haven't crossed the threshold) or 2) you can add the property to your HCL and apply/or import it to get it back into sync.

on its own your reproduction case doesn't show this issue and can be easily verified by running the provider test suite or this example.

terraform {
  required_providers {
    cloudflare = {
      source = "cloudflare/cloudflare"
    }
  }
}

provider "cloudflare" {}

resource "cloudflare_firewall_rule" "example" {
  zone_id     = var.cloudflare_zone_id
  description = "Challenge okhttp/3.8.0 UA on whatever root path /"
  filter_id   = cloudflare_filter.example.id
  action      = "challenge"
}

resource "cloudflare_filter" "example" {
  zone_id     = var.cloudflare_zone_id
  description = "Wordpress break-in attempts that are outside of the office"
  expression  = "true"
}

$ terraform apply -auto-approve

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # cloudflare_filter.example will be created
  + resource "cloudflare_filter" "example" {
      + description = "Wordpress break-in attempts that are outside of the office"
      + expression  = "true"
      + id          = (known after apply)
      + zone_id     = "0da42c8d2132a9ddaf714f9e7c920711"
    }

  # cloudflare_firewall_rule.example will be created
  + resource "cloudflare_firewall_rule" "example" {
      + action      = "challenge"
      + description = "Challenge okhttp/3.8.0 UA on whatever root path /"
      + filter_id   = (known after apply)
      + id          = (known after apply)
      + zone_id     = "0da42c8d2132a9ddaf714f9e7c920711"
    }

Plan: 2 to add, 0 to change, 0 to destroy.
cloudflare_filter.example: Creating...
cloudflare_filter.example: Creation complete after 2s [id=d6405f15cb8744a4b2b7455a8d513936]
cloudflare_firewall_rule.example: Creating...
cloudflare_firewall_rule.example: Creation complete after 1s [id=c445de1d1732476b84f2285e838eae76]
╷
│ Warning: Deprecated Resource
│ 
│   with cloudflare_firewall_rule.example,
│   on terraform.tf line 18, in resource "cloudflare_firewall_rule" "example":
│   18: resource "cloudflare_firewall_rule" "example" {
│ 
│ `cloudflare_firewall_rule` resource is in a deprecation phase that will
│ last for one year (May 1st, 2024). During this time period, this
│ resource is still fully supported but you are strongly advised
│ to move to the `cloudflare_ruleset` resource. For more information, see
│ https://developers.cloudflare.com/waf/reference/migration-guides/firewall-rules-to-custom-rules/#relevant-changes-for-terraform-users.
│ 
│ 
│ (and 5 more similar warnings elsewhere)
╵

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

$ terraform apply -auto-approve
cloudflare_filter.example: Refreshing state... [id=d6405f15cb8744a4b2b7455a8d513936]
cloudflare_firewall_rule.example: Refreshing state... [id=c445de1d1732476b84f2285e838eae76]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.
╷
│ Warning: Deprecated Resource
│ 
│   with cloudflare_firewall_rule.example,
│   on terraform.tf line 18, in resource "cloudflare_firewall_rule" "example":
│   18: resource "cloudflare_firewall_rule" "example" {
│ 
│ `cloudflare_firewall_rule` resource is in a deprecation phase that will
│ last for one year (May 1st, 2024). During this time period, this
│ resource is still fully supported but you are strongly advised
│ to move to the `cloudflare_ruleset` resource. For more information, see
│ https://developers.cloudflare.com/waf/reference/migration-guides/firewall-rules-to-custom-rules/#relevant-changes-for-terraform-users.
│ 
│ 
│ (and 3 more similar warnings elsewhere)
╵

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

as this isn't a bug, i'm going to close this off as there isn't any action for us to take further here but let me know if you still have any follow up questions.