マルチテナント Azure Kubernetes Service クラスターで Application Gateway イングレス コントローラーを使用する

Azure Application Gateway

Azure Key Vault

Azure Container Registry

Azure Kubernetes Service (AKS)

Azure Bastion

このソリューションでは、 Azure Web Application Firewall (WAF) を使用して、マルチテナント Azure Kubernetes Service (AKS) クラスターにデプロイする Web アプリケーションを一元的に保護します。 WAF は、一般的な悪用や脆弱性から保護するのに役立ちます。

Azure アプリlication Gateway でWAF ポリシーを使用すると、SQL インジェクションやクロスサイト スクリプティングなどの悪意のある攻撃から Web アプリケーションを保護できます。 このメソッドは、AKS クラスターで実行されアプリケーション ゲートウェイ イングレス コントローラー (AGIC)を介して公開される Web アプリケーションを保護するのに役立ちます。 Application Gateway の WAF ポリシーは、Open Worldwide Application Security Project (OWASP) Core Rule Set (CRS) で事前構成されており、他の OWASP CRS バージョンをサポートしています。 カスタム ルールを作成することもできます。

アーキテクチャ

このアーキテクチャの Visio ファイルをダウンロードします。

ワークフロー

• このアーキテクチャでは、コンパニオン Azure Resource Manager テンプレート (ARM テンプレート) を使用して、次の 4 つのサブネットを持つ新しい仮想ネットワークをデプロイします。

  • AksSubnet は AKS クラスターをホストします。
  • VmSubnet は、ジャンプボックス仮想マシン (VM) とプライベート エンドポイントをホストします。
  • AppGatewaySubnet は Application Gateway WAF2 層をホストします。
  • AzureBastionSubnet は Azure Bastion をホストします。

• AKS クラスターでは、ユーザー定義のマネージド ID を使用して、ロード バランサーやマネージド ディスクなどのリソースをさらに Azure に作成します。 ARM テンプレートを使用して、次の機能を備える AKS クラスターをデプロイできます。

  • Azure ディスクと Azure Files 用の Container Storage Interface (CSI) ドライバー
  • AKS マネージド Microsoft Entra の統合
  • Kubernetes 認証用 Azure ロールベースのアクセス制御 (RBAC)
  • サービス プリンシパルの代わりにマネージド ID
  • Microsoft Entra ワークロード ID
  • Azure ネットワーク ポリシー
  • Azure Monitor container insights アドオン
  • AGIC アドオン
  • IP アドレスの動的割り当てと拡張サブネットのサポート

• AKS クラスターには、次のノード プールがあります。

  • システム ノード プールは重要なシステム ポッドとサービスのみをホストします。 ワーカー ノードにはノード テイントがあり、このノード プールでアプリケーション ポッドがスケジュールされないようにします。
  • ユーザー ノード プールは、ユーザーのワークロードと成果物をホストします。

• VM は、AKS クラスターをホストするのと同じ仮想ネットワークにデプロイされます。 AKS をプライベート クラスターとしてデプロイする場合、システム管理者はこの VM を使用して、Kubernetes コマンドライン ツールからクラスターを管理できます。 この VM のブート診断ログは、Azure Storage アカウントに格納されます。

• Azure Bastion ホストは、Secure Sockets Layer (SSL) を介して Azure portal で直接、ジャンプボックス VM へのセキュリティで保護されたシームレスな Secure Shell (SSH) 接続を提供します。 このソリューションでは、Azure Container Registry を使用して、Helm チャートなどのコンテナー イメージと成果物をビルド、格納、管理します。

• このアーキテクチャには、イングレス コントローラーが使用するアプリケーション ゲートウェイが含まれています。 アプリケーション ゲートウェイは専用サブネットにデプロイされ、すべてのテナント ワークロードが共有するパブリック IP アドレスを介してパブリック インターネットに公開されます。 WAF ポリシーは、テナント ワークロードを悪意のある攻撃から保護するのに役立ちます。

  WAF ポリシーは、ルート レベルおよび HTTP リスナー レベルでアプリケーション ゲートウェイに関連付けられます。 ポリシーは防止モードで構成され、 OWASP 3.1 を使用して、ルールが検出する侵入と攻撃をブロックします。 攻撃者は 403 未承認のアクセス 例外を受け取り、接続が閉じられます。 防止モードの場合、このような攻撃は WAF ログに記録されます。

• AKS で実行されるワークロードでは、キー コンテナーをシークレット ストアとして使用し、クライアント ライブラリ、Secrets ストア CSI ドライバー、または Dapr を使用してキー、証明書、シークレットを取得します。 Azure Private Link を使用すると、AKS ワークロードは、仮想ネットワーク内のプライベート エンドポイント経由で Azure Key Vault などの Azure サービスとしてのプラットフォーム (PaaS) ソリューションにアクセスできます。

• このアーキテクチャには、次のコンポーネントへのプライベート エンドポイントが含まれています。

  • Azure Blob Storage アカウント
  • コンテナレジストリ
  • Key Vault (キー・ボールト)
  • プライベート AKS クラスターを使用する場合は、Kubernetes クラスターの API サーバー

• このアーキテクチャには、PaaS サービスの完全修飾ドメイン名 (FQDN) を、関連付けられているプライベート エンドポイントのプライベート IP アドレスに解決するためのプライベート DNS ゾーンも含まれています。 このアーキテクチャには、プライベート エンドポイントを次のコンポーネントに解決するためのプライベート DNS ゾーンが含まれています。

  • Blob Storage アカウント
  • コンテナレジストリ
  • Key Vault (キー・ボールト)
  • Kubernetes Server API (クラスターをプライベートとしてデプロイする場合)

• AKS クラスターをホストする仮想ネットワークと、上記のプライベート DNS ゾーンの間に仮想ネットワーク リンクが存在します。 Log Analytics ワークスペースは、次のソースから診断ログとメトリックを収集します。

  • AKS クラスター
  • ジャンプボックス VM
  • アプリケーション ゲートウェイ
  • Key Vault (キー・ボールト)
  • Azure ネットワーク セキュリティ グループ

コンポーネント

• Container Registry は、オープンソースの Docker Registry 2.0 が基になっている、マネージド型のプライベート Docker レジストリ サービスです。 既存のコンテナー開発およびデプロイ パイプラインで Azure コンテナー レジストリを使用できます。 または、Container Registry タスクを使用して、Azure でコンテナー イメージをビルドします。 オンデマンドでビルドしたり、ソース コードのコミットや基本イメージの更新などのトリガーを使用してビルドを完全に自動化したりできます。

• AKS は、運用オーバーヘッドを Azure にオフロードすることで、Azure でのマネージド Kubernetes クラスターのデプロイを簡略化します。 ホストされた Kubernetes サービスとして、Azure によって正常性監視やメンテナンスなどの重要なタスクが処理されます。 Azure では Kubernetes コントロール プレーン ノードが管理されるため、エージェント ノードの管理と保守のみが行われます。

• Key Vault は、API キー、パスワード、証明書、暗号化キーなどのシークレットへのアクセスを安全に格納および制御するのに役立ちます。 Key Vault を使用すると、パブリックおよびプライベートトランスポート層セキュリティ (TLS) 証明書または SSL 証明書を簡単にプロビジョニング、管理、デプロイし、Azure および内部接続リソースで使用できます。

• Application Gateway は、ダウンストリーム Web アプリケーションと REST API に送信される受信トラフィックを管理するために使用できる Web トラフィック ロード バランサーです。 従来のロード バランサーは、伝送制御プロトコル (TCP) とユーザー データグラム プロトコル (UDP) を使用するトラフィックを処理するために、オープン システム相互接続 (OSI) レイヤー 4 であるトランスポート層で動作します。 トラフィックは送信元 IP アドレスとポートに基づいて送信先 IP アドレスとポートにルーティングされます。 アプリケーション ゲートウェイは、アプリケーション レイヤー (OSI レイヤー 7) のロード バランサーです。

• WAF は、一般的な悪用や脆弱性から Web アプリケーションを一元的に保護するのに役立つサービスです。 WAF は、 OWASP CRS からの規則に基づいています。 WAF を使用して、ポリシーを通過する要求ごとに評価されるカスタム 規則を作成できます。 これらの規則は、マネージド規則セット内の他の規則よりも高い優先度を持ちます。 カスタム規則には、規則名、規則の優先度、一致条件の配列が含まれます。 要求がこれらの条件を満たしている場合、WAF は規則に基づいて要求を許可またはブロックします。

• Azure Bastion は、お使いの仮想ネットワーク内でプロビジョニングする、フル マネージドPaaS (サービスとしてのプラットフォーム) です。 Azure Bastion は、TLS 経由で Azure portal から直接、仮想ネットワーク内の VM への安全でシームレスなリモート デスクトップ プロトコル (RDP) と SSH 接続を提供するのに役立ちます。

• Azure Virtual Machines では、物理ハードウェアを購入して保守することなく、仮想化の柔軟性を提供する、オンデマンドでスケーラブルなコンピューティング リソースが提供されます。

• Azure Virtual Network は、Azure のプライベート ネットワークの基本的な構成ブロックです。 Virtual Network を使用すると、VM などの Azure リソースは、より安全な方法で相互、インターネット、およびオンプレミス ネットワークと通信できます。 Azure Virtual Network は、オンプレミスの従来のネットワークと似ていますが、スケーラビリティ、可用性、分離などの Azure インフラストラクチャのメリットが得られます。

• 仮想ネットワーク インターフェイス は、Azure VM とインターネット、Azure、オンプレミスのリソース間の通信を確立するのに役立ちます。 1 つの Azure VM に複数のネットワーク インターフェイス カードを追加できるため、子 VM で独自の専用ネットワーク インターフェイス デバイスと IP アドレスを使用できます。

• Azure マネージド ディスクは、Azure が Azure VM 上で管理するブロックレベルのストレージ ボリュームです。 ディスクの種類には、Azure Ultra Disk Storage、Azure Premium SSD、Azure Standard SSD、Azure Standard HDD が含まれます。

• Blob Storage は、クラウド用の Microsoft オブジェクト ストレージ ソリューションです。 Blob Storage は、テキスト データやバイナリ データなどの大量の非構造化データを格納するために最適化されています。 非構造化データとは、テキスト データやバイナリ データなど、特定のデータ モデルや定義に準拠していないデータです。

• Private Link は、Blob Storage や Key Vault などの Azure PaaS サービスにアクセスし、Azure でホストされている顧客所有のサービスまたはパートナー サービスにアクセスできるように、仮想ネットワーク内のプライベート エンドポイントを提供します。

代替

AKS クラスターでホストするワークロードを公開する場合は、考慮すべきいくつかのソリューションがあります。 AGIC を使用する代わりに、Application Gateway for Containers を使用するかアプリケーション ルーティング アドオンで NGINX イングレスを管理。 これらの代替手段は、AKS クラスターへのトラフィックの管理とセキュリティ保護に役立つさまざまな機能を提供します。

このアーキテクチャでは、AKS の AGIC アドオンを使用して、AGICをインストールします。 Helm チャートを使用して AGIC を インストールすることもできます。 新しいセットアップを作成するときに、Azure CLI で 1 行を使用して、新しいアプリケーション ゲートウェイと新しい AKS クラスターをデプロイできます。 このメソッドは、アドオンとして AGIC を有効にします。 アドオンはフル マネージド サービスであり、自動更新やサポートの強化など、追加の利点を提供します。 また、AKS とのより優れた統合を提供する、ファーストクラスのアドオンとも見なされます。 Microsoft では、AGIC の両方の展開方法がサポートされています。

AGIC アドオンは、AKS クラスターにポッドとしてデプロイされます。 ただし、Helm デプロイ バージョンと AGIC のアドオン バージョンにはいくつかの違いがあります。 次のリストでは、2 つのバージョンの違いを示します。

• AKS アドオンで Helm デプロイの値を変更することはできません。

  • 既定では、usePrivateIp プロパティは false に設定されます。 use-private-ip注釈を使用してこの値を上書きすることはできません。
  • アドオンは、 shared 構成オプションをサポートしていません。

• Helm でデプロイされた AGIC では、 ProhibitedTargetsがサポートされています。つまり、AGIC は、他の既存のバックエンドに影響を与えることなく、AKS クラスター専用にアプリケーション ゲートウェイを構成できます。

• AGIC アドオンはマネージド サービスであるため、最新バージョンに自動的に更新されます。 Helm 経由で AGIC をデプロイする場合は、AGIC を手動で更新する必要があります。

• AKS クラスターごとにデプロイできる AGIC アドオンは 1 つだけです。 各 AGIC アドオンは、1 つの Application Gateway インスタンスのみを対象とすることができます。 クラスターごとに複数の AGIC を必要とするデプロイ、または 1 つの Application Gateway インスタンスを対象とする複数の AGIC の場合は、Helm でデプロイされた AGIC を使用できます。

AGIC の 1 つのインスタンスは、複数の Kubernetes 名前空間からイベントを取り込むことができます。 AKS 管理者がアプリケーション ゲートウェイをイングレスとして使用する場合、すべての名前空間で Application Gateway の同じインスタンスが使用されます。 AGIC を 1 回インストールすると、アクセス可能な名前空間が監視され、関連付けられているアプリケーション ゲートウェイが構成されます。 詳細については、「 AGIC を使用した AKS クラスターでの複数名前空間のサポートを有効」を参照してください。

複数名前空間のサポートを有効にするには、次の手順を実行します。

1. 次のいずれかの方法で、helm-config.yaml ファイルを変更します。

• watchNamespace キーを helm-config.yaml ファイルから完全に削除して、AGIC ですべての名前空間を観察できるようにします。
• watchNamespaceを空の文字列に設定して、AGIC ですべての名前空間を観察できるようにします。
• など、コンマで区切られた複数の名前空間を追加して、AGIC がこれらの名前空間のみを監視できるようにします。

2. 次のスクリプトを使用して Helm テンプレートの変更を適用します: helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure。

複数の名前空間を監視する機能を持つ AGIC をデプロイすると、AGIC は次のアクションを実行します。

1. アクセス可能なすべての名前空間からのイングレス リソースを一覧表示します
2. 注釈が付けられたイングレス リソースをフィルター処理する kubernetes.io/ingress.class: azure/application-gateway
3. 組み合わせた Application Gateway 構成を作成します。
4. Azure Resource Manager を使用して、関連付けられているアプリケーション ゲートウェイに構成を適用します。

シナリオの詳細

このアーキテクチャは、マルチテナント Kubernetes クラスターを複数のユーザーとワークロード間で共有します。これは、一般的に テナントと呼ばれます。 この定義には、Kubernetes クラスターを共有する組織内のさまざまなチームまたは部門が含まれます。 また、サービスとしてのソフトウェア (SaaS) アプリケーションの顧客ごとのインスタンスによって共有されるクラスターも含まれます。 クラスター マルチテナント機能は、多数のシングルテナント専用クラスターを管理することに代わる手段です。 マルチテナントの Kubernetes クラスターのオペレーターは、テナントを相互に分離する必要があります。 この分離により、侵害されたテナントまたは悪意のあるテナントがクラスターや他のテナントに及ぼす可能性がある損害を最小限に抑えることができます。 複数のユーザーまたはチームが、固定数のノードを持つ同じクラスターを共有している場合、1 つのチームが必要以上に多くのリソースを使用する可能性があります。 管理者は、 リソース クォータを使用して この問題に対処できます。

マルチテナント AKS クラスターを構築する場合は、クラスター、名前空間、ノード、ポッド、コンテナーの分離など、Kubernetes が提供するリソース分離のレイヤーを検討する必要があります。 また、複数のテナント間で異なる種類のリソースを共有することによるセキュリティへの影響についても考慮する必要があります。 たとえば、同じノード上の異なるテナントのポッドをスケジュールする場合、クラスターで必要なマシンの数を減らすことができます。 一方、特定のワークロードが併置されないようにする必要がある場合もあります。 たとえば、ユーザーの組織外で作成された信頼できないコードは、機密情報を処理するコンテナーと同じノード上で実行しないようにすることができます。 Azure Policy を使用して、信頼されたレジストリのみを AKS にデプロイできます。

Kubernetes は、テナント間の完全に安全な分離を保証することはできませんが、特定のユース ケースに十分なセキュリティを提供する機能を提供します。 ベスト プラクティスとして、各テナントとその Kubernetes リソースを、それぞれ独自の名前空間に分ける必要があります。 その後、 Kubernetes RBAC および network ポリシーを使用して テナントの分離を強制できます。 たとえば、次の図は、同じクラスター上の同じアプリケーションの複数のインスタンス (テナントごとに 1 つ) をホストする一般的な SaaS プロバイダー モデルを示しています。 各アプリケーションは個別の名前空間にあります。 より高いレベルの物理的分離とパフォーマンスの保証が必要なテナントは、専用のノード セット、専用プール、さらには専用クラスターにワークロードをデプロイできます。

AGIC は Kubernetes アプリケーションであるため、AKS のお客様は、アプリケーション ゲートウェイを使用してコンテナー化されたアプリケーションをインターネットに公開できます。 AGIC は、ホストされている Kubernetes クラスターを監視し、選択したサービスがインターネットに公開されるようにアプリケーション ゲートウェイを継続的に更新します。 AGIC は、顧客の AKS インスタンス上の独自のポッドで実行されます。 AGIC は、Kubernetes リソースのサブセットの変更を監視します。 AKS クラスターの状態は Application Gateway 固有の構成に変換され、 Resource Manager に適用されます。 このアーキテクチャでは、パブリックまたはプライベートのAKS クラスターアプリケーション ゲートウェイおよび AGIC アドオンを使用してデプロイする実証済みのプラクティスについて説明します。

AGIC の 1 つのインスタンスは、複数の名前空間からイベントを取り込んで観察できます。 AKS 管理者が Application Gateway をイングレスとして使用する場合、すべての名前空間で Application Gateway の同じインスタンスが使用されます。 AGIC を 1 回インストールすると、アクセス可能な名前空間が監視され、関連付けられているアプリケーション ゲートウェイが構成されます。

考えられるユース ケース

AGIC を使用して、マルチテナント環境でAKS クラスターで実行されるインターネットに接続するワークロードを公開および保護します。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

これらの考慮事項の一部は、AKS のマルチテナントに完全には関係しませんが、このソリューションの必須要件です。 これらの考慮事項には、セキュリティ、パフォーマンス、可用性、信頼性、ストレージ、スケジューラ、サービス メッシュ、監視のガイダンスが含まれます。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。

これらの可用性と信頼性に関する考慮事項は、AKS のマルチテナントには完全には関係しませんが、このソリューションの必須要件です。 AKS クラスターとワークロードの可用性を最適化するため、次の方法をご検討ください。

コンテナー

• Kubernetes 正常性プローブを使用して、コンテナーが正常に機能していることを確認します。

  • livenessProbe では、コンテナーが実行中かどうかを示します。 ライブネス プローブが失敗した場合、 kubelet はコンテナーを終了し、コンテナーには再起動ポリシーが適用されます。

  • readinessProbe では、コンテナーが要求に応答できる状態かどうかを示します。 準備プローブが失敗した場合、エンドポイント コントローラーはポッドに一致するすべてのサービスのエンドポイントからポッドの IP アドレスを削除します。 初期遅延前の準備状態の既定の状態は 失敗。

  • startupProbeは、コンテナー内のアプリケーションが開始されているかどうかを示します。 スタートアップ プローブがある場合、スタートアップ プローブが成功するまで、他のすべてのプローブは無効になります。 スタートアップ プローブが失敗した場合、 kubelet はコンテナーを終了し、コンテナーには再起動ポリシーが適用されます。

• リソースの競合がサービスの可用性に影響を与える場合があります。 1 つのコンテナーがクラスター メモリおよび CPU のリソースを占有できなくなるように、コンテナー リソースの制約を定義します。 AKS 診断を使用して、クラスター内の問題を特定できます。

• リソース制限を使用して、1 つのコンテナーが他のコンテナーを奪えないように、コンテナーに割り当てられたリソースの合計を制限します。

コンテナレジストリ

• コンテナー レジストリにコンテナー イメージを格納します。 Container Registry geo レプリケーションを使用して、レジストリを各 AKS リージョンに geo レプリケートします。 geo レプリケーションは、Premium SKU コンテナー レジストリの機能です。

• コンテナー イメージをスキャンして脆弱性を探す。 検証に合格したイメージのみをデプロイします。 基本イメージおよびアプリケーション ランタイムを定期的に更新し、AKS クラスターにワークロードを再デプロイします。

• ポッドおよびデプロイで使用できるイメージ レジストリを制限します。 使用可能なイメージを検証および制御できる信頼されたレジストリへのアクセスを制限します。

• コンテナー レジストリにイメージを発行する前に、継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインの一部としてコンテナー イメージの脆弱性をスキャンします。 アプリケーション イメージに基本イメージを使用する場合は、基本イメージを更新するときに、自動化を使用して新しいイメージをビルドします。 基本イメージには通常、セキュリティ修正プログラムが含まれているため、ダウンストリーム アプリケーション コンテナー イメージを更新する必要があります。 Microsoft Defender for Containers を CI/CD ワークフローに統合することをお勧めします。 詳細については、「 Automate コンテナー イメージ ビルド」を参照してください。

• Container Registry タスクを使用して、Docker コンテナーの OS とフレームワークの修正プログラムの適用を自動化します。 コンテナー レジストリ タスクでは、コンテナーの基本イメージを更新するときの自動ビルド プロセスがサポートされます。 たとえば、いずれかの基本イメージで OS またはアプリケーション フレームワークにパッチを適用できます。

リージョン内の回復性

• リージョン内のすべての 可用性ゾーン に AKS クラスターのノード プールをデプロイすることを検討してください。 ノード プールの前 Azure Standard Load Balancer または Application Gateway を使用します。 このトポロジでは、単一のデータセンターの停止が発生した場合の回復性が向上します。 この方法では、リージョン内の 3 つの個別の可用性ゾーンに存在する複数のデータセンターにクラスター ノードを分散します。

• リージョン内の回復性と高可用性を実現するため、 Container Registry のゾーン冗長 を有効にします。

• ポッド トポロジの分散制約を使用してリージョン、可用性ゾーン、ノードなどの障害ドメイン間でポッドを AKS クラスター全体に分散する方法を制御します。

• ミッション クリティカルなワークロードをホストする AKS クラスターのアップタイム サービス レベル アグリーメント (SLA) の使用を検討してください。 アップタイム SLA は、クラスターに対して財務的に支援されたより高い SLA を有効にするオプションの機能です。 アップタイム SLA では、可用性ゾーンを使用するクラスターに対して、Kubernetes API サーバー エンドポイントの 99.95% の可用性が保証されます。 可用性ゾーンを使用しないクラスターでは、99.90% の可用性が保証されます。 AKS では、SLA 要件を満たすために、更新ドメインと障害ドメイン間でコントロール プレーン ノードレプリカが使用されます。

ディザスター リカバリーと事業継続

• 1 つの地域内の少なくとも 2 組の Azure リージョン ペア にソリューションをデプロイすることを検討します。 また、Azure Traffic Manager、Azure Front Door などのグローバル ロード バランサー採用する必要があります。 ロード バランサーをアクティブ/アクティブ/アクティブ/パッシブ ルーティング方法と組み合わせて、ビジネス継続性とディザスター リカバリーを保証します。

• 品質保証環境でリージョンのフェールオーバー プロセスをスクリプト化、文書化、および定期的にテストします。 フェールオーバー プロセスは、プライマリ リージョンの停止がコア サービスに影響を与える場合に、予期しない問題を回避するのに役立ちます。

• フェールオーバー プロセス テストを使用して、ディザスター リカバリーアプローチが目標復旧ポイント (RPO) と目標復旧時間 (RTO) を満たしているかどうかを確認します。 手動のプロセスと介入を検証に含めます。

• フェールバック プロシージャをテストして、想定どおりに動作することを確認します。

• コンテナー イメージを Container Registry に格納します。 レジストリを各 AKS リージョンに geo レプリケートします。 詳細については、「コンテナー レジストリの Geo レプリケーション」を参照してください。

• 可能な場合は、コンテナー内にサービス状態を格納しないでください。 代わりに、マルチリージョン レプリケーションをサポートする Azure PaaS を使用します。

• Azure Storage を使用する場合は、プライマリ リージョンからバックアップ リージョンにストレージを移行する方法を準備してテストします。

• GitOps を使用してクラスター構成をデプロイすることを検討してください。 GitOps では、プライマリ クラスターとディザスター リカバリー クラスターの間の統一性が提供され、失った場合に新しいクラスターをすばやく再構築する方法も提供されます。

• AKS バックアップVelero などのツールを使用して、クラスター構成のバックアップと復元を検討。

サービス メッシュ

• AKS クラスターで、 Istio、 Linkerd、 Consul などのオープン ソース サービス メッシュを使用することを検討してください。 サービス メッシュは相互 TLS を使用して、マイクロサービスの可観測性、信頼性、およびセキュリティを向上させます。 ブルー/グリーンデプロイやカナリアデプロイなどのトラフィック分割戦略を実装することもできます。 サービス メッシュは、サービス間通信の安全性、高速性、信頼性を高めるのに役立つ専用のインフラストラクチャ レイヤーです。 詳細については、「 Istio サービス メッシュ AKS アドオン」を参照してください。

• Daprを採用して、ステートレスでステートフルであるかどうかに関係なく、回復性の高いマイクロサービス ベースのアプリケーションを構築することを検討してください。 任意のプログラミング言語と開発者フレームワークを使用できます。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。

セキュリティに関する考慮事項は、AKS のマルチテナントには完全には関係ありませんが、このソリューションの必須要件です。

マルチテナント

• AKS クラスターをマルチテナント機能用に設計します。 Kubernetes には、同じクラスター内のチームとワークロードを論理的に分離するために使用できる機能が用意されています。 各チームが必要とするリソースに最小限の特権を指定します。 Kubernetes の namespace によって論理分離境界が作成されます。

• 論理的な分離を使用して、チームとプロジェクトを分離します。 チームまたはアプリケーションを分離するためにデプロイする物理 AKS クラスターの数を最小限に抑えます。 クラスターを論理的に分離すると、通常、物理的に分離されたクラスターよりもポッド密度が高くなります。

• 厳密な物理的分離を実装する必要がある場合は常に、専用ノード プールまたは専用 AKS クラスターを使用します。 たとえば、ワーカー ノードのプール、またはクラスター全体をマルチテナント環境のチームまたはテナント専用にすることができます。

  コンテナーと容認の組み合わせを使用して特定のノード プールへのポッドのデプロイを制御します。 ノード プールの作成時に AKS 内のノードのみをテイントできます。 または、 ラベルと nodePool セレクターを使用して 特定のノード プールにのみワークロードをデプロイすることもできます。

ネットワークのセキュリティ

• AKS ワークロードが使用するすべての PaaS サービス (Key Vault、Azure Service Bus、Azure SQL Database など) に対してプライベート エンドポイントを作成します。 プライベート エンドポイントは、アプリケーションとこれらのサービス間のトラフィックがパブリック インターネットに公開されないようにするのに役立ちます。 詳細については、「 Private Link とはを参照してください。

• HTTPS 経由でワークロードを公開するように Kubernetes イングレス リソースを構成します。 テナントごとに個別のサブドメインとデジタル証明書を使用します。 AGIC は、SSL 終了用に Application Gateway リスナーを自動的に構成します。

• AKS で実行される一般向けワークロードを悪意のある攻撃から保護するためにWAF ポリシーを使用するようにapplication Gateway を構成します。

• AKS で Azure CNI ネットワークを使用して、既存の仮想ネットワークまたはオンプレミス ネットワークと統合します。 このネットワーク モデルでは、エンタープライズ環境でリソースとコントロールをさらに分離することもできます。

• ネットワーク ポリシーを使用し、相互に通信できるコンポーネントを制御することにより、サービス内通信を分離し、セキュリティで保護します。 既定では、Kubernetes クラスター内のすべてのポッドでは制限なしにトラフィックを送受信できます。 セキュリティ向上のため、Azure ネットワーク ポリシーまたは Calico ネットワーク ポリシーを使用して、さまざまなマイクロサービス間のトラフィック フローを制御するルールを定義できます。 詳細については、「 Network ポリシー」を参照してください。

• AKS ノードへのリモート接続は公開しないでください。 管理仮想ネットワークに要塞ホスト (ジャンプボックス) を作成します。 踏み台ホストを使用すると、AKS クラスターへのトラフィックをリモート管理タスクに安全にルーティングできます。

• AKS で 認証された IP アドレス範囲 を使用して、運用環境に private AKS クラスター を作成することを検討してください。 プライベート AKS クラスターを使用できない場合は、少なくとも API サーバーへのアクセスをセキュリティで保護します。

• Azure DDoS Protection とアプリケーション設計のベスト プラクティスを組み合わせて、強化された DDoS 軽減機能と DDoS 攻撃に対する追加の防御を提供します。 境界仮想ネットワークで DDoS Protection を有効にします。

認証と権限承認

• Microsoft Entra 統合を使って AKS クラスターをデプロイします。 詳細については、AKS マネージド Microsoft Entra 統合に関する記事を参照してください。 Microsoft Entra ID は、ID 管理コンポーネントを一元化します。

• Kubernetes RBAC を使用して、クラスターのリソースに対するユーザーまたはグループのアクセス許可を定義します。 roles または ClusterRoles および bindings を使用して、ユーザーまたはグループのスコープを必要最小限のアクセス許可に設定します。 Kubernetes RBAC を Microsoft Entra ID と統合して、ユーザーの状態またはグループ メンバーシップを変更すると、クラスター リソースへのアクセスが自動的に更新されるようにします。 詳細については、「 Kubernetes RBAC」を参照してください。

• Azure RBAC を使用して、ユーザーまたはグループが 1 つ以上のサブスクリプションの AKS リソースに対して持つ必要最小限のアクセス許可を定義します。 詳細については、「Kubernetes 認可に Azure RBAC を使用する」を参照してください。

• Microsoft Entra ワークロード IDを使用して、Azure リソース アクセス用の個々のマイクロサービスにマネージド ID を割り当てます。 その後、マイクロサービスは、Key Vault、SQL Database、Service Bus、Azure Cosmos DB などのマネージド リソースにアクセスできます。 マイクロサービスは、Kubernetes シークレットから接続文字列または資格情報を格納および取得する必要はありません。

• Secrets Store CSI Driver for Key Vault を使用して資格情報や接続文字列などのシークレットに、Kubernetes シークレットからではなく Key Vault からアクセスします。

• Dapr シークレット ストア構成要素を Key Vault ストアと Kubernetes 上のマネージド ID と組み合わせて資格情報や接続文字列などのシークレットを Key Vault から取得します。

ワークロードとクラスター

• クラスターをセキュリティで保護するために、Kubernetes API サーバーへのアクセスをセキュリティで保護します。 Kubernetes RBAC を Microsoft Entra ID と統合して、API サーバーへのアクセスを制御します。 これらのコントロールを使用して、Azure サブスクリプション アクセスの場合と同じ方法で AKS をセキュリティで保護します。

• コンテナーで実行できるアクションへのアクセスを制限します。 ポッドの作成と更新の詳細な承認を有効にするにはPod Security Admission 機能を使用します。 最小限のアクセス許可を付与し、ルートまたは特権エスカレーションの使用を避けます。 詳細については、「 リソースへの安全なポッド アクセスを参照してください。

• 可能な限り、コンテナーをルート ユーザーとして実行しないでください。

• AppArmor Linux カーネル セキュリティ モジュールを使用して、コンテナーが実行できるアクションを制限します。

• 新しい機能とバグ修正を利用するために、AKS クラスターを最新の Kubernetes バージョンに定期的にアップグレードします。

• kured デーモンセットを使用して、保留中の再起動、切断、ドレイン ノードを監視し、更新プログラムを適用します。 AKS により、各 Linux ノードへのセキュリティ修正プログラムのダウンロードとインストールが自動的に行われますが、必要な場合にノードの再起動が自動的に実行されることはありません。 Windows Server ノードの場合は、ポッドを安全に cordon および drain し、更新されたすべてのノードをデプロイするために、AKS のアップグレード操作を定期的に実行します。

• すべてのポッド内通信に対して HTTPS と gRPC のセキュリティで保護されたトランスポート プロトコルを使用することを検討してください。 また、Open Authorization (OAuth) や JSON Web Tokens (JWT) など、すべての要求でプレーンな資格情報を送信する必要のない、より高度な認証メカニズムを使用します。 Istio、Linkerd、Consul などのサービス メッシュを使用して、より安全なサービス内通信を確立します。 または、 Daprを使用できます。

コンテナレジストリ

コンテナー イメージをスキャンして脆弱性を検出し、検証に合格したイメージのみをデプロイします。 基本イメージとアプリケーション ランタイムを定期的に更新する。 次に、AKS クラスター内のワークロードを再デプロイします。 CI/CD デプロイ ワークフローには、コンテナー イメージをスキャンするプロセスを含める必要があります。 Microsoft Defender for DevOps セキュリティを使用して、ビルドフェーズとデプロイフェーズ中に自動化されたパイプラインの脆弱性についてコードをスキャンできます。 または、 Prisma Cloud や Aqua などのツールを使用して、検証済みイメージのみをスキャンしてデプロイできるようにすることもできます。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。

このアーキテクチャのコストは、次のコンポーネントなどの構成の側面によって異なります。

• サービス階層
• スケーラビリティ、または特定の需要をサポートするためにサービスが動的に割り当てるインスタンスの数
• 自動化スクリプト
• ディザスター リカバリー レベル

これらの側面を評価したら、 Azure 料金計算ツール を使用してコストを見積もります。 詳細については、「コストの最適化の ウェル アーキテクト フレームワークの原則を参照してください。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。

ストレージ

• 読み取りと書き込みの待機時間を短縮しノードのスケーリングとクラスターのアップグレードを高速化するエフェメラル OS ディスクを使用して AKS クラスターをデプロイすることを検討してください。

• 適切なストレージを選択するためのアプリケーションのニーズを理解します。 運用環境のワークロードには、高パフォーマンスの SSD ベースのストレージを使用します。 複数のポッドが同じファイルに同時にアクセスする必要がある場合は、Azure Files などのネットワーク ベースのストレージ システムを計画します。 詳細については、AKS でのアプリケーションのストレージ オプションに関するページを参照してください。

• 適切なサイズのノードをデプロイできるように、アプリケーションの需要を計画します。 各ノード サイズでは、最大数のディスクがサポートされます。 また、さまざまなノード サイズで、さまざまな量のローカル ストレージやネットワーク帯域幅が提供されます。

• 動的プロビジョニングを使用します。 管理オーバーヘッドを減らし、スケーリングを有効にするには、永続ボリュームを静的に作成して割り当てないでください。 ストレージ クラスで、ポッドを削除した後に不要なストレージ コストを最小限に抑えるために、適切な回収ポリシーを定義します。

DevOps

• GitHub Actions や Azure DevOps などの DevOps システムを使用して、CI/CD パイプラインの Helm グラフを使用してワークロードを AKS にデプロイします。 詳細については、AKS へのビルドとデプロイに関するページをご覧ください。

• すべてのユーザーにアプリケーションを導入する前に、アプリケーションのライフサイクル管理に A/B テストとカナリア デプロイを導入して、アプリケーションを適切にテストします。 同じサービスの異なるバージョン間でトラフィックを分割するために使用できる手法はいくつかあります。

• 別の方法として、サービス メッシュが提供するトラフィック管理機能を使用できます。 詳細については、「 Istio トラフィック管理」を参照してください。

• コンテナー レジストリまたは Docker Hub などの別のレジストリ ストアを使用して、クラスターにデプロイするプライベート Docker イメージをカタログ化して提供します。 AKS は、Microsoft Entra ID を使用して Container Registry で認証できます。

• Application Gateway の設定を変更する必要がある場合は、イングレス コントローラーまたはその他の Kubernetes オブジェクトで公開されている構成 (サポートされている注釈の使用など) を使用して変更を行います。 アプリケーション ゲートウェイを AGIC にリンクすると、イングレス コントローラーはそのゲートウェイのほぼすべての構成を同期および制御します。 Application Gateway を命令型またはコードとしてのインフラストラクチャを介して直接構成した場合、イングレス コントローラーは最終的にそれらの変更を上書きします。

監視

• AKS クラスターとワークロードの正常性状態を監視するには、Azure 統合監視オプションを検討します。

• 診断ログとメトリックを収集し、それらを Log Analytics に送信するように、コンテナー レジストリや Key Vault などのすべての PaaS サービスを構成。

パフォーマンス効率

パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。

パフォーマンスに関する考慮事項は、AKS のマルチテナントには完全には関係ありませんが、これはこのソリューションの必須要件です。

• 待機時間の短いワークロードの場合は、近接通信配置グループに専用ノード プールをデプロイすることを検討してください。 Azure にアプリケーションをデプロイすると、リージョンまたは可用性ゾーン間に分散された VM インスタンスによってネットワーク待機時間が発生し、アプリケーションの全体的なパフォーマンスに影響を与える可能性があります。 近接通信配置グループは、Azure コンピューティング リソースが物理的に互いに近い場所にあることを確認するために使用できる論理的なグループです。 ゲーム、エンジニアリング シミュレーション、高周波取引などの一部のユース ケースでは、待機時間が短く、すばやく完了するタスクが必要です。 このようなハイ パフォーマンス コンピューティング シナリオの場合は、クラスターのノード プールに proximity 配置グループ を使用することを検討してください。

• より高速なビルドを作成できるため、常に小さいコンテナー イメージを使用します。 また、攻撃対象領域が減少するため、画像が小さいほど攻撃ベクトルに対する脆弱性も低くなります。

• Kubernetes 自動スケーリングを使用して、トラフィックが増加したときに AKS クラスター内のワーカー ノードの数を動的にスケールアウトします。 Horizontal Pod Autoscaler クラスター オートスケーラーを使用すると、ノードとポッドのボリュームは、トラフィックの状態に合わせてリアルタイムで動的に調整され、容量の問題によって引き起こされるダウンタイムを回避できます。 詳細については、「AKS でのクラスター オートスケーラーの使用」をご覧ください。

スケジューラ

• クラスターオペレーターとアプリケーション開発者が AKS でアプリケーションを正常にビルドして実行するためにベスト プラクティスを確認して実装します。

• すべての名前空間の名前空間レベルでリソース クォータを計画して適用します。 ポッドでリソースの要求と制限が定義されていない場合は、デプロイを拒否します。 リソースの使用状況を監視し、必要に応じてクォータを調整します。 複数のチームまたはテナントが、固定数のノードを持つ AKS クラスターを共有する場合は、リソース クォータを使用して、各チームまたはテナントにリソースの公平な共有を割り当てることができます。

• 制限範囲を採用 CPU とメモリの観点から、名前空間内のポッドまたはコンテナーへのリソース割り当てを制限します。

• リソース 要求と制限を定義します アプリケーションのデプロイに使用する YAML マニフェストまたは Helm グラフで、ポッドの CPU とメモリの使用量に対して明示的に定義します。 ポッド内のコンテナーに対するリソース要求を指定すると、Kubernetes スケジューラではこの情報を使用して、ポッドを配置するノードを決定します。 CPU やメモリなど、コンテナーのリソース制限を指定すると、kubelet はこれらの制限を適用して、実行中のコンテナーが設定した制限よりも多くのリソースを使用できないようにします。

• ポッドの中断予算を定義してアプリケーションの可用性を維持しクラスターで使用できるポッドの最小数を確認します。

• priority クラスを使用して、ポッドの重要性を示します。 スケジューラがポッドをスケジュールできない場合、保留中のポッドをスケジュールできるように、優先順位の低いポッドの割り込み (削除) を試みます。

• Kubernetes taints と容認 を使用して、リソースを集中的に消費するアプリケーションを特定のノードに配置し、ノイズの多い近隣の問題を回避します。 ノード リソースを必要とするワークロードでノード リソースを使用できるようにします。 ノードで他のワークロードをスケジュールすることは許可しないでください。

• ノード セレクター、ノード アフィニティ、またはポッド間アフィニティを使用して、ノード上のポッドのスケジュール設定を制御します。 ポッド間 アフィニティとアンチアフィニティ 設定を使用して、通信が頻繁なポッドを併置し、ポッドを異なるノードに配置し、同じノード上で同じ種類のポッドの複数のインスタンスを実行しないようにします。

このシナリオのデプロイ

このシナリオのソース コードは、GitHub で入手できます。 次の図は、 AKS マルチテナント AGIC GitHub リポジトリで見つけることができるデモ アプリケーションを示しています。

このアーキテクチャの Visio ファイルをダウンロードします。

前提条件

オンライン デプロイの場合、既存の Azure アカウントが必要です。 お持ちでない場合は、開始する前に 無料の Azure アカウント を作成してください。

Azure に配置する

1. Azure サブスクリプション情報が手元にあることを確認します。

2. ワークベンチ GitHub リポジトリを複製します。

   git clone https://github.com/Azure-Samples/aks-agic.git
   

3. README.md ファイルに記載されている手順に従います。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

• Paolo Salvatori | プリンシパル サービス エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

• AKS クラスターのベスト プラクティス
• AKS におけるスケジューラの基本的な機能に関するベスト プラクティス
• プライベート AKS クラスターを作成する
• Application Gateway の WAF ポリシーを作成する
• Helm デプロイと AKS アドオンの違い
• アプリケーション ゲートウェイの動作

関連リソース

• AKS クラスターのベースライン アーキテクチャ

このソリューションでは、 Azure Web Application Firewall (WAF) を使用して、マルチテナント Azure Kubernetes Service (AKS) クラスターにデプロイする Web アプリケーションを一元的に保護します。 WAF は、一般的な悪用や脆弱性から保護するのに役立ちます。

Azure アプリlication Gateway でWAF ポリシーを使用すると、SQL インジェクションやクロスサイト スクリプティングなどの悪意のある攻撃から Web アプリケーションを保護できます。 このメソッドは、AKS クラスターで実行されアプリケーション ゲートウェイ イングレス コントローラー (AGIC)を介して公開される Web アプリケーションを保護するのに役立ちます。 Application Gateway の WAF ポリシーは、Open Worldwide Application Security Project (OWASP) Core Rule Set (CRS) で事前構成されており、他の OWASP CRS バージョンをサポートしています。 カスタム ルールを作成することもできます。

アーキテクチャ

このアーキテクチャの Visio ファイルをダウンロードします。

ワークフロー

• このアーキテクチャでは、コンパニオン Azure Resource Manager テンプレート (ARM テンプレート) を使用して、次の 4 つのサブネットを持つ新しい仮想ネットワークをデプロイします。

  • AksSubnet は AKS クラスターをホストします。
  • VmSubnet は、ジャンプボックス仮想マシン (VM) とプライベート エンドポイントをホストします。
  • AppGatewaySubnet は Application Gateway WAF2 層をホストします。
  • AzureBastionSubnet は Azure Bastion をホストします。

• AKS クラスターでは、ユーザー定義のマネージド ID を使用して、ロード バランサーやマネージド ディスクなどのリソースをさらに Azure に作成します。 ARM テンプレートを使用して、次の機能を備える AKS クラスターをデプロイできます。

  • Azure ディスクと Azure Files 用の Container Storage Interface (CSI) ドライバー
  • AKS マネージド Microsoft Entra の統合
  • Kubernetes 認証用 Azure ロールベースのアクセス制御 (RBAC)
  • サービス プリンシパルの代わりにマネージド ID
  • Microsoft Entra ワークロード ID
  • Azure ネットワーク ポリシー
  • Azure Monitor container insights アドオン
  • AGIC アドオン
  • IP アドレスの動的割り当てと拡張サブネットのサポート

• AKS クラスターには、次のノード プールがあります。

  • システム ノード プールは重要なシステム ポッドとサービスのみをホストします。 ワーカー ノードにはノード テイントがあり、このノード プールでアプリケーション ポッドがスケジュールされないようにします。
  • ユーザー ノード プールは、ユーザーのワークロードと成果物をホストします。

• VM は、AKS クラスターをホストするのと同じ仮想ネットワークにデプロイされます。 AKS をプライベート クラスターとしてデプロイする場合、システム管理者はこの VM を使用して、Kubernetes コマンドライン ツールからクラスターを管理できます。 この VM のブート診断ログは、Azure Storage アカウントに格納されます。

• Azure Bastion ホストは、Secure Sockets Layer (SSL) を介して Azure portal で直接、ジャンプボックス VM へのセキュリティで保護されたシームレスな Secure Shell (SSH) 接続を提供します。 このソリューションでは、Azure Container Registry を使用して、Helm チャートなどのコンテナー イメージと成果物をビルド、格納、管理します。

• このアーキテクチャには、イングレス コントローラーが使用するアプリケーション ゲートウェイが含まれています。 アプリケーション ゲートウェイは専用サブネットにデプロイされ、すべてのテナント ワークロードが共有するパブリック IP アドレスを介してパブリック インターネットに公開されます。 WAF ポリシーは、テナント ワークロードを悪意のある攻撃から保護するのに役立ちます。

  WAF ポリシーは、ルート レベルおよび HTTP リスナー レベルでアプリケーション ゲートウェイに関連付けられます。 ポリシーは防止モードで構成され、 OWASP 3.1 を使用して、ルールが検出する侵入と攻撃をブロックします。 攻撃者は 403 未承認のアクセス 例外を受け取り、接続が閉じられます。 防止モードの場合、このような攻撃は WAF ログに記録されます。

• AKS で実行されるワークロードでは、キー コンテナーをシークレット ストアとして使用し、クライアント ライブラリ、Secrets ストア CSI ドライバー、または Dapr を使用してキー、証明書、シークレットを取得します。 Azure Private Link を使用すると、AKS ワークロードは、仮想ネットワーク内のプライベート エンドポイント経由で Azure Key Vault などの Azure サービスとしてのプラットフォーム (PaaS) ソリューションにアクセスできます。

• このアーキテクチャには、次のコンポーネントへのプライベート エンドポイントが含まれています。

  • Azure Blob Storage アカウント
  • コンテナレジストリ
  • Key Vault (キー・ボールト)
  • プライベート AKS クラスターを使用する場合は、Kubernetes クラスターの API サーバー

• このアーキテクチャには、PaaS サービスの完全修飾ドメイン名 (FQDN) を、関連付けられているプライベート エンドポイントのプライベート IP アドレスに解決するためのプライベート DNS ゾーンも含まれています。 このアーキテクチャには、プライベート エンドポイントを次のコンポーネントに解決するためのプライベート DNS ゾーンが含まれています。

  • Blob Storage アカウント
  • コンテナレジストリ
  • Key Vault (キー・ボールト)
  • Kubernetes Server API (クラスターをプライベートとしてデプロイする場合)

• AKS クラスターをホストする仮想ネットワークと、上記のプライベート DNS ゾーンの間に仮想ネットワーク リンクが存在します。 Log Analytics ワークスペースは、次のソースから診断ログとメトリックを収集します。

  • AKS クラスター
  • ジャンプボックス VM
  • アプリケーション ゲートウェイ
  • Key Vault (キー・ボールト)
  • Azure ネットワーク セキュリティ グループ

コンポーネント

• Container Registry は、オープンソースの Docker Registry 2.0 が基になっている、マネージド型のプライベート Docker レジストリ サービスです。 既存のコンテナー開発およびデプロイ パイプラインで Azure コンテナー レジストリを使用できます。 または、Container Registry タスクを使用して、Azure でコンテナー イメージをビルドします。 オンデマンドでビルドしたり、ソース コードのコミットや基本イメージの更新などのトリガーを使用してビルドを完全に自動化したりできます。

• AKS は、運用オーバーヘッドを Azure にオフロードすることで、Azure でのマネージド Kubernetes クラスターのデプロイを簡略化します。 ホストされた Kubernetes サービスとして、Azure によって正常性監視やメンテナンスなどの重要なタスクが処理されます。 Azure では Kubernetes コントロール プレーン ノードが管理されるため、エージェント ノードの管理と保守のみが行われます。

• Key Vault は、API キー、パスワード、証明書、暗号化キーなどのシークレットへのアクセスを安全に格納および制御するのに役立ちます。 Key Vault を使用すると、パブリックおよびプライベートトランスポート層セキュリティ (TLS) 証明書または SSL 証明書を簡単にプロビジョニング、管理、デプロイし、Azure および内部接続リソースで使用できます。

• Application Gateway は、ダウンストリーム Web アプリケーションと REST API に送信される受信トラフィックを管理するために使用できる Web トラフィック ロード バランサーです。 従来のロード バランサーは、伝送制御プロトコル (TCP) とユーザー データグラム プロトコル (UDP) を使用するトラフィックを処理するために、オープン システム相互接続 (OSI) レイヤー 4 であるトランスポート層で動作します。 トラフィックは送信元 IP アドレスとポートに基づいて送信先 IP アドレスとポートにルーティングされます。 アプリケーション ゲートウェイは、アプリケーション レイヤー (OSI レイヤー 7) のロード バランサーです。

• WAF は、一般的な悪用や脆弱性から Web アプリケーションを一元的に保護するのに役立つサービスです。 WAF は、 OWASP CRS からの規則に基づいています。 WAF を使用して、ポリシーを通過する要求ごとに評価されるカスタム 規則を作成できます。 これらの規則は、マネージド規則セット内の他の規則よりも高い優先度を持ちます。 カスタム規則には、規則名、規則の優先度、一致条件の配列が含まれます。 要求がこれらの条件を満たしている場合、WAF は規則に基づいて要求を許可またはブロックします。

• Azure Bastion は、お使いの仮想ネットワーク内でプロビジョニングする、フル マネージドPaaS (サービスとしてのプラットフォーム) です。 Azure Bastion は、TLS 経由で Azure portal から直接、仮想ネットワーク内の VM への安全でシームレスなリモート デスクトップ プロトコル (RDP) と SSH 接続を提供するのに役立ちます。

• Azure Virtual Machines では、物理ハードウェアを購入して保守することなく、仮想化の柔軟性を提供する、オンデマンドでスケーラブルなコンピューティング リソースが提供されます。

• Azure Virtual Network は、Azure のプライベート ネットワークの基本的な構成ブロックです。 Virtual Network を使用すると、VM などの Azure リソースは、より安全な方法で相互、インターネット、およびオンプレミス ネットワークと通信できます。 Azure Virtual Network は、オンプレミスの従来のネットワークと似ていますが、スケーラビリティ、可用性、分離などの Azure インフラストラクチャのメリットが得られます。

• 仮想ネットワーク インターフェイス は、Azure VM とインターネット、Azure、オンプレミスのリソース間の通信を確立するのに役立ちます。 1 つの Azure VM に複数のネットワーク インターフェイス カードを追加できるため、子 VM で独自の専用ネットワーク インターフェイス デバイスと IP アドレスを使用できます。

• Azure マネージド ディスクは、Azure が Azure VM 上で管理するブロックレベルのストレージ ボリュームです。 ディスクの種類には、Azure Ultra Disk Storage、Azure Premium SSD、Azure Standard SSD、Azure Standard HDD が含まれます。

• Blob Storage は、クラウド用の Microsoft オブジェクト ストレージ ソリューションです。 Blob Storage は、テキスト データやバイナリ データなどの大量の非構造化データを格納するために最適化されています。 非構造化データとは、テキスト データやバイナリ データなど、特定のデータ モデルや定義に準拠していないデータです。

• Private Link は、Blob Storage や Key Vault などの Azure PaaS サービスにアクセスし、Azure でホストされている顧客所有のサービスまたはパートナー サービスにアクセスできるように、仮想ネットワーク内のプライベート エンドポイントを提供します。

代替

AKS クラスターでホストするワークロードを公開する場合は、考慮すべきいくつかのソリューションがあります。 AGIC を使用する代わりに、Application Gateway for Containers を使用するかアプリケーション ルーティング アドオンで NGINX イングレスを管理。 これらの代替手段は、AKS クラスターへのトラフィックの管理とセキュリティ保護に役立つさまざまな機能を提供します。

このアーキテクチャでは、AKS の AGIC アドオンを使用して、AGICをインストールします。 Helm チャートを使用して AGIC を インストールすることもできます。 新しいセットアップを作成するときに、Azure CLI で 1 行を使用して、新しいアプリケーション ゲートウェイと新しい AKS クラスターをデプロイできます。 このメソッドは、アドオンとして AGIC を有効にします。 アドオンはフル マネージド サービスであり、自動更新やサポートの強化など、追加の利点を提供します。 また、AKS とのより優れた統合を提供する、ファーストクラスのアドオンとも見なされます。 Microsoft では、AGIC の両方の展開方法がサポートされています。

AGIC アドオンは、AKS クラスターにポッドとしてデプロイされます。 ただし、Helm デプロイ バージョンと AGIC のアドオン バージョンにはいくつかの違いがあります。 次のリストでは、2 つのバージョンの違いを示します。

• AKS アドオンで Helm デプロイの値を変更することはできません。

  • 既定では、usePrivateIp プロパティは false に設定されます。 use-private-ip注釈を使用してこの値を上書きすることはできません。
  • アドオンは、 shared 構成オプションをサポートしていません。

• Helm でデプロイされた AGIC では、 ProhibitedTargetsがサポートされています。つまり、AGIC は、他の既存のバックエンドに影響を与えることなく、AKS クラスター専用にアプリケーション ゲートウェイを構成できます。

• AGIC アドオンはマネージド サービスであるため、最新バージョンに自動的に更新されます。 Helm 経由で AGIC をデプロイする場合は、AGIC を手動で更新する必要があります。

• AKS クラスターごとにデプロイできる AGIC アドオンは 1 つだけです。 各 AGIC アドオンは、1 つの Application Gateway インスタンスのみを対象とすることができます。 クラスターごとに複数の AGIC を必要とするデプロイ、または 1 つの Application Gateway インスタンスを対象とする複数の AGIC の場合は、Helm でデプロイされた AGIC を使用できます。

AGIC の 1 つのインスタンスは、複数の Kubernetes 名前空間からイベントを取り込むことができます。 AKS 管理者がアプリケーション ゲートウェイをイングレスとして使用する場合、すべての名前空間で Application Gateway の同じインスタンスが使用されます。 AGIC を 1 回インストールすると、アクセス可能な名前空間が監視され、関連付けられているアプリケーション ゲートウェイが構成されます。 詳細については、「 AGIC を使用した AKS クラスターでの複数名前空間のサポートを有効」を参照してください。

複数名前空間のサポートを有効にするには、次の手順を実行します。

1. 次のいずれかの方法で、helm-config.yaml ファイルを変更します。

• watchNamespace キーを helm-config.yaml ファイルから完全に削除して、AGIC ですべての名前空間を観察できるようにします。
• watchNamespaceを空の文字列に設定して、AGIC ですべての名前空間を観察できるようにします。
• など、コンマで区切られた複数の名前空間を追加して、AGIC がこれらの名前空間のみを監視できるようにします。

2. 次のスクリプトを使用して Helm テンプレートの変更を適用します: helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure。

複数の名前空間を監視する機能を持つ AGIC をデプロイすると、AGIC は次のアクションを実行します。

1. アクセス可能なすべての名前空間からのイングレス リソースを一覧表示します
2. 注釈が付けられたイングレス リソースをフィルター処理する kubernetes.io/ingress.class: azure/application-gateway
3. 組み合わせた Application Gateway 構成を作成します。
4. Azure Resource Manager を使用して、関連付けられているアプリケーション ゲートウェイに構成を適用します。

シナリオの詳細

このアーキテクチャは、マルチテナント Kubernetes クラスターを複数のユーザーとワークロード間で共有します。これは、一般的に テナントと呼ばれます。 この定義には、Kubernetes クラスターを共有する組織内のさまざまなチームまたは部門が含まれます。 また、サービスとしてのソフトウェア (SaaS) アプリケーションの顧客ごとのインスタンスによって共有されるクラスターも含まれます。 クラスター マルチテナント機能は、多数のシングルテナント専用クラスターを管理することに代わる手段です。 マルチテナントの Kubernetes クラスターのオペレーターは、テナントを相互に分離する必要があります。 この分離により、侵害されたテナントまたは悪意のあるテナントがクラスターや他のテナントに及ぼす可能性がある損害を最小限に抑えることができます。 複数のユーザーまたはチームが、固定数のノードを持つ同じクラスターを共有している場合、1 つのチームが必要以上に多くのリソースを使用する可能性があります。 管理者は、 リソース クォータを使用して この問題に対処できます。

マルチテナント AKS クラスターを構築する場合は、クラスター、名前空間、ノード、ポッド、コンテナーの分離など、Kubernetes が提供するリソース分離のレイヤーを検討する必要があります。 また、複数のテナント間で異なる種類のリソースを共有することによるセキュリティへの影響についても考慮する必要があります。 たとえば、同じノード上の異なるテナントのポッドをスケジュールする場合、クラスターで必要なマシンの数を減らすことができます。 一方、特定のワークロードが併置されないようにする必要がある場合もあります。 たとえば、ユーザーの組織外で作成された信頼できないコードは、機密情報を処理するコンテナーと同じノード上で実行しないようにすることができます。 Azure Policy を使用して、信頼されたレジストリのみを AKS にデプロイできます。

Kubernetes は、テナント間の完全に安全な分離を保証することはできませんが、特定のユース ケースに十分なセキュリティを提供する機能を提供します。 ベスト プラクティスとして、各テナントとその Kubernetes リソースを、それぞれ独自の名前空間に分ける必要があります。 その後、 Kubernetes RBAC および network ポリシーを使用して テナントの分離を強制できます。 たとえば、次の図は、同じクラスター上の同じアプリケーションの複数のインスタンス (テナントごとに 1 つ) をホストする一般的な SaaS プロバイダー モデルを示しています。 各アプリケーションは個別の名前空間にあります。 より高いレベルの物理的分離とパフォーマンスの保証が必要なテナントは、専用のノード セット、専用プール、さらには専用クラスターにワークロードをデプロイできます。

AGIC は Kubernetes アプリケーションであるため、AKS のお客様は、アプリケーション ゲートウェイを使用してコンテナー化されたアプリケーションをインターネットに公開できます。 AGIC は、ホストされている Kubernetes クラスターを監視し、選択したサービスがインターネットに公開されるようにアプリケーション ゲートウェイを継続的に更新します。 AGIC は、顧客の AKS インスタンス上の独自のポッドで実行されます。 AGIC は、Kubernetes リソースのサブセットの変更を監視します。 AKS クラスターの状態は Application Gateway 固有の構成に変換され、 Resource Manager に適用されます。 このアーキテクチャでは、パブリックまたはプライベートのAKS クラスターアプリケーション ゲートウェイおよび AGIC アドオンを使用してデプロイする実証済みのプラクティスについて説明します。

AGIC の 1 つのインスタンスは、複数の名前空間からイベントを取り込んで観察できます。 AKS 管理者が Application Gateway をイングレスとして使用する場合、すべての名前空間で Application Gateway の同じインスタンスが使用されます。 AGIC を 1 回インストールすると、アクセス可能な名前空間が監視され、関連付けられているアプリケーション ゲートウェイが構成されます。

考えられるユース ケース

AGIC を使用して、マルチテナント環境でAKS クラスターで実行されるインターネットに接続するワークロードを公開および保護します。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

これらの考慮事項の一部は、AKS のマルチテナントに完全には関係しませんが、このソリューションの必須要件です。 これらの考慮事項には、セキュリティ、パフォーマンス、可用性、信頼性、ストレージ、スケジューラ、サービス メッシュ、監視のガイダンスが含まれます。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。

これらの可用性と信頼性に関する考慮事項は、AKS のマルチテナントには完全には関係しませんが、このソリューションの必須要件です。 AKS クラスターとワークロードの可用性を最適化するため、次の方法をご検討ください。

コンテナー

• Kubernetes 正常性プローブを使用して、コンテナーが正常に機能していることを確認します。

  • livenessProbe では、コンテナーが実行中かどうかを示します。 ライブネス プローブが失敗した場合、 kubelet はコンテナーを終了し、コンテナーには再起動ポリシーが適用されます。

  • readinessProbe では、コンテナーが要求に応答できる状態かどうかを示します。 準備プローブが失敗した場合、エンドポイント コントローラーはポッドに一致するすべてのサービスのエンドポイントからポッドの IP アドレスを削除します。 初期遅延前の準備状態の既定の状態は 失敗。

  • startupProbeは、コンテナー内のアプリケーションが開始されているかどうかを示します。 スタートアップ プローブがある場合、スタートアップ プローブが成功するまで、他のすべてのプローブは無効になります。 スタートアップ プローブが失敗した場合、 kubelet はコンテナーを終了し、コンテナーには再起動ポリシーが適用されます。

• リソースの競合がサービスの可用性に影響を与える場合があります。 1 つのコンテナーがクラスター メモリおよび CPU のリソースを占有できなくなるように、コンテナー リソースの制約を定義します。 AKS 診断を使用して、クラスター内の問題を特定できます。

• リソース制限を使用して、1 つのコンテナーが他のコンテナーを奪えないように、コンテナーに割り当てられたリソースの合計を制限します。

コンテナレジストリ

• コンテナー レジストリにコンテナー イメージを格納します。 Container Registry geo レプリケーションを使用して、レジストリを各 AKS リージョンに geo レプリケートします。 geo レプリケーションは、Premium SKU コンテナー レジストリの機能です。

• コンテナー イメージをスキャンして脆弱性を探す。 検証に合格したイメージのみをデプロイします。 基本イメージおよびアプリケーション ランタイムを定期的に更新し、AKS クラスターにワークロードを再デプロイします。

• ポッドおよびデプロイで使用できるイメージ レジストリを制限します。 使用可能なイメージを検証および制御できる信頼されたレジストリへのアクセスを制限します。

• コンテナー レジストリにイメージを発行する前に、継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインの一部としてコンテナー イメージの脆弱性をスキャンします。 アプリケーション イメージに基本イメージを使用する場合は、基本イメージを更新するときに、自動化を使用して新しいイメージをビルドします。 基本イメージには通常、セキュリティ修正プログラムが含まれているため、ダウンストリーム アプリケーション コンテナー イメージを更新する必要があります。 Microsoft Defender for Containers を CI/CD ワークフローに統合することをお勧めします。 詳細については、「 Automate コンテナー イメージ ビルド」を参照してください。

• Container Registry タスクを使用して、Docker コンテナーの OS とフレームワークの修正プログラムの適用を自動化します。 コンテナー レジストリ タスクでは、コンテナーの基本イメージを更新するときの自動ビルド プロセスがサポートされます。 たとえば、いずれかの基本イメージで OS またはアプリケーション フレームワークにパッチを適用できます。

リージョン内の回復性

• リージョン内のすべての 可用性ゾーン に AKS クラスターのノード プールをデプロイすることを検討してください。 ノード プールの前 Azure Standard Load Balancer または Application Gateway を使用します。 このトポロジでは、単一のデータセンターの停止が発生した場合の回復性が向上します。 この方法では、リージョン内の 3 つの個別の可用性ゾーンに存在する複数のデータセンターにクラスター ノードを分散します。

• リージョン内の回復性と高可用性を実現するため、 Container Registry のゾーン冗長 を有効にします。

• ポッド トポロジの分散制約を使用してリージョン、可用性ゾーン、ノードなどの障害ドメイン間でポッドを AKS クラスター全体に分散する方法を制御します。

• ミッション クリティカルなワークロードをホストする AKS クラスターのアップタイム サービス レベル アグリーメント (SLA) の使用を検討してください。 アップタイム SLA は、クラスターに対して財務的に支援されたより高い SLA を有効にするオプションの機能です。 アップタイム SLA では、可用性ゾーンを使用するクラスターに対して、Kubernetes API サーバー エンドポイントの 99.95% の可用性が保証されます。 可用性ゾーンを使用しないクラスターでは、99.90% の可用性が保証されます。 AKS では、SLA 要件を満たすために、更新ドメインと障害ドメイン間でコントロール プレーン ノードレプリカが使用されます。

ディザスター リカバリーと事業継続

• 1 つの地域内の少なくとも 2 組の Azure リージョン ペア にソリューションをデプロイすることを検討します。 また、Azure Traffic Manager、Azure Front Door などのグローバル ロード バランサー採用する必要があります。 ロード バランサーをアクティブ/アクティブ/アクティブ/パッシブ ルーティング方法と組み合わせて、ビジネス継続性とディザスター リカバリーを保証します。

• 品質保証環境でリージョンのフェールオーバー プロセスをスクリプト化、文書化、および定期的にテストします。 フェールオーバー プロセスは、プライマリ リージョンの停止がコア サービスに影響を与える場合に、予期しない問題を回避するのに役立ちます。

• フェールオーバー プロセス テストを使用して、ディザスター リカバリーアプローチが目標復旧ポイント (RPO) と目標復旧時間 (RTO) を満たしているかどうかを確認します。 手動のプロセスと介入を検証に含めます。

• フェールバック プロシージャをテストして、想定どおりに動作することを確認します。

• コンテナー イメージを Container Registry に格納します。 レジストリを各 AKS リージョンに geo レプリケートします。 詳細については、「コンテナー レジストリの Geo レプリケーション」を参照してください。

• 可能な場合は、コンテナー内にサービス状態を格納しないでください。 代わりに、マルチリージョン レプリケーションをサポートする Azure PaaS を使用します。

• Azure Storage を使用する場合は、プライマリ リージョンからバックアップ リージョンにストレージを移行する方法を準備してテストします。

• GitOps を使用してクラスター構成をデプロイすることを検討してください。 GitOps では、プライマリ クラスターとディザスター リカバリー クラスターの間の統一性が提供され、失った場合に新しいクラスターをすばやく再構築する方法も提供されます。

• AKS バックアップVelero などのツールを使用して、クラスター構成のバックアップと復元を検討。

サービス メッシュ

• AKS クラスターで、 Istio、 Linkerd、 Consul などのオープン ソース サービス メッシュを使用することを検討してください。 サービス メッシュは相互 TLS を使用して、マイクロサービスの可観測性、信頼性、およびセキュリティを向上させます。 ブルー/グリーンデプロイやカナリアデプロイなどのトラフィック分割戦略を実装することもできます。 サービス メッシュは、サービス間通信の安全性、高速性、信頼性を高めるのに役立つ専用のインフラストラクチャ レイヤーです。 詳細については、「 Istio サービス メッシュ AKS アドオン」を参照してください。

• Daprを採用して、ステートレスでステートフルであるかどうかに関係なく、回復性の高いマイクロサービス ベースのアプリケーションを構築することを検討してください。 任意のプログラミング言語と開発者フレームワークを使用できます。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。

セキュリティに関する考慮事項は、AKS のマルチテナントには完全には関係ありませんが、このソリューションの必須要件です。

マルチテナント

• AKS クラスターをマルチテナント機能用に設計します。 Kubernetes には、同じクラスター内のチームとワークロードを論理的に分離するために使用できる機能が用意されています。 各チームが必要とするリソースに最小限の特権を指定します。 Kubernetes の namespace によって論理分離境界が作成されます。

• 論理的な分離を使用して、チームとプロジェクトを分離します。 チームまたはアプリケーションを分離するためにデプロイする物理 AKS クラスターの数を最小限に抑えます。 クラスターを論理的に分離すると、通常、物理的に分離されたクラスターよりもポッド密度が高くなります。

• 厳密な物理的分離を実装する必要がある場合は常に、専用ノード プールまたは専用 AKS クラスターを使用します。 たとえば、ワーカー ノードのプール、またはクラスター全体をマルチテナント環境のチームまたはテナント専用にすることができます。

  コンテナーと容認の組み合わせを使用して特定のノード プールへのポッドのデプロイを制御します。 ノード プールの作成時に AKS 内のノードのみをテイントできます。 または、 ラベルと nodePool セレクターを使用して 特定のノード プールにのみワークロードをデプロイすることもできます。

ネットワークのセキュリティ

• AKS ワークロードが使用するすべての PaaS サービス (Key Vault、Azure Service Bus、Azure SQL Database など) に対してプライベート エンドポイントを作成します。 プライベート エンドポイントは、アプリケーションとこれらのサービス間のトラフィックがパブリック インターネットに公開されないようにするのに役立ちます。 詳細については、「 Private Link とはを参照してください。

• HTTPS 経由でワークロードを公開するように Kubernetes イングレス リソースを構成します。 テナントごとに個別のサブドメインとデジタル証明書を使用します。 AGIC は、SSL 終了用に Application Gateway リスナーを自動的に構成します。

• AKS で実行される一般向けワークロードを悪意のある攻撃から保護するためにWAF ポリシーを使用するようにapplication Gateway を構成します。

• AKS で Azure CNI ネットワークを使用して、既存の仮想ネットワークまたはオンプレミス ネットワークと統合します。 このネットワーク モデルでは、エンタープライズ環境でリソースとコントロールをさらに分離することもできます。

• ネットワーク ポリシーを使用し、相互に通信できるコンポーネントを制御することにより、サービス内通信を分離し、セキュリティで保護します。 既定では、Kubernetes クラスター内のすべてのポッドでは制限なしにトラフィックを送受信できます。 セキュリティ向上のため、Azure ネットワーク ポリシーまたは Calico ネットワーク ポリシーを使用して、さまざまなマイクロサービス間のトラフィック フローを制御するルールを定義できます。 詳細については、「 Network ポリシー」を参照してください。

• AKS ノードへのリモート接続は公開しないでください。 管理仮想ネットワークに要塞ホスト (ジャンプボックス) を作成します。 踏み台ホストを使用すると、AKS クラスターへのトラフィックをリモート管理タスクに安全にルーティングできます。

• AKS で 認証された IP アドレス範囲 を使用して、運用環境に private AKS クラスター を作成することを検討してください。 プライベート AKS クラスターを使用できない場合は、少なくとも API サーバーへのアクセスをセキュリティで保護します。

• Azure DDoS Protection とアプリケーション設計のベスト プラクティスを組み合わせて、強化された DDoS 軽減機能と DDoS 攻撃に対する追加の防御を提供します。 境界仮想ネットワークで DDoS Protection を有効にします。

認証と権限承認

• Microsoft Entra 統合を使って AKS クラスターをデプロイします。 詳細については、AKS マネージド Microsoft Entra 統合に関する記事を参照してください。 Microsoft Entra ID は、ID 管理コンポーネントを一元化します。

• Kubernetes RBAC を使用して、クラスターのリソースに対するユーザーまたはグループのアクセス許可を定義します。 roles または ClusterRoles および bindings を使用して、ユーザーまたはグループのスコープを必要最小限のアクセス許可に設定します。 Kubernetes RBAC を Microsoft Entra ID と統合して、ユーザーの状態またはグループ メンバーシップを変更すると、クラスター リソースへのアクセスが自動的に更新されるようにします。 詳細については、「 Kubernetes RBAC」を参照してください。

• Azure RBAC を使用して、ユーザーまたはグループが 1 つ以上のサブスクリプションの AKS リソースに対して持つ必要最小限のアクセス許可を定義します。 詳細については、「Kubernetes 認可に Azure RBAC を使用する」を参照してください。

• Microsoft Entra ワークロード IDを使用して、Azure リソース アクセス用の個々のマイクロサービスにマネージド ID を割り当てます。 その後、マイクロサービスは、Key Vault、SQL Database、Service Bus、Azure Cosmos DB などのマネージド リソースにアクセスできます。 マイクロサービスは、Kubernetes シークレットから接続文字列または資格情報を格納および取得する必要はありません。

• Secrets Store CSI Driver for Key Vault を使用して資格情報や接続文字列などのシークレットに、Kubernetes シークレットからではなく Key Vault からアクセスします。

• Dapr シークレット ストア構成要素を Key Vault ストアと Kubernetes 上のマネージド ID と組み合わせて資格情報や接続文字列などのシークレットを Key Vault から取得します。

ワークロードとクラスター

• クラスターをセキュリティで保護するために、Kubernetes API サーバーへのアクセスをセキュリティで保護します。 Kubernetes RBAC を Microsoft Entra ID と統合して、API サーバーへのアクセスを制御します。 これらのコントロールを使用して、Azure サブスクリプション アクセスの場合と同じ方法で AKS をセキュリティで保護します。

• コンテナーで実行できるアクションへのアクセスを制限します。 ポッドの作成と更新の詳細な承認を有効にするにはPod Security Admission 機能を使用します。 最小限のアクセス許可を付与し、ルートまたは特権エスカレーションの使用を避けます。 詳細については、「 リソースへの安全なポッド アクセスを参照してください。

• 可能な限り、コンテナーをルート ユーザーとして実行しないでください。

• AppArmor Linux カーネル セキュリティ モジュールを使用して、コンテナーが実行できるアクションを制限します。

• 新しい機能とバグ修正を利用するために、AKS クラスターを最新の Kubernetes バージョンに定期的にアップグレードします。

• kured デーモンセットを使用して、保留中の再起動、切断、ドレイン ノードを監視し、更新プログラムを適用します。 AKS により、各 Linux ノードへのセキュリティ修正プログラムのダウンロードとインストールが自動的に行われますが、必要な場合にノードの再起動が自動的に実行されることはありません。 Windows Server ノードの場合は、ポッドを安全に cordon および drain し、更新されたすべてのノードをデプロイするために、AKS のアップグレード操作を定期的に実行します。

• すべてのポッド内通信に対して HTTPS と gRPC のセキュリティで保護されたトランスポート プロトコルを使用することを検討してください。 また、Open Authorization (OAuth) や JSON Web Tokens (JWT) など、すべての要求でプレーンな資格情報を送信する必要のない、より高度な認証メカニズムを使用します。 Istio、Linkerd、Consul などのサービス メッシュを使用して、より安全なサービス内通信を確立します。 または、 Daprを使用できます。

コンテナレジストリ

コンテナー イメージをスキャンして脆弱性を検出し、検証に合格したイメージのみをデプロイします。 基本イメージとアプリケーション ランタイムを定期的に更新する。 次に、AKS クラスター内のワークロードを再デプロイします。 CI/CD デプロイ ワークフローには、コンテナー イメージをスキャンするプロセスを含める必要があります。 Microsoft Defender for DevOps セキュリティを使用して、ビルドフェーズとデプロイフェーズ中に自動化されたパイプラインの脆弱性についてコードをスキャンできます。 または、 Prisma Cloud や Aqua などのツールを使用して、検証済みイメージのみをスキャンしてデプロイできるようにすることもできます。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。

このアーキテクチャのコストは、次のコンポーネントなどの構成の側面によって異なります。

• サービス階層
• スケーラビリティ、または特定の需要をサポートするためにサービスが動的に割り当てるインスタンスの数
• 自動化スクリプト
• ディザスター リカバリー レベル

これらの側面を評価したら、 Azure 料金計算ツール を使用してコストを見積もります。 詳細については、「コストの最適化の ウェル アーキテクト フレームワークの原則を参照してください。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。

ストレージ

• 読み取りと書き込みの待機時間を短縮しノードのスケーリングとクラスターのアップグレードを高速化するエフェメラル OS ディスクを使用して AKS クラスターをデプロイすることを検討してください。

• 適切なストレージを選択するためのアプリケーションのニーズを理解します。 運用環境のワークロードには、高パフォーマンスの SSD ベースのストレージを使用します。 複数のポッドが同じファイルに同時にアクセスする必要がある場合は、Azure Files などのネットワーク ベースのストレージ システムを計画します。 詳細については、AKS でのアプリケーションのストレージ オプションに関するページを参照してください。

• 適切なサイズのノードをデプロイできるように、アプリケーションの需要を計画します。 各ノード サイズでは、最大数のディスクがサポートされます。 また、さまざまなノード サイズで、さまざまな量のローカル ストレージやネットワーク帯域幅が提供されます。

• 動的プロビジョニングを使用します。 管理オーバーヘッドを減らし、スケーリングを有効にするには、永続ボリュームを静的に作成して割り当てないでください。 ストレージ クラスで、ポッドを削除した後に不要なストレージ コストを最小限に抑えるために、適切な回収ポリシーを定義します。

DevOps

• GitHub Actions や Azure DevOps などの DevOps システムを使用して、CI/CD パイプラインの Helm グラフを使用してワークロードを AKS にデプロイします。 詳細については、AKS へのビルドとデプロイに関するページをご覧ください。

• すべてのユーザーにアプリケーションを導入する前に、アプリケーションのライフサイクル管理に A/B テストとカナリア デプロイを導入して、アプリケーションを適切にテストします。 同じサービスの異なるバージョン間でトラフィックを分割するために使用できる手法はいくつかあります。

• 別の方法として、サービス メッシュが提供するトラフィック管理機能を使用できます。 詳細については、「 Istio トラフィック管理」を参照してください。

• コンテナー レジストリまたは Docker Hub などの別のレジストリ ストアを使用して、クラスターにデプロイするプライベート Docker イメージをカタログ化して提供します。 AKS は、Microsoft Entra ID を使用して Container Registry で認証できます。

• Application Gateway の設定を変更する必要がある場合は、イングレス コントローラーまたはその他の Kubernetes オブジェクトで公開されている構成 (サポートされている注釈の使用など) を使用して変更を行います。 アプリケーション ゲートウェイを AGIC にリンクすると、イングレス コントローラーはそのゲートウェイのほぼすべての構成を同期および制御します。 Application Gateway を命令型またはコードとしてのインフラストラクチャを介して直接構成した場合、イングレス コントローラーは最終的にそれらの変更を上書きします。

監視

• AKS クラスターとワークロードの正常性状態を監視するには、Azure 統合監視オプションを検討します。

• 診断ログとメトリックを収集し、それらを Log Analytics に送信するように、コンテナー レジストリや Key Vault などのすべての PaaS サービスを構成。

パフォーマンス効率

パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。

パフォーマンスに関する考慮事項は、AKS のマルチテナントには完全には関係ありませんが、これはこのソリューションの必須要件です。

• 待機時間の短いワークロードの場合は、近接通信配置グループに専用ノード プールをデプロイすることを検討してください。 Azure にアプリケーションをデプロイすると、リージョンまたは可用性ゾーン間に分散された VM インスタンスによってネットワーク待機時間が発生し、アプリケーションの全体的なパフォーマンスに影響を与える可能性があります。 近接通信配置グループは、Azure コンピューティング リソースが物理的に互いに近い場所にあることを確認するために使用できる論理的なグループです。 ゲーム、エンジニアリング シミュレーション、高周波取引などの一部のユース ケースでは、待機時間が短く、すばやく完了するタスクが必要です。 このようなハイ パフォーマンス コンピューティング シナリオの場合は、クラスターのノード プールに proximity 配置グループ を使用することを検討してください。

• より高速なビルドを作成できるため、常に小さいコンテナー イメージを使用します。 また、攻撃対象領域が減少するため、画像が小さいほど攻撃ベクトルに対する脆弱性も低くなります。

• Kubernetes 自動スケーリングを使用して、トラフィックが増加したときに AKS クラスター内のワーカー ノードの数を動的にスケールアウトします。 Horizontal Pod Autoscaler クラスター オートスケーラーを使用すると、ノードとポッドのボリュームは、トラフィックの状態に合わせてリアルタイムで動的に調整され、容量の問題によって引き起こされるダウンタイムを回避できます。 詳細については、「AKS でのクラスター オートスケーラーの使用」をご覧ください。

スケジューラ

• クラスターオペレーターとアプリケーション開発者が AKS でアプリケーションを正常にビルドして実行するためにベスト プラクティスを確認して実装します。

• すべての名前空間の名前空間レベルでリソース クォータを計画して適用します。 ポッドでリソースの要求と制限が定義されていない場合は、デプロイを拒否します。 リソースの使用状況を監視し、必要に応じてクォータを調整します。 複数のチームまたはテナントが、固定数のノードを持つ AKS クラスターを共有する場合は、リソース クォータを使用して、各チームまたはテナントにリソースの公平な共有を割り当てることができます。

• 制限範囲を採用 CPU とメモリの観点から、名前空間内のポッドまたはコンテナーへのリソース割り当てを制限します。

• リソース 要求と制限を定義します アプリケーションのデプロイに使用する YAML マニフェストまたは Helm グラフで、ポッドの CPU とメモリの使用量に対して明示的に定義します。 ポッド内のコンテナーに対するリソース要求を指定すると、Kubernetes スケジューラではこの情報を使用して、ポッドを配置するノードを決定します。 CPU やメモリなど、コンテナーのリソース制限を指定すると、kubelet はこれらの制限を適用して、実行中のコンテナーが設定した制限よりも多くのリソースを使用できないようにします。

• ポッドの中断予算を定義してアプリケーションの可用性を維持しクラスターで使用できるポッドの最小数を確認します。

• priority クラスを使用して、ポッドの重要性を示します。 スケジューラがポッドをスケジュールできない場合、保留中のポッドをスケジュールできるように、優先順位の低いポッドの割り込み (削除) を試みます。

• Kubernetes taints と容認 を使用して、リソースを集中的に消費するアプリケーションを特定のノードに配置し、ノイズの多い近隣の問題を回避します。 ノード リソースを必要とするワークロードでノード リソースを使用できるようにします。 ノードで他のワークロードをスケジュールすることは許可しないでください。

• ノード セレクター、ノード アフィニティ、またはポッド間アフィニティを使用して、ノード上のポッドのスケジュール設定を制御します。 ポッド間 アフィニティとアンチアフィニティ 設定を使用して、通信が頻繁なポッドを併置し、ポッドを異なるノードに配置し、同じノード上で同じ種類のポッドの複数のインスタンスを実行しないようにします。

このシナリオのデプロイ

このシナリオのソース コードは、GitHub で入手できます。 次の図は、 AKS マルチテナント AGIC GitHub リポジトリで見つけることができるデモ アプリケーションを示しています。

このアーキテクチャの Visio ファイルをダウンロードします。

前提条件

オンライン デプロイの場合、既存の Azure アカウントが必要です。 お持ちでない場合は、開始する前に 無料の Azure アカウント を作成してください。

Azure に配置する

1. Azure サブスクリプション情報が手元にあることを確認します。

2. ワークベンチ GitHub リポジトリを複製します。

   git clone https://github.com/Azure-Samples/aks-agic.git
   

3. README.md ファイルに記載されている手順に従います。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

• Paolo Salvatori | プリンシパル サービス エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

• AKS クラスターのベスト プラクティス
• AKS におけるスケジューラの基本的な機能に関するベスト プラクティス
• プライベート AKS クラスターを作成する
• Application Gateway の WAF ポリシーを作成する
• Helm デプロイと AKS アドオンの違い
• アプリケーション ゲートウェイの動作

関連リソース

• AKS クラスターのベースライン アーキテクチャ