Azureにアマゾン ウェブ サービス (AWS) Web アプリケーション ワークロードをデプロイする準備をする

この記事では、Azure プラットフォーム上の Web アプリケーションのホスティング、保護、スケーリング、監視を容易にするために、堅牢で運用可能なインフラストラクチャをデプロイする方法に関する包括的なガイドを提供します。

AWS での Yelb デプロイ

AWS 上の Yelb サンプル Web アプリケーションは、Bash、 AWS CLI、 eksctl、 kubectl、 Helm を使用してデプロイされます。 コンパニオン sample には、Yelb アプリケーションの AWS Elastic Kubernetes Service (EKS) へのデプロイを自動化するために使用できる Bash スクリプトと YAML マニフェストが含まれています。 このソリューションでは、 AWS WAF を使用して Web アプリケーション ファイアウォールを実装し、 Amazon Elastic Kubernetes Service (EKS) で実行されている Web アプリケーションを保護する方法を示します。 Bash スクリプトを使用して EKS クラスターを作成し、 Yelb アプリケーションをデプロイできます。 Yelb Web アプリケーションは、 Amazon アプリケーション Load Balancer (ALB) を使用してパブリック インターネットに公開され、AWS WAF Web アクセス制御リスト (Web ACL) を使用して保護されます。 詳細な手順については、 AWS Elastic Kubernetes Service (EKS) から Azure Kubernetes Service (AKS) への Web アプリケーションのインポートに関するページを参照してください。

Yelb サービス インターフェイスのスクリーンショット。

Azure での Yelb のデプロイ

以降のセクションでは、Yelb サンプル Web アプリケーションを Azure Kubernetes Service (AKS) クラスターにデプロイし、NGINX イングレス コントローラー などのイングレス コントローラーを介して公開する方法について説明します。 イングレス コントローラー サービスには、AKS クラスターを収容する仮想ネットワーク内のトラフィックの分散を行う 内部 (またはプライベート) ロード バランサーを介してアクセスできます。 ハイブリッド シナリオでは、ロード バランサーフロントエンドにオンプレミス ネットワークからアクセスできます。 内部負荷分散の詳細については、「 Azure Kubernetes Service (AKS) を使用した内部ロード バランサーの使用」を参照してください。

付属の sample では、アプリケーション ルーティング アドオンを使用したマネージド NGINX イングレス コントローラー、または Helm チャート を使用したアンマネージド NGINX イングレス コントローラー のインストールをサポートしています。 NGINX イングレス コントローラーを使用したアプリケーション ルーティング アドオンには、次の機能があります。

その他の構成の場合は、

セキュリティを強化するために、Yelb アプリケーションは、Azure Application Gateway リソースによって保護されます。 このリソースは、AKS クラスターと同じ仮想ネットワーク内またはピアリングされた仮想ネットワーク内の専用サブネットにデプロイされます。 Azure Web Application Firewall (WAF) は、Azure Kubernetes Service (AKS) でホストされ、Azure Application Gateway を介して公開される Web アプリケーションへのアクセスを、一般的なエクスプロイトや脆弱性から保護します。

前提条件

Architecture

このサンプルでは、AKS クラスターを構築し、Yelb アプリケーションをデプロイし、NGINX ingress controller を使用して UI サービスを公開し、Azure Application Gateway と Azure Web Application Firewall (WAF) で保護するための、Bicep テンプレート、Bash スクリプト、YAML マニフェスト一式を提供します。

このサンプルには、2 つの個別のBicep パラメーター ファイルと 2 セットの Bash スクリプトと YAML マニフェストも含まれており、それぞれ 2 つの異なるソリューション オプションのデプロイを目指しています。 Bicepの詳細については、「Bicepとは

Application Gateway での TLS 終了と HTTP 経由の Yelb 呼び出し

このソリューションでは、Azure Web Application Firewall (WAF)悪意のある攻撃をブロックすることで、システムのセキュリティを確保します。 Azure Application Gateway は、クライアント アプリケーションからの着信呼び出しを受信し、TLS 終了を実行し、要求を AKS でホストされる yelb-ui サービスに転送します。 この通信は、HTTP トランスポート プロトコルを使用して、内部ロード バランサーと NGINX イングレス コントローラーを介して実現されます。 次の図は、アーキテクチャを示しています。

HTTP 経由の Application Gateway WAFv2 と NGINX イングレス コントローラーに基づくソリューションの図。

メッセージ・フローは次のとおりです。

HTTP 経由の Application Gateway WAFv2 と NGINX イングレス コントローラーに基づくソリューションのメッセージ フローの図。

  1. Azure Application Gateway は TLS 終了を処理し、HTTP 経由で AKS でホストされる yelb-ui サービスに着信呼び出しを送信します。
  2. Application Gateway リスナーは、セキュリティで保護された通信を確保するために、Azure Key Vault から取得した SSL 証明書を使用します。
  3. リスナーに関連付けられている Azure WAF ポリシーは、受信要求に OWASP 規則とカスタム 規則を適用し、多くの種類の悪意のある攻撃を効果的に防止します。
  4. Application Gateway バックエンド HTTP 設定は、ポート 80 を使用して HTTP 経由で Yelb アプリケーションを呼び出します。
  5. Application Gateway バックエンド プールと正常性プローブは、トラフィック管理用の HTTP プロトコルを使用して、AKS 内部ロード バランサーを介して NGINX イングレス コントローラー を呼び出します。
  6. NGINX イングレス コントローラーは、AKS 内部ロード バランサーを使用して、クラスター内の通信をセキュリティで保護します。
  7. Kubernetes イングレス オブジェクトは、NGINX イングレス コントローラーを使用して、内部ロード バランサーを介して HTTP 経由でアプリケーションを公開します。
  8. yelb-ui型のClusterIP サービスは、クラスター内または NGINX イングレス コントローラーを介して呼び出しを制限します。

Azure Application Gateway を使用したエンド ツー エンド TLS の実装

TLS 終端

Azure Application Gateway では、ゲートウェイ レベルでの TLS 終了がサポートされています。つまり、バックエンド サーバーに送信される前に、ゲートウェイでトラフィックが復号化されます。 TLS 終了を構成するには、リスナーに TLS/SSL 証明書を追加する必要があります。 証明書は、秘密キーと公開キーの両方を含む個人情報Exchange (PFX) 形式である必要があります。 Azure Key Vaultから Application Gateway に証明書をインポートできます。 詳細については、「Key Vault 証明書での SSL 終了」を参照してください。

ゼロ トラスト セキュリティ モデル

ゼロ トラスト セキュリティ モデルを採用する場合は、Azure Application Gatewayなどのサービス プロキシとバックエンド サーバー間の暗号化されていない通信を防ぐ必要があります。 ゼロ トラスト セキュリティ モデルでは、ネットワーク内のリソースにアクセスしようとしているユーザーまたはデバイスに対して信頼が自動的に付与されることはありません。 代わりに、ユーザーの場所やネットワークに関係なく、要求ごとに ID と承認を継続的に検証する必要があります。 このシナリオでは、ゼロ トラスト セキュリティ モデルの実装には、受信要求のフロントエンドとして機能するサービス プロキシとしてAzure Application Gatewayを使用する必要があります。 これらの要求は、暗号化された形式でAzure Kubernetes Service (AKS)の NGINX イングレス コントローラーに送信されます。

Application Gateway を使用したエンド ツー エンド TLS

バックエンド サーバーでエンド ツー エンドの TLS 暗号化を行うAzure Application Gatewayを構成することで、ゼロ トラストアプローチを実装できます。 エンド ツー エンド TLS 暗号化 を使用すると、Application Gateway のレイヤー 7 負荷分散機能 (Cookie ベースのセッション アフィニティ、URL ベースのルーティング、サイトに基づくルーティング、X-Forwarded-* ヘッダーの書き換えまたは挿入機能など) を利用しながら、バックエンドに機密データを安全に送信できます。

Application Gateway がエンド ツー エンド TLS 通信モードで構成されている場合、ゲートウェイで TLS セッションが終了し、ユーザー トラフィックが復号化されます。 次に、構成された規則を適用して、トラフィックのルーティングに適したバックエンド プール インスタンスを選択します。 次に、Application Gateway はバックエンド サーバーへの新しい TLS 接続を開始し、バックエンド サーバーの公開キー証明書を使用してデータを再暗号化してから、バックエンドに要求を送信します。 Web サーバーからの応答は、エンド ユーザーに到達する前に同じプロセスに従います。 エンド ツー エンド TLS を有効にするには、[バックエンド HTTP 設定] のプロトコル設定を HTTPS に設定し、バックエンド プールに適用する必要があります。 この方法により、バックエンド サーバーとの通信がセキュリティで保護され、要件に準拠することが保証されます。

詳細については、 Application Gateway のエンド ツー エンド TLS 暗号化 と 、Application Gateway をセキュリティで保護するためのベスト プラクティスに関する説明を参照してください。

このソリューションでは、Azure Web Application Firewall (WAF)悪意のある攻撃をブロックすることで、システムのセキュリティを確保します。 Azure Application Gateway は、クライアント アプリケーションからの受信呼び出しを処理し、TLS 終端を実行し、内部ロード バランサーと NGINX イングレス コントローラー経由で HTTPS プロトコルを使用して、基盤となる AKS でホストされている yelb-ui サービスを呼び出すことで、end-to-end TLS を実現します。 次の図は、アーキテクチャを示しています。

HTTPS 経由の Application Gateway WAFv2 と NGINX イングレス コントローラーに基づくソリューションの図。

メッセージ・フローは次のとおりです。

  1. Azure Application Gateway は TLS 終了を処理し、HTTPS 経由でバックエンド アプリケーションと通信します。
  2. Application Gateway リスナーは、 Azure Key Vault から取得した SSL 証明書を使用します。
  3. リスナーに関連付けられている Azure WAF ポリシーは、悪意のある攻撃をブロックするために、受信要求に対して OWASP 規則とカスタム 規則を実行します。
  4. Application Gateway バックエンド HTTP 設定は、ポート 443 で HTTPS 経由で AKS でホストされる yelb-ui サービスを呼び出すように構成されます。
  5. Application Gateway のバックエンド プールと正常性プローブは、HTTPS を使用して AKS の内部ロード バランサー経由で NGINX イングレス コントローラー にアクセスします。
  6. NGINX イングレス コントローラーは、AKS 内部ロード バランサーを使用するようにデプロイされます。
  7. SAKS クラスターは、Azure Key Vault プロバイダー for Secrets Store CSI Driver アドオンで構成され、CSI ボリュームを介してAzure Key Vaultからシークレット、証明書、およびキーを取得します。
  8. SecretProviderClass は、Application Gateway で使用される証明書をKey Vaultから取得するために使用されます。
  9. Kubernetes イングレス オブジェクトは、NGINX イングレス コントローラーを使用して、AKS 内部ロード バランサーを介して HTTPS 経由でアプリケーションを公開します。
  10. yelb-ui サービスには、クラスター内または ClusterIPを介して呼び出しを制限するの種類があります。

システムのセキュリティと安定性を確保するために、次の推奨事項を検討してください。

  • 最適なセキュリティを確保するために、Azure WAF ポリシーを最新の規則で定期的に更新します。
  • 受信した要求と潜在的な攻撃を追跡および分析するための監視とログ記録のメカニズムを実装します。
  • セキュリティの脆弱性に対処し、セキュリティで保護されたインフラストラクチャを維持するために、AKS クラスター、NGINX イングレス コントローラー、Application Gateway のメンテナンスと更新を定期的に実行します。
  • 受信した要求と潜在的な攻撃を追跡および分析するための監視とログ記録のメカニズムを実装します。
  • セキュリティの脆弱性に対処し、セキュリティで保護されたインフラストラクチャを維持するために、AKS クラスター、NGINX イングレス コントローラー、Application Gateway のメンテナンスと更新を定期的に実行します。

ホスト名

Application Gateway リスナーと Kubernetes イングレス は、同じホスト名を使用するように構成されます。 次の理由から、サービス プロキシとバックエンド Web アプリケーションに同じホスト名を使用することが重要です。

  • セッション状態の保持: プロキシとバックエンド アプリケーションに別のホスト名を使用すると、セッションの状態が失われる可能性があります。 つまり、ユーザー セッションが正しく保持されず、ユーザー エクスペリエンスが低下し、データが失われる可能性があります。
  • 認証エラー: ホスト名がプロキシとバックエンド アプリケーションの間で異なる場合、認証メカニズムが失敗する可能性があります。 この方法により、ユーザーはアプリケーション内でログインしたり、セキュリティで保護されたリソースにアクセスしたりできなくなる可能性があります。
  • 不注意による URL の公開: ホスト名が保持されていない場合は、バックエンド URL がエンド ユーザーに公開される可能性があります。 これにより、潜在的なセキュリティの脆弱性や機密情報への不正アクセスにつながる可能性があります。
  • Cookie の問題: Cookie は、ユーザー セッションを維持し、クライアントとサーバーの間で情報を渡す上で重要な役割を果たします。 ホスト名が異なると、Cookie が期待どおりに機能せず、認証の失敗、不適切なセッション処理、不適切なリダイレクトなどの問題が発生する可能性があります。
  • エンドツーエンドの TLS/SSL 要件: プロキシとバックエンド サービス間のセキュリティで保護された通信にエンドツーエンドの TLS/SSL が必要な場合は、元のホスト名に一致する TLS 証明書が必要です。 同じホスト名を使用すると、証明書管理プロセスが簡略化され、セキュリティで保護された通信がシームレスに確立されます。

サービス プロキシとバックエンド Web アプリケーションに同じホスト名を使用することで、これらの問題を回避できます。 バックエンド アプリケーションは Web ブラウザーと同じドメインを見て、セッションの状態、認証、および URL 処理が正しく機能することを確認します。

メッセージ フロー

次の図は、デプロイ時と実行時のメッセージ フロー ステップを示しています。

HTTPS 経由の Application Gateway WAFv2 と NGINX イングレス コントローラーに基づくソリューションのメッセージ フローの図。

デプロイのワークフロー

次の手順では、デプロイ プロセスについて説明します。 このワークフローは、前の図の緑色の番号に対応しています。

  1. セキュリティ エンジニアは、ワークロードが使用するカスタム ドメインの証明書を生成し、Azureキー コンテナーに保存します。 既知の 証明機関 (CA) から有効な証明書を取得できます。
  2. プラットフォーム エンジニアは、main.bicepparams Bicep パラメーター ファイルに必要な情報を指定し、Bicep テンプレートをデプロイしてAzure リソースを作成します。 必要な情報は次のとおりです。
    • Azure リソースのプレフィックス。
    • ワークロードホスト名と Application Gateway リスナーカスタム ドメインの TLS 証明書を保持する既存のAzure Key Vaultの名前とリソース グループ。
  3. 次のパッケージを AKS クラスターにインストールするように デプロイ スクリプト を構成できます。 詳細については、Bicep モジュールの parameters セクションを確認してください。
  4. Application Gateway リスナーは、Azure Key Vaultから TLS 証明書を取得します。
  5. Kubernetes ingress オブジェクトは、シークレット ストア CSI Driver の Azure Key Vault プロバイダーから取得した証明書を使用して、HTTPS 経由で Yelb UI サービスを公開します。
  6. Application Gateway リスナーは、Azure Key Vault から TLS 証明書を取得します。
  7. Kubernetes ingress オブジェクトは、Secrets Store CSI Driver の Azure Key Vault プロバイダーから取得した証明書を使用して、HTTPS 経由で Yelb UI サービスを公開します。

ランタイム ワークフロー

  1. クライアント アプリケーションは、ホスト名を使用してサンプル Web アプリケーションを呼び出します。 Application Gateway リスナーのカスタム ドメインに関連付けられている DNS ゾーンは、A レコードを使用して、Application Gateway のフロントエンド IP 構成で使用されるAzureパブリック IP のアドレスで DNS クエリを解決します。
  2. 要求は、Application Gateway のフロントエンド IP 構成で使用されるAzureパブリック IP に送信されます。
  3. Application Gateway は、次のアクションを実行します。
    1. Application Gateway は TLS 終了を処理し、HTTPS 経由でバックエンド アプリケーションと通信します。
    2. Application Gateway リスナーは、 Azure Key Vault から取得した SSL 証明書を使用します。
    3. リスナーに関連付けられている Azure WAF ポリシーは、受信要求に対して OWASP ルールとカスタム ルールを実行し、悪意のある攻撃をブロックします。
    4. Application Gateway バックエンド HTTP 設定は、ポート 443 で HTTPS 経由でサンプル Web アプリケーションを呼び出すように構成されています。
  4. Application Gateway バックエンド プールは、HTTPS を使用して AKS 内部ロード バランサーを介して NGINX イングレス コントローラーを呼び出します。
  5. 要求は、NGINX イングレス コントローラーのポッドをホストするエージェント ノードのいずれかに送信されます。
  6. NGINX イングレス コントローラー レプリカの 1 つが要求を処理し、 yelb-ui サービスのいずれかのサービス エンドポイントに要求を送信します。
  7. yelb-uiは、yelb-appserver サービスを呼び出します。
  8. yelb-appserverは、yelb-dbサービスとyelb-cache サービスを呼び出します。
  9. yelb-uiは、yelb-appserver サービスを呼び出します。
  10. yelb-appserverは、yelb-dbサービスとyelb-cache サービスを呼び出します。

Deployment

既定では、Bicep テンプレートは、Azure CNI Overlay ネットワーク プラグインと Cilium データ プレーンを使用して AKS クラスターをインストールします。 代替のネットワーク プラグインを使用できます。 さらに、このプロジェクトでは、次の拡張機能と機能を備えた AKS クラスターをデプロイする方法を示します。

運用環境では、アップタイム SLA を使用してプライベート AKS クラスターをデプロイすることを強くお勧めします。 詳細については、 パブリック DNS アドレスを持つプライベート AKS クラスターを参照してください。

または、 承認された IP アドレス範囲を使用して、パブリック AKS クラスターをデプロイし、API サーバーへのアクセスをセキュリティで保護することもできます。 Bicep テンプレートを使用してインフラストラクチャをAzureにデプロイする方法の詳細と手順については、companion Azure コード サンプルを参照してください。

運用環境では、アップタイム SLA を使用してプライベート AKS クラスターをデプロイすることを強くお勧めします。 詳細については、 パブリック DNS アドレスを持つプライベート AKS クラスターを参照してください。 または、 承認された IP アドレス範囲を使用して、パブリック AKS クラスターをデプロイし、API サーバーへのアクセスをセキュリティで保護することもできます。 Bicep テンプレートを使用してインフラストラクチャをAzureにデプロイする方法の詳細と手順については、companion Azure コード サンプルを参照してください。

次のステップ

AWS Web アプリケーションワークロードを Azure

貢献者達

Microsoft では、この記事を保持しています。 最初の寄稿者は次のとおりです:

主要著者:

その他の共同作成者:

  • Last updated on