コンテンツにスキップ

AWS VPCでWallarmをプロキシとしてデプロイする

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

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

このプロキシのアドバンスドソリューションを試すことで、ソリューションの柔軟性を実際に確認できます。

セキュリティに関する注意

このソリューションはAWSのセキュリティベストプラクティスに準拠するよう設計されています。デプロイにはAWSのルートアカウントの使用を避けることを推奨します。代わりに、必要最小限の権限のみを付与したIAMユーザーまたはロールを使用してください。

デプロイプロセスは最小権限の原則を前提としており、Wallarmコンポーネントのプロビジョニングおよび運用に必要な最小限のアクセスのみを付与します。

ユースケース

サポートされるWallarmのデプロイオプションの中でも、次のようなユースケースではAWS VPCへのWallarmのデプロイにTerraformモジュールの使用を推奨します:

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

  • Infrastructure as Code (IaC)の実践を活用しています。WallarmのTerraformモジュールにより、AWS上のWallarmノードの管理とプロビジョニングを自動化でき、効率性と一貫性が向上します。

要件

  • Terraform 1.0.5以上がローカルにインストール済みであること

  • USまたはEUのCloudにあるWallarm ConsoleでAdministratorロールを持つアカウントへのアクセス

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

  • 任意のAWSリージョンを使用できます。Wallarmノードのデプロイにリージョンの特別な制限はありません

  • Terraform、AWS EC2、Security Groupsおよびその他のAWSサービスに関する理解

  • リソースのデプロイにAWSのルートアカウントは決して使用しないでください

    本ガイドで説明するデプロイを実行するには、必要最小限の権限のみを持つ専用のIAMユーザーまたはロールを使用してください。

  • 広範な権限（例: AdministratorAccess）の使用は避け、このモジュールの動作に必要なアクションのみに権限を付与してください

    このデプロイで使用するIAMロールと権限は最小権限の原則に従って設計されています。必要なAWSリソース（例: EC2、ネットワーキング、ログ）の作成と管理に必要な権限のみを付与してください。

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

Wallarmプロキシの構成図

この例のWallarmプロキシソリューションは次のコンポーネントで構成されます:

  • インターネット向けApplication Load BalancerがトラフィックをWallarmノードインスタンスへルーティングします。

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

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

  • Wallarmノードがリクエストをプロキシ転送するサービス。サービスの種類は問いません。例:

    • VPC Endpoints経由でVPCに接続されたAWS API Gatewayアプリケーション（対応する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オフロードの設定です。

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

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

    この機能を無効にするには、上記の注意に従ってください。

例のWallarm AWSプロキシソリューションを実行する

  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のヘルスチェックを手動で無効化してみることができます。これにより、サービス設定が不正でもインスタンスはアクティブな状態を維持し、再起動されません。数分での切り分けに追われるのではなく、ログを十分に調査してサービスをデバッグできます。

参考情報