GCPへのWallarm Dockerイメージの展開¶

本クイックガイドは、NGINXベースのWallarmノードのDockerイメージをGoogle Compute Engine (GCE)を使用してGoogle Cloud Platformにデプロイするための手順を説明します。

使用例¶

Among all supported Wallarm deployment options, Wallarm deployment on Google Compute Engine (GCE) using the Docker image is recommended in these use cases:

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

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

要件¶

• 有効なGCPアカウント

• GCPプロジェクトが作成済み

• Compute Engine APIが有効になっている

• Google Cloud SDK (gcloud CLI)がインストールされ設定済み

• Wallarm Console上でUS CloudまたはEU CloudのAdministratorロールが付与され、二要素認証が無効になっているアカウントへのアクセス

• 攻撃検知ルールおよびAPI仕様のアップデートのダウンロード、並びに許可リスト、拒否リスト、またはグレイリストに登録された国、地域、またはデータセンターに対する正確なIPを取得するために、以下のIPアドレスへのアクセス

  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ノードDockerコンテナの構成オプション¶

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.

環境変数で構成されたWallarmノードDockerコンテナの展開¶

環境変数のみを使用して構成されたコンテナ化されたWallarmフィルタリングノードをデプロイするには、GCP Consoleまたはgcloud CLIを使用できます。本手順ではgcloud CLIを使用します。

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. インスタンスをWallarm Cloudに接続するために使用するWallarmノードトークンを含むローカル環境変数を設定します:

   export WALLARM_API_TOKEN='<WALLARM_API_TOKEN>'
   

3. gcloud compute instances create-with-containerコマンドを使用して、Dockerコンテナが稼働するインスタンスを作成します:

   Wallarm US Cloud向けコマンドWallarm EU Cloud向けコマンド

   gcloud compute instances create-with-container <INSTANCE_NAME> \
       --zone <DEPLOYMENT_ZONE> \
       --tags http-server \
       --container-env WALLARM_API_TOKEN=${WALLARM_API_TOKEN} \
       --container-env NGINX_BACKEND=<HOST_TO_PROTECT_WITH_WALLARM> \
       --container-env WALLARM_API_HOST=us1.api.wallarm.com \
       --container-image registry-1.docker.io/wallarm/node:5.3.0
   

   gcloud compute instances create-with-container <INSTANCE_NAME> \
       --zone <DEPLOYMENT_ZONE> \
       --tags http-server \
       --container-env WALLARM_API_TOKEN=${WALLARM_API_TOKEN} \
       --container-env NGINX_BACKEND=<HOST_TO_PROTECT_WITH_WALLARM> \
       --container-image registry-1.docker.io/wallarm/node:5.3.0
   

   • <INSTANCE_NAME>：インスタンスの名称です。例：wallarm-node。
   • --zone：インスタンスをホストするゾーンです。
   • --tags：インスタンスタグです。タグは他のリソースのインスタンス利用可否を設定するために使用されます。本ケースでは、ポート80を開放するタグhttp-serverがインスタンスに割り当てられます。
   • --container-image：フィルタリングノードのDockerイメージのリンクです。

   • --container-env：フィルタリングノードの構成情報を持つ環境変数です（利用可能な変数は以下の表に記載されています）。WALLARM_API_TOKENの値を明示的に渡すことは推奨しませんのでご注意ください。

     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

   • gcloud compute instances create-with-containerコマンドのすべてのパラメータについては、GCPドキュメントに記載されています。

4. GCP Console→Compute Engine→VM instancesを開き、インスタンスがリストに表示されていることをご確認ください。

5. フィルタリングノードの動作テストを行います。

マウントされたファイルを使用して構成されたWallarmノードDockerコンテナの展開¶

環境変数とマウントされたファイルを使用して構成されたコンテナ化されたWallarmフィルタリングノードを展開するには、インスタンスを作成し、このインスタンスのファイルシステム上にフィルタリングノードの構成ファイルを配置して、Dockerコンテナを実行する必要があります。これらの操作はGCP Consoleまたはgcloud CLIを使用して実行できます。本手順ではgcloud CLIを使用します。

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. gcloud compute instances createコマンドを使用して、Compute Engineレジストリから任意のオペレーティングシステムイメージに基づくインスタンスを作成します:

   gcloud compute instances create <INSTANCE_NAME> \
       --image <PUBLIC_IMAGE_NAME> \
       --zone <DEPLOYMENT_ZONE> \
       --tags http-server
   

   • <INSTANCE_NAME>：インスタンスの名称です。
   • --image：Compute Engineレジストリからのオペレーティングシステムイメージの名称です。作成されたインスタンスはこのイメージに基づいており、後でDockerコンテナの実行に使用されます。このパラメータが省略された場合、インスタンスはDebian 10イメージに基づきます。
   • --zone：インスタンスをホストするゾーンです。
   • --tags：インスタンスタグです。タグは他のリソースのインスタンス利用可否を設定するために使用されます。本ケースでは、ポート80を開放するタグhttp-serverがインスタンスに割り当てられます。
   • gcloud compute instances createコマンドのすべてのパラメータについては、GCPドキュメントに記載されています。

3. GCP Console→Compute Engine→VM instancesを開き、インスタンスがリストに表示され、RUNNING状態であることをご確認ください。

4. SSHを使用してインスタンスに接続します。詳細はGCPの手順をご参照ください。

5. 適切なオペレーティングシステム向けの手順に従って、インスタンスにDockerパッケージをインストールします。

6. インスタンスをWallarm Cloudに接続するために使用するWallarmノードトークンを含むローカル環境変数を設定します:

   export WALLARM_API_TOKEN='<WALLARM_API_TOKEN>'
   

7. インスタンス上で、フィルタリングノードの構成が含まれるファイルdefaultを含むディレクトリ（例として、ディレクトリ名をconfigsとすることが可能です）を作成します。以下は最小限の設定が記載されたファイルの例です:

   server {
       listen 80 default_server;
       listen [::]:80 default_server ipv6only=on;
       #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;
       }
   }
   

   構成ファイルに記載可能なフィルタリングノードのディレクティブ一覧 →

8. 環境変数とマウントされた構成ファイルを渡して、docker runコマンドを使用してWallarmノードDockerコンテナを実行します:

   Wallarm US Cloud向けコマンドWallarm EU Cloud向けコマンド

   docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=<GROUP>' -e WALLARM_API_HOST='us1.api.wallarm.com' -v <INSTANCE_PATH_TO_CONFIG>:<DIRECTORY_FOR_MOUNTING> -p 80:80 wallarm/node:5.3.0
   

   docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=<GROUP>' -v <INSTANCE_PATH_TO_CONFIG>:<CONTAINER_PATH_FOR_MOUNTING> -p 80:80 wallarm/node:5.3.0
   

   • <INSTANCE_PATH_TO_CONFIG>：前の手順で作成した構成ファイルへのパスです。例：configs。

   • <DIRECTORY_FOR_MOUNTING>：構成ファイルをマウントするコンテナ内のディレクトリです。構成ファイルはNGINXが使用する以下のコンテナディレクトリにマウント可能です:

     • /etc/nginx/conf.d — 共通設定
     • /etc/nginx/sites-enabled — 仮想ホスト設定
     • /var/www/html — 静的ファイル

     フィルタリングノードのディレクティブは/etc/nginx/sites-enabled/defaultファイルに記述する必要があります。

   • -p：フィルタリングノードが待ち受けるポートです。この値はインスタンスのポートと同一である必要があります。

   • -e：フィルタリングノードの構成情報を持つ環境変数です（利用可能な変数は以下の表に記載されています）。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)
     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

9. フィルタリングノードの動作テストを行います。

フィルタリングノードの動作テスト¶

1. GCP Console→Compute Engine→VM instancesを開き、External IP列からインスタンスのIPアドレスをコピーします。

   

   もしIPアドレスが空の場合は、インスタンスがRUNNING状態であることをご確認ください。

2. コピーしたアドレスに対して、テスト用のPath Traversal攻撃を送信します:

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

3. Wallarm ConsoleのUS CloudまたはEU CloudにてAttacksを開き、攻撃がリストに表示されていることをご確認ください.
   

コンテナデプロイメント中に発生したエラーの詳細は、View logsインスタンスメニューに表示されます。インスタンスが利用できない場合は、必要なフィルタリングノードパラメーターが正しい値でコンテナに渡されているかをご確認ください.

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