Manage F5 BIG-IP Advanced WAF Policies with Terraform (Best Practices)

Terraform naming convention

• Use « _ » instead of “-“ in every terraform names: resource, data source, outputs…
• Any resources or data sources that are unique in your deployment can be named “this”.

resource "bigip_waf_policy" "this" {
   provider = bigip.new
   application_language = "utf-8"
   name = "/Common/scenario3"
   policy_id = "YiEQ4l1Fw1U9UnB2-mTKWA"
   template_name = "POLICY_TEMPLATE_COMPREHENSIVE"
   type = "security"
   policy_import_json = file("${path.module}/currentWAFPolicy.json")
}

• Don't repeat the resource type in the name of the resource:

do not:

resource "bigip_waf_policy" "bigip_waf_policy_myPolicy" {}

use instead:

resource "bigip_waf_policy" "myPolicy" {}

Use TFVars input files

Any files with the *.auto.tfvars suffix will automatically be loaded to populate Input Variables.

You can have multiple tfvars input files:

• One for the attack signatures (ex: signatures.auto.tfvars)
• One for the parameters (ex: parameters.auto.tfvars)
• One for the urls (ex: urls.auto.tfvars)
• ...

There is an example here.

Or you can manage all your input variables into a single tfvars file per WAF Policy.
Simply don’t put all the inputs for all WAF policies into a single consolidated file, it will be unmanageable.

Terraform State file management

First concept to have in mind is the location of the Terraform State files.

• They can be local or dedicated if you are a single operator and you can keep the terraform.tfstate file on your computer.
• or centralized and shared if you can store them in an AWS S3 bucket or an Azure storage Account.

The centralized approach is of course better if you are a team collaborating in the management of the WAF policies. Only keep in mind you should never store your terraform state files into a publicly accessible store, the terraform state file contains all the secrets!

Decompose your F5 BIG-IP Advanced WAF Policies into terraform modules

You may have tens, hundreds or even thousands of waf policies to manage.

With Terraform, you can pretty much organize the folder structure as you want to better reflect your organization, your environments, your processes…

module “policy1” {
   source               = "./myModuleLink"
   name                 = "scenario1"
   partition            = "Common"
   template_name        = "POLICY_TEMPLATE_RAPID_DEPLOYMENT"
   application_language = "utf-8"
   enforcement_mode     = "blocking"
   server_technologies  = ["Apache Tomcat", "MySQL", "Unix/Linux", "MongoDB"]
   parameters           = var.parameters
   signatures           = var.signatures
   urls                 = var.urls
}

Use with AS3

A F5 BIG-IP Advanced WAF Policy itself is not enough to protect a service. It needs to be associated with a proxy configuration. Good news, AS3 is used through the same terraform provider, so for every F5 BIG-IP, you have only one provider configuration to manage.

Manage Configuration Drifts

There may be situations where you have to make manual changes directly on your F5 BIG-IP because of a specific feature not yet implemented in the terraform provider or someone in the security department having to make urgent configuration updates.
In that case, we do not have to override the changes to reconciliate the current configuration with our latest known state.

You can ask for a JSON export of the F5 BIG-IP Advanced WAF policy directly from a F5 BIG-IP and use it as the policy_import_json argument of the bigip_waf_policy resource. Any other arguments defined in the resource overrides the same definition in the JSON payload.

For example, if you have 2 parameters P1 and P2 in your F5 BIG-IP Advanced WAF JSON policy and you have a bigip_waf_entity_parameters list with P1, P2 and P3, the terraform resource will override P1 and P2 and will add P3 in the declaration before sending it to the F5 BIG-IP.