Skip to content

Deployment of the Wallarm Docker Image to Azure

This quick guide provides the steps to deploy the Docker image of the NGINX-based Wallarm node to the Microsoft Azure cloud platform using the Azure Container Instances service.

The instructions limitations

These instructions do not cover the configuration of load balancing and node autoscaling. If setting up these components yourself, we recommend that you read the documentation on Azure Application Gateway.

Use cases

Among all supported Wallarm deployment options, Wallarm deployment on Azure Container Instances using the Docker image is recommended in these use cases:

  • If your applications leverage a microservices architecture, and are already containerized and operational on Azure Container Instances.

  • 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.

Requirements

  • Active Azure subscription

  • Azure CLI installed

  • Access to the account with the Administrator role and two‑factor authentication disabled in Wallarm Console for the US Cloud or EU Cloud

  • 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

    34.96.64.17
34.110.183.149
35.235.66.155
34.102.90.100
34.94.156.115
35.235.115.105

    34.160.38.183
34.144.227.90
34.90.110.226

Options for the Wallarm node Docker container configuration

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.

Deploying the Wallarm node Docker container configured through environment variables

To deploy the containerized Wallarm filtering node configured only through environment variables, you can use the following tools:

In these instructions, the container is deployed using the Azure CLI.

  1. Get Wallarm token of the appropriate type:

    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. Sign in to the Azure CLI by using the az login command:

    az login

  3. Create a resource group by using the az group create command. For example, create the group myResourceGroup in the East US region with the following command:

    az group create --name myResourceGroup --location eastus

  4. Set the local environment variable with the Wallarm node token to be used to connect the instance to the Wallarm Cloud:

    export WALLARM_API_TOKEN='<WALLARM_API_TOKEN>'

  5. Create an Azure resource from the Wallarm node Docker container by using the az container create command:

    az container create \
   --resource-group myResourceGroup \
   --name waf-node \
   --dns-name-label wallarm-waf \
   --ports 80 \
   --image registry-1.docker.io/wallarm/node:5.2.1 \
   --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} NGINX_BACKEND='example.com' WALLARM_API_HOST='us1.api.wallarm.com' WALLARM_LABELS='group=<GROUP>'

    az container create \
   --resource-group myResourceGroup \
   --name waf-node \
   --dns-name-label wallarm-waf \
   --ports 80 \
   --image registry-1.docker.io/wallarm/node:5.2.1 \
   --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} NGINX_BACKEND='example.com' WALLARM_LABELS='group=<GROUP>'
    • --resource-group: name of the resource group created in the second step.
    • --name: name of the container.
    • --dns-name-label: DNS name label for the container.
    • --ports: port on which the filtering node listens.
    • --image: name of the Wallarm node Docker image.

    • --environment-variables: environment variables with the filtering node configuration (available variables are listed in the table below). Please note that it is not recommended to pass the value of WALLARM_API_TOKEN explicitly.

      Environment variable Description Required
      WALLARM_API_TOKEN Wallarm node or API token. Yes
      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)
      NGINX_BACKEND Domain or IP address of the resource to protect with the Wallarm solution. 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_MODE Node mode:
      • block to block malicious requests
      • safe_blocking to block only those malicious requests originated from graylisted IP addresses
      • monitoring to analyze but not block requests
      • off to disable traffic analyzing and processing
      By default: monitoring.
      Detailed description of filtration modes →      		 No
      WALLARM_APPLICATION Unique identifier of the protected application to be used in the Wallarm Cloud. The value can be a positive integer except for 0.

      Default value (if the variable is not passed to the container) is -1 which indicates the default application displayed in Wallarm Console → Settings → Application.

      More details on setting up applications →      		 No
      TARANTOOL_MEMORY_GB Amount of memory allocated to Tarantool. The value can be an integer or a float (a dot . is a decimal separator). By default: 1 gygabytes. No
      NGINX_PORT Sets a port that NGINX will use inside the Docker container.

      Starting from the Docker image 4.0.2-1, the wallarm-status service automatically runs on the same port as NGINX.

      Default value (if the variable is not passed to the container) is 80.

      Syntax is NGINX_PORT='443'.      		 No
      WALLARM_STATUS_ALLOW Custom CIDRs that are allowed to access the /wallarm-status endpoint from outside the Docker container. Example value: 10.0.0.0/8. If you need to pass several values, use a comma , as a separator. To access the service externally, use the Docker container's IP, specifying the /wallarm-status endpoint path. No
      DISABLE_IPV6 The variable with any value except for an empty one deletes the listen [::]:80 default_server ipv6only=on; line from the NGINX configuration file which will stop NGINX from IPv6 connection processing.

      If the variable is not specified explicitly or has an empty value "", NGINX processes both IPv6 and IPv4 connections.      		 No
      WALLARM_APIFW_ENABLE This setting toggles API Specification Enforcement on or off, available from release 4.10 onwards. Please note that activating this feature does not substitute for the required subscription and configuration through the Wallarm Console UI.

      Its default value is true, enabling the functionality.      		 No

  6. Open the Azure portal and ensure the created resource is displayed in the list of resources.

  7. Test the filtering node operation.

Deploying the Wallarm node Docker container configured through the mounted file

To deploy the containerized Wallarm filtering node configured through environment variables and mounted file, only Azure CLI can be used.

To deploy the container with environment variables and mounted configuration file:

  1. Get Wallarm token of the appropriate type:

    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. Sign in to the Azure CLI by using the az login command:

    az login

  3. Create a resource group by using the az group create command. For example, create the group myResourceGroup in the East US region with the following command:

    az group create --name myResourceGroup --location eastus

  4. Create a configuration file with the filtering node settings locally. A example of the 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;
    # wallarm_application 1;

    location / {
            proxy_pass http://example.com;
            include proxy_params;
    }
}

    Set of filtering node directives that can be specified in the configuration file →

  5. Locate the configuration file in one of the ways suitable for mounting data volumes in Azure. All methods are described in the Mount data volumes section of the Azure documentation.

    In these instructions, the configuration file is mounted from the Git repository.

  6. Set the local environment variable with the Wallarm node token to be used to connect the instance to the Wallarm Cloud:

    export WALLARM_API_TOKEN='<WALLARM_API_TOKEN>'

  7. Create an Azure resource from the Wallarm node Docker container by using the az container create command:

    az container create \
   --resource-group myResourceGroup \
   --name waf-node \
   --dns-name-label wallarm-waf \
   --ports 80 \
   --image registry-1.docker.io/wallarm/node:5.2.1 \
   --gitrepo-url <URL_OF_GITREPO> \
   --gitrepo-mount-path /etc/nginx/sites-enabled \
   --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} WALLARM_API_HOST='us1.api.wallarm.com' WALLARM_LABELS='group=<GROUP>'

    az container create \
   --resource-group myResourceGroup \
   --name waf-node \
   --dns-name-label wallarm-waf \
   --ports 80 \
   --image registry-1.docker.io/wallarm/node:5.2.1 \
   --gitrepo-url <URL_OF_GITREPO> \
   --gitrepo-mount-path /etc/nginx/sites-enabled \
   --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} WALLARM_LABELS='group=<GROUP>'
    • --resource-group: name of the resource group created in the 2nd step.
    • --name: name of the container.
    • --dns-name-label: DNS name label for the container.
    • --ports: port on which the filtering node listens.
    • --image: name of the Wallarm node Docker image.
    • --gitrepo-url: URL of the Git repository containing the configuration file. If the file is located in the repository root, you need to pass only this parameter. If the file is located in a separate Git repository directory, please also pass the path to the directory in the --gitrepo-dir parameter (for example,
      --gitrepo-dir ./dir1).

    • --gitrepo-mount-path: directory of the container to mount the configuration file to. Configuration files can be mounted to the following container directories used by NGINX:

      • /etc/nginx/conf.d — common settings
      • /etc/nginx/sites-enabled — virtual host settings
      • /var/www/html — static files

      The filtering node directives should be described in the /etc/nginx/sites-enabled/default file.

    • --environment-variables: environment variables containing settings for the filtering node and Wallarm Cloud connection (available variables are listed in the table below). Please note that it is not recommended to explicitly pass the value of WALLARM_API_TOKEN.

      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)

  8. Open the Azure portal and ensure the created resource is displayed in the list of resources.

  9. Test the filtering node operation.

Testing the filtering node operation

  1. Open the created resource on the Azure portal and copy the FQDN value.

    Settig up container instance

    If the FQDN field is empty, please ensure the container is in the Running status.

  2. Send the request with the test Path Traversal attack to the copied domain:

    curl http://<COPIED_DOMAIN>/etc/passwd

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

Details on errors occurred during the container deployment are displayed on the Containers → Logs tab of the resource details on the Azure portal. If the resource is unavailable, please ensure required filtering node parameters with correct values are passed to the container.