Running Docker NGINX‑based Image¶

The Wallarm NGINX-based filtering node can be deployed using a Docker image. This node supports both x86_64 and ARM64 processor operating systems, which are automatically identified during installation. This article provides guidance on how to run the node from the Docker image.

The Docker image is based on Alpine Linux and the NGINX version provided by Alpine. Currently, the latest image uses Alpine Linux version 3.20, which includes NGINX stable 1.26.2.

Use cases¶

Among all supported Wallarm deployment options, NGINX-based Docker image is recommended for Wallarm deployment in these use cases:

• If your organization utilizes Docker-based infrastructure, Wallarm Docker image is the ideal choice. It integrates effortlessly into your existing setup, whether you are employing a microservice architecture running on AWS ECS, Alibaba ECS, or other similar services. This solution also applies to those using virtual machines seeking a more streamlined management through Docker containers.

• If you require fine-grained control over each container, the Docker image excels. It affords a greater level of resource isolation than typically possible with traditional VM-based deployments.

For more information on running Wallarm's NGINX-based Docker image on popular public cloud container orchestration services, refer to our guides: AWS ECS, GCP GCE, Azure Container Instances, Alibaba ECS.

Requirements¶

• Docker installed on your host system

• Access to https://hub.docker.com/r/wallarm/node to download the Docker image. Please ensure the access is not blocked by a firewall

• Access to the account with the Administrator role in Wallarm Console in the US Cloud or EU Cloud

• Access to https://us1.api.wallarm.com if working with US Wallarm Cloud or to https://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

  US CloudEU Cloud

  34.96.64.17
  34.110.183.149
  35.235.66.155
  

  34.160.38.183
  34.144.227.90
  34.90.110.226
  

Options for running the container¶

The filtering node configuration parameters should be passed to the deployed Docker container in one of the following ways:

• In the environment variables. This option allows for the configuration of only basic filtering node parameters. Most directives cannot be configured through environment variables.

• In the mounted configuration file. This option allows full filtering node configuration via any directives. With this configuration method, environment variables with the filtering node and Wallarm Cloud connection settings are also passed to the container.

Run the container passing the environment variables¶

To run the container:

1. Get Wallarm token of the appropriate type:

   API tokenNode token

   1. Open Wallarm Console → Settings → API tokens in the US Cloud or EU Cloud.
   2. Find or create API token with the Deploy source role.
   3. Copy this token.

   1. Open Wallarm Console → Nodes in the US Cloud or EU Cloud.
   2. Do one of the following:
      • Create the node of the Wallarm node type and copy the generated token.
      • Use existing node group - copy token using node's menu → Copy token.

2. Run the container with the node:

   US CloudEU Cloud

   docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=<GROUP>' -e NGINX_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -p 80:80 wallarm/node:5.0.2-1
   

   docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=<GROUP>' -e NGINX_BACKEND='example.com' -p 80:80 wallarm/node:5.0.2-1
   

You can pass the following basic filtering node settings to the container via the option -e:

The command does the following:

• Creates the file default with minimal NGINX configuration and passes filtering node configuration in the /etc/nginx/sites-enabled container directory.

• Creates files with filtering node credentials to access the Wallarm Cloud in the /opt/wallarm/etc/wallarm container directory:

  • node.yaml with filtering node UUID and secret key
  • private.key with Wallarm private key

• Protects the resource http://NGINX_BACKEND:80.

Run the container mounting the configuration file¶

You can mount the prepared configuration file to the Docker container via the -v option. The file must contain the following settings:

• Filtering node directives

• NGINX settings

To run the container:

1. Get Wallarm token of the appropriate type:

   API tokenNode token

   1. Open Wallarm Console → Settings → API tokens in the US Cloud or EU Cloud.
   2. Find or create API token with the Deploy source role.
   3. Copy this token.

   1. Open Wallarm Console → Nodes in the US Cloud or EU Cloud.
   2. Do one of the following:
      • Create the node of the Wallarm node type and copy the generated token.
      • Use existing node group - copy token using node's menu → Copy token.

2. Run the container with the node:

   US CloudEU Cloud

   docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=<GROUP>' -e WALLARM_API_HOST='us1.api.wallarm.com' -v /configs/default:/etc/nginx/sites-enabled/default -p 80:80 wallarm/node:5.0.2-1
   

   docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=<GROUP>' -v /configs/default:/etc/nginx/sites-enabled/default -p 80:80 wallarm/node:5.0.2-1
   

   • The -e option passes the following required environment variables to the container:

     Environment variable	Description	Required
     WALLARM_API_TOKEN	Wallarm node or API token.	Yes
     WALLARM_API_HOST	Wallarm API server: us1.api.wallarm.com for the US Cloud api.wallarm.com for the EU Cloud By default: api.wallarm.com.	No
     WALLARM_LABELS	Available starting from node 4.6. Works only if WALLARM_API_TOKEN is set to API token with the Deploy role. Sets the group label for node instance grouping, for example: WALLARM_LABELS="group=<GROUP>" ...will place node instance into the <GROUP> instance group (existing, or, if does not exist, it will be created).	Yes (for API tokens)

   • The -v option mounts the directory with the configuration file default to the /etc/nginx/sites-enabled container directory.

     See an example of the mounted file with minimal settings

     server {
             listen 80 default_server;
             listen [::]:80 default_server ipv6only=on;
             #listen 443 ssl;
     
             server_name localhost;
     
             #ssl_certificate cert.pem;
             #ssl_certificate_key cert.key;
     
             root /usr/share/nginx/html;
     
             index index.html index.htm;
     
             wallarm_mode monitoring;
     
             location / {
     
                     proxy_pass http://example.com;
                     include proxy_params;
             }
     }
     

     Mounting other configuration files

     The container directories used by NGINX:

     • /etc/nginx/nginx.conf - This is the main NGINX configuration file. If you decide to mount this file, additional steps are necessary for proper Wallarm functionality:

       1. In nginx.conf, add the following setting at the top level:

          include /etc/nginx/modules-enabled/*.conf;
          

       2. In nginx.conf, add the wallarm_srv_include /etc/nginx/wallarm-apifw-loc.conf; directive in the http block. This specifies the path to the configuration file for API Specification Enforcement.

       3. Mount the wallarm-apifw-loc.conf file to the specified path. The content should be:

          location ~ ^/wallarm-apifw(.*)$ {
                  wallarm_mode off;
                  proxy_pass http://127.0.0.1:8088$1;
                  error_page 404 431         = @wallarm-apifw-fallback;
                  error_page 500 502 503 504 = @wallarm-apifw-fallback;
                  allow 127.0.0.0/8;
                  deny all;
          }
          
          location @wallarm-apifw-fallback {
                  wallarm_mode off;
                  return 500 "API FW fallback";
          }
          

       4. Mount the /etc/nginx/conf.d/wallarm-status.conf file, ensuring its contents align with the template.

       5. Within the NGINX configuration files, set up the configuration for the /wallarm-status service according to the template.

     • /etc/nginx/conf.d — common settings

     • /etc/nginx/sites-enabled — virtual host settings
     • /opt/wallarm/usr/share/nginx/html — static files

     If required, you can mount any files to the listed container directories. The filtering node directives should be described in the /etc/nginx/sites-enabled/default file.

The command does the following:

• Mounts the file default into the /etc/nginx/sites-enabled container directory.

• Creates files with filtering node credentials to access Wallarm Cloud in the /opt/wallarm/etc/wallarm container directory:

  • node.yaml with filtering node UUID and secret key
  • private.key with Wallarm private key

• Protects the resource http://example.com.

Logging configuration¶

The logging is enabled by default. The log directories are:

• /var/log/nginx — NGINX logs

• /opt/wallarm/var/log/wallarm — Wallarm node logs

Monitoring configuration¶

To monitor the filtering node, there are Nagios‑compatible scripts inside the container. See details in Monitoring the filtering node.

Example of running the scripts:

docker exec -it <WALLARM_NODE_CONTAINER_ID> /usr/lib/nagios/plugins/check_wallarm_tarantool_timeframe -w 1800 -c 900

docker exec -it <WALLARM_NODE_CONTAINER_ID> /usr/lib/nagios/plugins/check_wallarm_export_delay -w 120 -c 300

• <WALLARM_NODE_CONTAINER_ID> is the ID of the running Wallarm Docker container. To get the ID, run docker ps and copy the proper ID.

Testing Wallarm node operation¶

1. Send the request with test Path Traversal attack to a protected resource address:

   curl http://localhost/etc/passwd
   

2. Open Wallarm Console → Attacks section in the US Cloud or EU Cloud and make sure the attack is displayed in the list.
   

Configuring the use cases¶

The configuration file mounted to the Docker container should describe the filtering node configuration in the available directive. Below are some commonly used filtering node configuration options:

• Configuration of the filtration mode

• Logging Wallarm node variables

• Limiting the single request processing time in the directive wallarm_process_time_limit

• Limiting the server reply waiting time in the NGINX directive proxy_read_timeout

• Limiting the maximum request size in the NGINX directive client_max_body_size

Was this page helpful?

How can we improve this article? (Optional)

Information is unclear or confusing

Insufficient information

Outdated or incorrect information

0/240

Send