Terraform For Barracudawaf "Components", `resource "barracuda_component"`

as a BarracudaWaaS admin I want to manage all barracudawaas configuration as Infrastructure As Code so that Waf configuration changes can have their life cycles carefully managed (peer iac code review, git ops, etc)

for the sake of example, here is a specific component that is missing: request_rewrite

This is an EXAMPLE of a component who's configuration is required to produce IAC for barracudawaf that is currently missing. This Github Issue is reporting that Many barracudawaf components are currently missing from the barracuda waf terraform provider.

An example Component is "request_rewrite".

Reproduce Steps:

Create a new Barracuda Application
Add the Snapshots Component
Export the current configuration.

this snapshot will include a default-enabled component "request_rewrite", which includes a rule that cannot be deleted for anti-lockout reasons like this one:

{
  "endpoints": "...",
  "request_rewrite": 
      "rules": [
          {
            "name": "Host_Header_for_Testing",
            "sequence_number": 3,
            "action": "Rewrite Header",
            "header": "Host",
            "rewrite_value_type": "constant",
            "old_value": "appXXXXXX.prod.cudawaas.com",
            "rewrite_value": "example.com",
            "condition": "*",
            "continue_processing": true,
            "comments": "This rule allows you to access your application using its endpoint URL, without changing DNS records."
          },
          "...",
        ],
        "...": "..."
    },
  "response_body_rewrite": "...",
  "response_rewrite": "...",
  "servers": "...",
  "trusted_hosts": "...",
  "url_translation": "...",
  "website_profile": "..."
}

in particular, a critical step in deploying a barracudawaf test site is configuring this host header to match what a live site expects. For example lets say the live site is presently api.example.com and we have passed control of api2.example.com to barracudawas as a cname. To complete this test it is required to installing a similar rewrite rule after this rewrite rule to specify the correct backend host header "api.example.com" as the app will reject all traffic using the barracuda-hard-rule that matches the domain name associated with the site "api2.example.com"

Preferences note, I would be very happy with a single resources that represented the entire barracudawaf configuration; compatible with the snapshot export/import tool. Manipulating json documents in terraform is well-supported and likely eliminates a great portion of the golang resource state complexity.

Hopefully this servers as a sufficient example to indicate that presently "request_rewrite" is missing from the barracudawaf terraform provider, as best as I can tell, as are several other components. I suspected currently all component configuration is missing.

This is extremely concerning to me as Barracuda docs explicitly clarify, that actions taken in the barracuda console are irreversible and applied immediately.

I would strongly prefer if the compensating control for the webapp being very risky to interact with, with that an official and complete terraform project provided simple and obvious tools to install configuration from IAC, who's configuration changes can be peer-reviewed in advance of applying, and who's specific apply time can be controlled through customer's organizational code gates such as git-ops approvals. Rather than requiring an Administrator to click very carefully on a specific change set as rapidly as possible, and the site to have moment-to-moment configuration differences as barracudawafa auto-deploy partial changes mid-Operator click-set.

Did I misunderstand the documentation and examples and source code herein? I am okay pivoting this issue to a documentation-issue if it turns out these features are present but undocumented.

barracudanetworks / terraform-provider-barracudawaf