Wallarm Docker Görüntüsünün Azure Üzerine Dağıtımı¶

Bu hızlı rehber, NGINX tabanlı Wallarm node'unun Docker görüntüsünün Azure Container Instances servisi kullanılarak Microsoft Azure bulut platformuna dağıtım adımlarını sunar.

Kullanım Durumları¶

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.

Gereksinimler¶

• Aktif bir Azure aboneliği

• Azure CLI yüklü

• US Cloud veya EU Cloud için Wallarm Console'da Administrator rolüne sahip ve iki faktörlü kimlik doğrulaması devre dışı bırakılmış hesaba erişim

• Saldırı tespit kuralları güncellemelerini ve API specification indirmek ile allowlisted, denylisted, or graylisted ülkeler, bölgeler veya veri merkezleri için doğru IP'leri almak üzere aşağıdaki IP adreslerine erişim

  US CloudEU Cloud

  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
  

Wallarm node Docker konteyner yapılandırması için seçenekler¶

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.

Ortam değişkenleriyle yapılandırılmış Wallarm node Docker konteynerinin dağıtılması¶

Sadece ortam değişkenleriyle yapılandırılmış konteynerleştirilmiş Wallarm filtreleme node'unu dağıtmak için aşağıdaki araçları kullanabilirsiniz:

• Azure CLI

• Azure portal

• Azure PowerShell

• ARM template

• Docker CLI

Bu talimatlarda, konteyner Azure CLI kullanılarak dağıtılmaktadır.

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 Node deployment/Deployment usage type.
   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. az login komutunu kullanarak Azure CLI'ya giriş yapın:

   az login
   

3. az group create komutunu kullanarak bir kaynak grubu oluşturun. Örneğin, aşağıdaki komutla East US bölgesinde myResourceGroup grubunu oluşturun:

   az group create --name myResourceGroup --location eastus
   

4. Wallarm Cloud'a bağlantı için kullanılacak Wallarm node token'ını içeren yerel ortam değişkenini ayarlayın:

   export WALLARM_API_TOKEN='<WALLARM_API_TOKEN>'
   

5. az container create komutunu kullanarak Wallarm node Docker konteynerinden bir Azure kaynağı oluşturun:

   Wallarm US Cloud için KomutWallarm EU Cloud için Komut

   az container create \
      --resource-group myResourceGroup \
      --name wallarm-node \
      --dns-name-label wallarm \
      --ports 80 \
      --image registry-1.docker.io/wallarm/node:5.3.0 \
      --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 wallarm-node \
      --dns-name-label wallarm \
      --ports 80 \
      --image registry-1.docker.io/wallarm/node:5.3.0 \
      --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} NGINX_BACKEND='example.com' WALLARM_LABELS='group=<GROUP>'
   

   • --resource-group: İkinci adımda oluşturulan kaynak grubunun adı.
   • --name: Konteynerin adı.
   • --dns-name-label: Konteyner için DNS ad etiketi.
   • --ports: Filtreleme node'unun dinlediği port.
   • --image: Wallarm node Docker görüntüsünün adı.

   • --environment-variables: Filtreleme node yapılandırmasını içeren ortam değişkenleri (kullanılabilir değişkenler aşağıdaki tabloda listelenmiştir). Lütfen WALLARM_API_TOKEN değerinin açıkça geçirilmesinin önerilmediğini unutmayın.

     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
     SLAB_ALLOC_ARENA (TARANTOOL_MEMORY_GB [NGINX Node 5.x and earlier][what-is-new-wstore])	Amount of memory allocated to wstore. The value can be a float (a dot . is a decimal separator). By default: 1.0 (1 gygabyte).	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
     WALLARM_APID_ONLY (5.3.7 and higher)	In this mode, attacks detected in your traffic are blocked locally by the node (if enabled) but not exported to Wallarm Cloud. Meanwhile, API Discovery and some other features remain fully functional, detecting your API inventory and uploading it to the Cloud for visualization. This mode is for those who want to review their API inventory and identify sensitive data first, and plan controlled attack data export accordingly. However, disabling attack export is rare, as Wallarm securely processes attack data and provides sensitive attack data masking if needed. More details By default: false.	No

6. Azure portal sayfasını açın ve oluşturulan kaynağın kaynaklar listesinde görüntülendiğinden emin olun.

7. Filtreleme node'unun çalışmasını test edin.

Montelenmiş dosya ile yapılandırılmış Wallarm node Docker konteynerinin dağıtılması¶

Ortam değişkenleri ve montelenmiş dosya ile yapılandırılmış konteynerleştirilmiş Wallarm filtreleme node'unu dağıtmak için sadece Azure CLI kullanılabilir.

Ortam değişkenleri ve montelenmiş yapılandırma dosyası ile konteyneri dağıtmak için:

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 Node deployment/Deployment usage type.
   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. az login komutunu kullanarak Azure CLI'ya giriş yapın:

   az login
   

3. az group create komutunu kullanarak bir kaynak grubu oluşturun. Örneğin, aşağıdaki komutla East US bölgesinde myResourceGroup grubunu oluşturun:

   az group create --name myResourceGroup --location eastus
   

4. Filtreleme node ayarlarını içeren bir yapılandırma dosyasını yerel olarak oluşturun. Minimal ayarların örneği:

   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;
       }
   }
   

   Yapılandırma dosyasında belirtilebilen filtreleme node yönergeleri →

5. Yapılandırma dosyasını Azure'da veri hacimlerini monte etme için uygun yöntemlerden biriyle yerleştirin. Tüm yöntemler, Azure dokümantasyonunun Mount data volumes bölümünde açıklanmıştır.

   Bu talimatlarda, yapılandırma dosyası Git deposundan monte edilmektedir.

6. Wallarm Cloud'a bağlantı için kullanılacak Wallarm node token'ını içeren yerel ortam değişkenini ayarlayın:

   export WALLARM_API_TOKEN='<WALLARM_API_TOKEN>'
   

7. az container create komutunu kullanarak Wallarm node Docker konteynerinden bir Azure kaynağı oluşturun:

   Wallarm US Cloud için KomutWallarm EU Cloud için Komut

   az container create \
      --resource-group myResourceGroup \
      --name wallarm-node \
      --dns-name-label wallarm \
      --ports 80 \
      --image registry-1.docker.io/wallarm/node:5.3.0 \
      --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 wallarm-node \
      --dns-name-label wallarm \
      --ports 80 \
      --image registry-1.docker.io/wallarm/node:5.3.0 \
      --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: 2. adımda oluşturulan kaynak grubunun adı.
   • --name: Konteynerin adı.
   • --dns-name-label: Konteyner için DNS ad etiketi.
   • --ports: Filtreleme node'unun dinlediği port.
   • --image: Wallarm node Docker görüntüsünün adı.
   • --gitrepo-url: Yapılandırma dosyasını içeren Git deposunun URL'si. Dosya depo kökünde yer alıyorsa, sadece bu parametreyi geçirmeniz gerekir. Dosya ayrı bir Git depo dizinindeyse, lütfen --gitrepo-dir parametresinde dizin yolunu da belirtin (örneğin,
     --gitrepo-dir ./dir1).

   • --gitrepo-mount-path: Yapılandırma dosyasının monte edileceği konteyner dizini. Yapılandırma dosyaları NGINX tarafından kullanılan aşağıdaki konteyner dizinlerine monte edilebilir:

     • /etc/nginx/conf.d — ortak ayarlar
     • /etc/nginx/sites-enabled — sanal ana bilgisayar ayarları
     • /var/www/html — statik dosyalar

     Filtreleme node yönergeleri /etc/nginx/sites-enabled/default dosyasında tanımlanmalıdır.

   • --environment-variables: Filtreleme node ve Wallarm Cloud bağlantısı ayarlarını içeren ortam değişkenleri (kullanılabilir değişkenler aşağıdaki tabloda listelenmiştir). Lütfen WALLARM_API_TOKEN değerinin açıkça geçirilmesinin önerilmediğini unutmayın.

     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)
     SLAB_ALLOC_ARENA (TARANTOOL_MEMORY_GB [NGINX Node 5.x and earlier][what-is-new-wstore])	Amount of memory allocated to wstore. The value can be a float (a dot . is a decimal separator). By default: 1.0 (1 gygabyte).	No
     WALLARM_APID_ONLY (5.3.7 and higher)	In this mode, attacks detected in your traffic are blocked locally by the node (if enabled) but not exported to Wallarm Cloud. Meanwhile, API Discovery and some other features remain fully functional, detecting your API inventory and uploading it to the Cloud for visualization. This mode is for those who want to review their API inventory and identify sensitive data first, and plan controlled attack data export accordingly. However, disabling attack export is rare, as Wallarm securely processes attack data and provides sensitive attack data masking if needed. More details By default: false.	No

8. Azure portal sayfasını açın ve oluşturulan kaynağın kaynaklar listesinde görüntülendiğinden emin olun.

9. Filtreleme node'unun çalışmasını test edin.

Filtreleme Node İşleminin Test Edilmesi¶

1. Azure portalında oluşturulan kaynağı açın ve FQDN değerini kopyalayın.

   

   FQDN alanı boşsa, lütfen konteynerin Running durumunda olduğundan emin olun.

2. Kopyalanan alan adına, test Path Traversal saldırısını gönderin:

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

3. Wallarm Console → Attacks bölümünü US Cloud veya EU Cloud üzerinden açın ve saldırının listede görüntülendiğinden emin olun.
   

Konteyner dağıtımı sırasında meydana gelen hatalarla ilgili detaylar, Azure portalındaki kaynak detaylarında Containers → Logs sekmesinde görüntülenir. Kaynak erişilemezse, lütfen konteynere doğru değerlerle gerekli filtreleme node parametrelerinin geçirildiğinden emin olun.

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