AzureへのWallarm Dockerイメージのデプロイ¶
このクイックガイドでは、NGINXベースのWallarmノードのDockerイメージをAzure Container Instancesサービスを使用してMicrosoft Azureクラウドプラットフォームにデプロイする手順を説明します。
この手順の制限事項
本手順には負荷分散およびノードの自動スケーリングの設定は含まれていません。これらのコンポーネントを自身で設定する場合は、Azure Application Gatewayのドキュメントを参照することをおすすめします。
ユースケース¶
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.
前提条件¶
-
有効なAzureサブスクリプション
-
US CloudまたはEU CloudのWallarm ConsoleでAdministratorロールを持つアカウントへのアクセス
-
攻撃検出ルールやAPI仕様の更新をダウンロードし、さらにallowlisted、denylisted、graylistedの国・地域・データセンターの正確なIPを取得するために、以下のIPアドレスへのアクセス
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フィルタリングノードをデプロイするには、以下のツールを使用できます:
本手順では、Azure CLIを使用してコンテナーをデプロイします。
-
Get Wallarm token of the appropriate type:
-
az login
コマンドでAzure CLIにサインインします: -
az group create
コマンドでリソースグループを作成します。例えば、以下のコマンドでEast USリージョンにmyResourceGroup
グループを作成します: -
インスタンスをWallarm Cloudに接続するために使用するWallarmノードトークンをローカル環境変数に設定します:
-
az container create
コマンドを使用して、WallarmノードDockerコンテナーからAzureリソースを作成します:az container create \ --resource-group myResourceGroup \ --name wallarm-node \ --dns-name-label wallarm \ --ports 80 \ --image registry-1.docker.io/wallarm/node:6.4.1 \ --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} NGINX_BACKEND='example.com' WALLARM_API_HOST='us1.api.wallarm.com' WALLARM_LABELS='group=<GROUP>'
--resource-group
: 2番目の手順で作成したリソースグループ名。--name
: コンテナー名。--dns-name-label
: コンテナーのDNS名ラベル。--ports
: フィルタリングノードが待ち受けるポート。--image
: WallarmノードDockerイメージ名。-
--environment-variables
: フィルタリングノードの構成を含む環境変数(利用可能な変数は以下の表に記載しています)。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 theDeploy
role. Sets thegroup
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 Cloudapi.wallarm.com
for the EU Cloud
api.wallarm.com
.No WALLARM_MODE
Node mode: block
to block malicious requestssafe_blocking
to block only those malicious requests originated from graylisted IP addressesmonitoring
to analyze but not block requestsoff
to disable traffic analyzing and processing
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)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 image4.0.2-1
, thewallarm-status
service automatically runs on the same port as NGINX.
Default value (if the variable is not passed to the container) is80
.
Syntax isNGINX_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 istrue
, 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 APIFW_METRICS_ENABLED
(6.4.1 and higher)Enables Prometheus metrics for the API Specification Enforcement module.
By default:false
(disabled).No APIFW_METRICS_HOST
(6.4.1 and higher)Defines the host and port on which the API Specification Enforcement exposes metrics.
By default::9010
.No APIFW_METRICS_ENDPOINT_NAME
(6.4.1 and higher)Defines the HTTP path of the API Specification Enforcement metrics endpoint
By default:metrics
.No WALLARM_WSTORE__METRICS__LISTEN_ADDRESS
Defines the host and port on which Postanalytics and general system metrics are exposed.
By default:http://localhost:9001/metrics
.No WALLARM_WSTORE__SERVICE__PROTOCOL
(6.6.0 and higher)Specifies the protocol family that wstore uses for incoming connections. Possible values: "tcp"
- dual-stack mode (listens on both IPv4 and IPv6)"tcp4"
- IPv4 only"tcp6"
- IPv6 only
"tcp4"
.No
-
Azure portalを開き、作成したリソースがリソース一覧に表示されていることを確認します。
マウントしたファイルで構成されたWallarmノードDockerコンテナーのデプロイ¶
環境変数とマウントしたファイルで構成されたコンテナ化Wallarmフィルタリングノードをデプロイするには、Azure CLIのみを使用できます。
環境変数とマウント済みの構成ファイルを使ってコンテナーをデプロイするには:
-
Get Wallarm token of the appropriate type:
-
az login
コマンドでAzure CLIにサインインします: -
az group create
コマンドでリソースグループを作成します。例えば、以下のコマンドでEast USリージョンにmyResourceGroup
グループを作成します: -
フィルタリングノードの設定を記述した構成ファイルをローカルに作成します。最小設定の例:
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; } }
-
Azureでデータボリュームをマウントするのに適したいずれかの方法で構成ファイルを配置します。すべての方法はAzureドキュメントのデータボリュームのマウントセクションに記載されています。
本手順では、構成ファイルをGitリポジトリからマウントします。
-
インスタンスをWallarm Cloudに接続するために使用するWallarmノードトークンをローカル環境変数に設定します:
-
az container create
コマンドを使用して、WallarmノードDockerコンテナーからAzureリソースを作成します:az container create \ --resource-group myResourceGroup \ --name wallarm-node \ --dns-name-label wallarm \ --ports 80 \ --image registry-1.docker.io/wallarm/node:6.4.1 \ --gitrepo-url <URL_OF_GITREPO> \ --gitrepo-mount-path /etc/nginx/http.d \ --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:6.4.1 \ --gitrepo-url <URL_OF_GITREPO> \ --gitrepo-mount-path /etc/nginx/http.d \ --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} WALLARM_LABELS='group=<GROUP>'
--resource-group
: 2番目の手順で作成したリソースグループ名。--name
: コンテナー名。--dns-name-label
: コンテナーのDNS名ラベル。--ports
: フィルタリングノードが待ち受けるポート。--image
: WallarmノードDockerイメージ名。--gitrepo-url
: 構成ファイルを含むGitリポジトリのURL。ファイルがリポジトリのルートにある場合はこのパラメータのみを渡します。ファイルがGitリポジトリ内の別ディレクトリにある場合は、--gitrepo-dir
パラメータにディレクトリへのパスも渡してください(例:--gitrepo-dir ./dir1
)。-
--gitrepo-mount-path
: 構成ファイルをマウントするコンテナー内のディレクトリ。構成ファイルは、NGINXが使用する次のコンテナーディレクトリにマウントできます:/etc/nginx/conf.d
— 共通設定/etc/nginx/http.d
— 仮想ホスト設定/var/www/html
— 静的ファイル
フィルタリングノードのディレクティブは
/etc/nginx/http.d/default.conf
ファイルに記述します。 -
--environment-variables
: フィルタリングノードおよびWallarm Cloud接続の設定を含む環境変数(利用可能な変数は以下の表に記載しています)。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 Cloudapi.wallarm.com
for the EU Cloud
api.wallarm.com
.No WALLARM_LABELS
Available starting from node 4.6. Works only if
WALLARM_API_TOKEN
is set to API token with theDeploy
role. Sets thegroup
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)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 APIFW_METRICS_ENABLED
(6.4.1 and higher)Enables Prometheus metrics for the API Specification Enforcement module.
By default:false
(disabled).No APIFW_METRICS_HOST
(6.4.1 and higher)Defines the host and port on which the API Specification Enforcement exposes metrics.
By default::9010
.No APIFW_METRICS_ENDPOINT_NAME
(6.4.1 and higher)Defines the HTTP path of the API Specification Enforcement metrics endpoint
By default:metrics
.No WALLARM_WSTORE__SERVICE__PROTOCOL
(6.6.0 and higher)Specifies the protocol family that wstore uses for incoming connections. Possible values: "tcp"
- dual-stack mode (listens on both IPv4 and IPv6)"tcp4"
- IPv4 only"tcp6"
- IPv6 only
"tcp4"
.No
-
Azure portalを開き、作成したリソースがリソース一覧に表示されていることを確認します。
フィルタリングノードの動作テスト¶
-
Azure portalで作成済みリソースを開き、FQDNの値をコピーします。
FQDNフィールドが空の場合は、コンテナーがRunningステータスであることを確認してください。
-
コピーしたドメインにテスト用のPath Traversal攻撃を含むリクエストを送信します:
-
Wallarm Console → AttacksをUS CloudまたはEU Cloudで開き、攻撃が一覧に表示されていることを確認します。
-
任意で、ノードの他の動作も[テスト][link-docs-check-operation]します。
コンテナーのデプロイ中に発生したエラーの詳細は、Azure portalのリソース詳細のContainers → Logsタブに表示されます。リソースにアクセスできない場合は、必要なフィルタリングノードのパラメーターが正しい値でコンテナーに渡されていることを確認してください。