Applying cloudflare_cloud_connector_rules resource deletes other existing ones

[fleetwoodstack]

Confirmation

• This is a bug with an existing resource and is not a feature request or enhancement. Feature requests should be submitted with Cloudflare Support or your account team.
• I have searched the issue tracker and my issue isn't already found.
• I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

Terraform 1.10.3
Cloudflare provider 4.49.1

Affected resource(s)

cloudflare_cloud_connector_rules

Terraform configuration files

resource "cloudflare_cloud_connector_rules" "storage" {
  zone_id = var.cloudflare_zone_id

  rules {
    description = "My Rule"
    enabled     = true
    expression  = "(http.request.full_uri contains \"www.mydomain.com\")"
    provider    = "azure_storage"
    parameters {
      host = "mystorage.blob.core.windows.net"
    }
  }
}

Link to debug output

n/a

Panic output

N/A

Expected output

Other existing cloud connector rules in Cloudflare (managed by terraform in separate repositories) shouldn't be deleted when this terraform is applied. It should add a new cloud connector rule with no impact on other existing rules.

Actual output

All other cloud connector rules not in the current state were deleted

Steps to reproduce

1. Create a cloud connector rule manually via the Cloudflare portal or in a separate terraform repo.
2. In your main terraform repo, apply terraform that creates a new cloud connector
3. You should notice all other existing rules are deleted

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]

this is expected behaviour as all rules are managed centrally at the zone level. all rules need to be defined in a single resource together.

[fleetwoodstack]

That's quite limiting if intended behaviour, wouldn't you agree?

What if you want to split your terraform state by your environments (e.g. live, staging) and have rules for different environments? What if you have some rules defined in terraform and some in the portal?

It means this resource is different from other cloudflare terraform resources (which can be managed across different terraform states) and is a special case.

[jacobbednarz]

it's not limiting if you understand the underlying implementation and why it exists. under the hood, it relies on the ruleset engine. see the overview at https://developers.cloudflare.com/ruleset-engine/

we don't offer a ruleset rule resource today as the current ERE architecture needs the surrounding context to make them useful. that may change in the future but no ETA or solid plans.

What if you want to split your terraform state by your environments (e.g. live, staging) and have rules for different environments?

you should use different zones at a minimum for this, not the same zone - https://developers.cloudflare.com/terraform/advanced-topics/best-practices/#use-separate-environments

What if you have some rules defined in terraform and some in the portal?

given this is the one resource, you don't want to do this and you'll be rubbing up against terraform's architecture doing so. see https://developers.cloudflare.com/terraform/advanced-topics/best-practices/#manage-terraform-resources-in-terraform