Deploying Wallarm on AWS using Terraform¶
Wallarm provides the Terraform module to deploy the node to AWS from the Terraform-compatible environment. Use these instructions to explore the module and try the provided deployment examples.
By implementing the Wallarm Terraform module, we have provided the solution enabling two core Wallarm deployment options: in-line (which is proxy in this deployment method) and Out‑of‑band (mirror) security solutions. The deployment option is easily controlled by the preset
Wallarm module variable.
Use cases¶
Among all supported Wallarm deployment options, Terraform module is recommended for Wallarm deployment in these use cases:
-
Your existing infrastructure resides on AWS.
-
You leverage the Infrastructure as Code (IaC) practice. Wallarm's Terraform module allows for the automated management and provisioning of the Wallarm node on AWS, enhancing efficiency and consistency.
Requirements¶
-
Terraform 1.0.5 or higher installed locally
-
Access to the account with the Administrator role in Wallarm Console in the US or EU Cloud
-
Access to
https://us1.api.wallarm.com
if working with US Wallarm Cloud or tohttps://api.wallarm.com
if working with EU Wallarm Cloud. Please ensure the access is not blocked by a firewall -
Access to the IP addresses below for downloading updates to attack detection rules and API specifications, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers
This topic does not include instructions for creating all AWS resources necessary to deploy Wallarm, such as a VPC cluster. For details, refer to the relevant Terraform guide.
How to use the Wallarm AWS Terraform Module?¶
To deploy Wallarm for production using the AWS Terraform module:
-
Open Wallarm Console → Nodes and create the node of the Wallarm node type.
-
Copy the generated node token.
-
Add the
wallarm
module code to your Terraform configuration: -
Set variable values in the
wallarm
module configuration:
Variable | Description | Type | Required? |
---|---|---|---|
instance_type | Amazon EC2 instance type to be used for the Wallarm deployment, e.g.: t3.small . | string | Yes |
vpc_id | ID of the AWS Virtual Private Cloud to deploy the Wallarm EC2 instance to. | string | Yes |
token | Wallarm node token copied from the Wallarm Console UI. Using one token for several installations You can use one token in several installations regardless of the selected platform. It allows logical grouping of node instances in the Wallarm Console UI. Example: you deploy several Wallarm nodes to a development environment, each node is on its own machine owned by a certain developer. | string | Yes |
Wallarm-specific variables | |||
host | Wallarm API server. Possible values:
api.wallarm.com . | string | No |
upstream | The Wallarm node version to be deployed. Minimum supported version is 4.0 .By default, 4.8 . | string | No |
preset | Wallarm deployment scheme. Possible values:
proxy . | string | No |
proxy_pass | Proxied server protocol and address. Wallarm node will process requests sent to the specified address and proxy legitimate ones to. As a protocol, 'http' or 'https' can be specified. The address can be specified as a domain name or IP address, and an optional port. | string | Yes, if preset is proxy |
mode | Traffic filtration mode. Possible values: off , monitoring , safe_blocking , block .By default, monitoring . | string | No |
libdetection | Whether to use the libdetection library during the traffic analysis. By default, true . | bool | No |
global_snippet | Custom configuration to be added to the NGINX global configuration. You can put the file with the configuration to the Terraform code directory and specify the path to this file in this variable. You will find the variable configuration example in the example of the proxy advanced solution deployment. | string | No |
http_snippet | Custom configuration to be added to the http configuration block of NGINX. You can put the file with the configuration to the Terraform code directory and specify the path to this file in this variable.You will find the variable configuration example in the example of the proxy advanced solution deployment. | string | No |
server_snippet | Custom configuration to be added to the server configuration block of NGINX. You can put the file with the configuration to the Terraform code directory and specify the path to this file in this variable.You will find the variable configuration example in the example of the proxy advanced solution deployment. | string | No |
post_script | Custom script to be run after the Wallarm node initialization script (cloud-init.py ). You can put the file with any script to the Terraform code directory and specify the path to this file in this variable.You will find the variable configuration example in the example of the proxy advanced solution deployment. | string | No |
AWS deployment configuration | |||
app_name | Prefix for the AWS resource names the Wallarm module will create. By default, wallarm . | string | No |
app_name_no_template | Whether to use upper-case letters, numbers and special characters in the AWS resource names the Wallarm module will create. If false , resource names will include only lower-case letters.By default, false . | bool | No |
lb_subnet_ids | List of AWS Virtual Private Cloud subnets IDs to deploy an Application Load Balancer in. The recommended value is public subnets associated with a route table that has a route to an internet gateway. | list(string) | No |
instance_subnet_ids | List of AWS Virtual Private Cloud subnets IDs to deploy Wallarm EC2 instances in. The recommended value is private subnets configured for egress-only connections. | list(string) | No |
lb_enabled | Whether to create an AWS Application Load Balancer. A target group will be created with any value passed in this variable unless a custom target group is specified in the custom_target_group variable.By default, true . | bool | No |
lb_internal | Whether to make an Application Load Balancer an internal load balancer. By default, an ALB has the internet-facing type. If using the asynchronous approach to handle connections, the recommended value is true .By default, false . | bool | No |
lb_deletion_protection | Whether to enable protection for an Application Load Balancer to be prevented from being deleted accidentally. For production deployments, the recommended value is true .By default, true . | bool | No |
lb_ssl_enabled | Whether to negotiate SSL connections between a client and an Application Load Balancer. If true , the lb_ssl_policy and lb_certificate_arn variables are required. Recommended for production deployments.By default, false . | bool | No |
lb_ssl_policy | Security policy for an Application Load Balancer. | string | Yes, if lb_ssl_enabled is true |
lb_certificate_arn | Amazon Resource Name (ARN) of an AWS Certificate Manager (ACM) certificate. | string | Yes, if lb_ssl_enabled is true |
custom_target_group | Name of existing target group to attach to the created Auto Scaling group. By default, a new target group will be created and attached. If the value is non-default, AWS ALB creation will be disabled. | string | No |
inbound_allowed_ip_ranges | List of source IPs and networks to allow inbound connections to Wallarm instances from. Please keep in mind that AWS masks load balancer traffic even if it is originated from public subnets. By default:
| list(string) | No |
outbound_allowed_ip_ranges | List of source IPs and networks to allow Wallarm instance outbount connections to. By default: "0.0.0.0/0" . | list(string) | No |
extra_ports | List of internal network extra ports to allow inbound connections to Wallarm instances from. The configuration will be applied to a security group. | list(number) | No |
extra_public_ports | List of public network extra ports to allow inbound connections to Wallarm instances from. | list(number) | No |
extra_policies | AWS IAM policies to be associated with the Wallarm stack. Can be helpful to use together with the post_script variable running the script that requests data from Amazon S3. | list(string) | No |
source_ranges | List of source IPs and networks to allow an AWS Application Load Balancer traffic from. By default, "0.0.0.0/0" . | list(string) | No |
https_redirect_code | Code for HTTP request redirection to HTTPS. Possible values:
0 . | number | No |
asg_enabled | Whether to create an AWS Auto Scaling group. By default, true | bool | No |
min_size | Minimum number of instances in the created AWS Auto Scaling group. By default, 1 . | number | No |
max_size | Maximum number of instances in the created AWS Auto Scaling group. By default, 3 . | number | No |
desired_capacity | Inital number of instances in the created AWS Auto Scaling group. Must be greater than or equal to min_size and less than or equal to max_size .By default, 1 . | number | No |
autoscaling_enabled | Whether to enable Amazon EC2 Auto Scaling for the Wallarm cluster. By default, false . | bool | No |
autoscaling_cpu_target | Average CPU utilization percentage to keep the AWS Auto Scaling group at. By default, 70.0 . | string | No |
ami_id | ID of Amazon Machine Image to be used for the Wallarm instance deployment. By default (empty string), the latest image from upstream is used. You are welcome to create the custom AMI based on the Wallarm node. | string | No |
key_name | Name of AWS key pair to be used to connect to the Wallarm instances via SSH. By default, SSH connection is disabled. | string | No |
tags | Tags for AWS resources the Wallarm module will create. | map(string) | No |
Trying Wallarm Terraform Module with examples¶
We have prepared examples of different ways to use the Wallarm module, so you could try it before deploying it to production:
Further information about Wallarm and Terraform¶
Terraform supports a number of integrations (providers) and ready-to-use configurations (modules) available to users via the public registry, populated by a number of vendors.
To this registry, Wallarm published:
-
The Wallarm module to deploy the node to AWS from the Terraform-compatible environment. Described in the current article.
-
The Wallarm provider for managing Wallarm via Terraform.
These two are an independent elements used for different purposes, do not require each other.
Limitations¶
- Credential stuffing detection is currently unsupported