Terraform debug log detected ✅

from terraform-provider-cloudflare.

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.

from terraform-provider-cloudflare.

what are you trying to achieve here? the configuration you've used isn't going to do anything (hence it being invalid).

from terraform-provider-cloudflare.

It does do something, it adds a disabled rule. We work with a number of brands that offer slightly different features but all use the same basic infrastructure. Until now we have been able to use cloudflare_firewall_rule resources with a

count = var.feature_enabled == true ? 1 : 0

type of ternary condition to decide which rules need to be added to the WAF ruleset for each brand.

Moving to a cloudflare_ruleset does not allow us to remove some rules from the ruleset in that way, they need to be added to all brands but disabled in the brands that don't need them. Sure, I can keep a separate list of global rules and use a dynamic {} block to include only the rules where the conditions are true but that seems unintuitive when the API should just allow me to create a disabled rule.

Also the error message is completely useless. There is nothing invalid about the JSON and the ruleset field is "known" -it's part of the spec. Cloudflare should explain why the rule cannot be added.

from terraform-provider-cloudflare.

Perhaps further to my point, and something that highlights the inconsistency between the Cloudflare Dashboard and what can be achieved with the API:

If I create the rule using terraform with the action of "skip" it succeeds. If I then go into the Dashboard and change the rule to an action of "block" and change the HCL to match, it then fails to apply.

The same thing happens if I create the rule with an action of "block" but with "enabled = true" then try to disable it with terraform.

      ~ rules {
          ~ action       = "skip" -> "block"
          ~ enabled      = false -> true

results in the same error.

Why should I not be able to toggle an existing rule with terraform?

from terraform-provider-cloudflare.

Also the error message is completely useless. There is nothing invalid about the JSON and the ruleset field is "known" -it's part of the spec.

i agree the error message could be more helpful here however, the validations aren't as straight forward as what you think is on the surface here. some actions only have certain action_parameters that are valid. for instance, you cannot just any field for a block action that may be valid for a skip action. there are some which overlap but it's not a free for all when it comes to what is supported. this is likely why you are hitting a problem swapping between the actions with the action_parameters.ruleset attribute being present.

Perhaps further to my point, and something that highlights the inconsistency between the Cloudflare Dashboard and what can be achieved with the API:

the dash and API are not 1:1. the API can handle things in their rawest form while the dash wraps some of the functionality to make it easier to visualise for end users. i suspect the way the dash is handling this is building the request from scratch for a PUT whereas the terraform side is taking the existing state (as it is designed to) into account.

cc @zakcutner who may have some more insight here.

from terraform-provider-cloudflare.

Jacob is correct—the action parameters are completely dependent on what the action is (you can think of them as arguments for the action), but this is a little tricky to express in Terraform. In the API docs, you can see that block rules and skip rules take quite different action parameters.

For your specific example, the ruleset = "current" action parameter for the skip action causes the rest of the rules in the current ruleset to be skipped. If you would like to both block the request and skip the remaining rules, you can simply use the block action. Blocking the request is a terminating action, so will cause the remainder of the rules to be skipped in any case.

from terraform-provider-cloudflare.

@jacobbednarz closing this with no action is pretty lame. There are cases that the terraform provider cannot handle - the whole point of using terraform instead of manually using the Dashboard is so it can be reapplied and so the state of the resources are what is committed in the repo. At the moment, I cannot create the same set of rules with terraform that I can with the Dash, and if I create a rule that is close to what I need then modify it in the Dash, it breaks terraform state and there is no way to recover other than delete the rule outright.

Also you acknowledged the misleading error message but don't want to fix it?

@zakcutner the issue is not about action_parameters, it is about creating a rule with action = "block" and enabled = "false" which according to the API docs you posted above, should be possible. I took your point that ruleset is not a valid action_parameter when action = "block" so I removed it and now I get a more sensible error message

Terraform will perform the following actions:

  # cloudflare_ruleset.custom-firewall-rules will be updated in-place
  ~ resource "cloudflare_ruleset" "custom-firewall-rules" {
        id      = "402d91f22dd8400c8a0b24951fa0e6c5"
        name    = "default"
        # (3 unchanged attributes hidden)

      ~ rules {
          ~ action       = "skip" -> "block"
          ~ enabled      = false -> true
          ~ id           = "c7c764a36ec641db8c5c1e340662e90d" -> (known after apply)
          ~ last_updated = "2023-12-07 02:07:58.856611 +0000 UTC" -> (known after apply)
          ~ ref          = "c7c764a36ec641db8c5c1e340662e90d" -> (known after apply)
          ~ version      = "1" -> (known after apply)
            # (2 unchanged attributes hidden)

          - action_parameters {
              - ruleset = "current" -> null
            }

          ~ logging {
              ~ enabled = true -> false
            }
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.
cloudflare_ruleset.custom-firewall-rules: Modifying... [id=402d91f22dd8400c8a0b24951fa0e6c5]
╷
│ Error: error updating ruleset with ID "402d91f22dd8400c8a0b24951fa0e6c5"
│
│   with cloudflare_ruleset.custom-firewall-rules,
│   on cloudflare-waf.tf line 1, in resource "cloudflare_ruleset" "custom-firewall-rules":
│    1: resource "cloudflare_ruleset" "custom-firewall-rules" {
│
│ logging options only allowed in the skip action (20018)
╵

Why can't the provider return a sensible error message like that telling me ruleset options only allowed in the skip action?

from terraform-provider-cloudflare.

@waddles the issue is closed as there is no action to take in the provider. the issue here is misunderstanding how the rule actions work coupled with a vague error message. the provider cannot fix either of those as at the end of the day, it is just another API client and we don't wrap or abstract service errors.

i've raised a ticket internally about the error message improvement which when/if it lands, terraform (along with every other client) will pick up automatically.

if you're struggling with how to use the ruleset engine within terraform, you're best bet is to do one of the following (depending on what is available to you):

• raise a support ticket asking for clarification on your questions; or
• head over to community.cloudflare.com or the discord for community based support; or
• inspect the HTTP payloads that the dash is making and attempt to map them to terraform attributes (they should be pretty close to 1:1) using the developer docs and registry documentation as reference.

from terraform-provider-cloudflare.