コンテンツにスキップ

AWS VPCでProxyとしてWallarmを展開する

本例はTerraformモジュールを使用して、既存のAWS Virtual Private Cloud (VPC)にインラインプロキシとしてWallarmを展開する方法を示します。

Wallarm proxyソリューションは、WAAPおよびAPIセキュリティ機能を備えた高度なHTTPトラフィックルーターとして機能する追加のネットワーク層を提供します。

プロキシ高度ソリューションを試すことで、ソリューションの柔軟性を確認できます： proxy advanced solution

ユースケース

すべてのサポートされるWallarmデプロイメントオプションの中で、Terraformモジュールは以下のユースケースにおいてAWS VPCでのWallarm展開に推奨されます：

  • 既存のインフラストラクチャがAWS上に存在します。

  • Infrastructure as Code (IaC)のプラクティスを活用しています。WallarmのTerraformモジュールは、AWS上のWallarmノードの自動管理とプロビジョニングを可能にし、効率性と一貫性を向上させます。

要件

  • Terraform1.0.5以上ローカルにインストール済み

  • USまたはEUCloudのWallarm ConsoleでAdministratorroleを持つアカウントへのアクセス権が必要です。

  • US Wallarm Cloudを利用する場合はhttps://us1.api.wallarm.com、EU Wallarm Cloudを利用する場合はhttps://api.wallarm.comへのアクセス権が必要です。ファイアウォールによってアクセスがブロックされていないことを確認ください。

ソリューションアーキテクチャ

Wallarm proxy scheme

本例のWallarm proxyソリューションは、以下のコンポーネントで構成されます：

  • インターネットに公開されるApplication Load BalancerがWallarmノードインスタンスへトラフィックをルーティングします。

  • Wallarmノードインスタンスがトラフィックを解析し、リクエストをさらにプロキシします。図中の対応する要素はA、B、CのEC2インスタンスです。

    本例ではWallarmノードが説明された挙動を促進する監視モードで実行されます。Wallarmノードは、悪意のあるリクエストをブロックし正当なリクエストのみを転送するなど、他のモードでも動作可能です。Wallarmノードのモードの詳細は当社ドキュメントをご参照ください。

  • Wallarmノードがリクエストをプロキシするサービスです。サービスは以下のような任意のタイプで構成可能です：

    • AWS API GatewayアプリケーションがVPC Endpoints経由でVPCに接続されています（該当するWallarm TerraformデプロイメントはAPI Gatewayの例で説明されています）。
    • AWS S3
    • EKSクラスターで稼働するEKSノード（この場合はInternal Load BalancerまたはNodePort Serviceの設定が推奨されます）。
    • その他の任意のバックエンドサービス

    デフォルトでは、Wallarmノードはトラフィックをhttps://httpbin.orgに転送します。本例の起動中に、AWS Virtual Private Cloud (VPC)から利用可能な任意のサービスドメインまたはパスを指定してトラフィックをプロキシすることが可能です。

    https_redirect_code = 302モジュール構成オプションにより、AWS ALBがHTTPリクエストを安全にHTTPSへリダイレクトするように設定できます。

リストアップされた全てのコンポーネント（プロキシされるサーバーを除く）は、提供されたwallarm例モジュールによってデプロイされます。

コードコンポーネント

本例は以下のコードコンポーネントで構成されます：

  • main.tf: プロキシソリューションとしてデプロイするためのwallarmモジュールのメイン構成です。この構成では、AWS ALBとWallarmインスタンスを生成します。

  • ssl.tf: domain_name変数で指定されたドメインに対して自動的に新規のAWS Certificate Manager (ACM)を発行し、AWS ALBにバインドするSSL/TLS offloadの構成です。

    この機能を無効化するには、ssl.tfおよびdns.tfファイルを削除またはコメントアウトし、wallarmモジュール定義内のlb_ssl_enabled、lb_certificate_arn、https_redirect_code、depends_onオプションもコメントアウトしてください。機能を無効化すると、HTTPポート (80) のみを使用できます。

  • dns.tf: AWS ALBのDNSレコードをプロビジョニングするAWS Route 53の構成です。

    機能を無効化する場合は、上記の注意事項に従ってください。

例のWallarm AWS proxyソリューションの実行方法

  1. EU CloudまたはUS CloudのWallarm Consoleにサインアップします。

  2. Wallarm Consoleを開き、Nodesを選択してWallarm nodeタイプのノードを作成します。

  3. 生成されたノードトークンをコピーします。

  4. 例のコードを含むリポジトリをマシンにクローンします：

    git clone https://github.com/wallarm/terraform-aws-wallarm.git

  5. クローンしたリポジトリ内のexamples/proxy/variables.tfファイルのdefaultオプションに変数値を設定し、変更を保存します。

  6. examples/proxy/main.tf内のproxy_passに、プロキシするサーバーのプロトコルとアドレスを設定します。

    デフォルトでは、Wallarmはトラフィックをhttps://httpbin.orgにプロキシします。デフォルト値で問題なければそのままにしてください。

  7. examples/proxyディレクトリから以下のコマンドを実行してスタックをデプロイします：

    terraform init
terraform apply

デプロイされた環境を削除するには、以下のコマンドを使用してください：

terraform destroy

トラブルシューティング

Wallarmが繰り返しインスタンスを作成および終了する

提供されたAWS Auto Scalingグループの構成は、サービスの高い信頼性と安定性に注力しています。AWS Auto Scalingグループの初期化中にEC2インスタンスが繰り返し作成および終了される場合、ヘルスチェックの失敗が原因である可能性があります。

この問題を解決するため、以下の設定を確認し、修正してください：

  • WallarmノードトークンがWallarm Console UIから正しい値をコピーされていること

  • NGINX設定が正しいこと

  • NGINX設定で指定されたドメイン名が正常に解決されていること（例：proxy_passの値）

極端な方法
上記の設定が正しい場合、Auto Scalingグループ設定でELBのヘルスチェックを手動で無効化し、問題の原因を特定することが可能です。これにより、サービスの構成が無効であってもインスタンスをアクティブに保ち、インスタンスが再起動しません。数分で問題を調査する代わりに、ログを徹底的に確認してサービスをデバッグできます。

参考資料