編集

Share via

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

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 アプリケーションに対する、一般的な悪用と脆弱性からの一元的な保護が提供されます。 Azure Application Gateway で WAF ポリシーを使用すると、Azure Kubernetes Service (AKS) クラスターで実行され、Application Gateway イングレス コントローラー (AGIC) を介して公開されている Web アプリケーションを、SQL インジェクションやクロスサイト スクリプティングなどの悪意のある攻撃から保護できます。 Azure Application Gateway の WAF ポリシーは、OWASP コア ルール セットで事前に構成されており、サポートされている他の OWASP CRS バージョンに変更できます。

アーキテクチャ

この Application Gateway イングレス コントローラー ソリューションのアーキテクチャを示す図。

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

ワークフロー

ガイド用のこの ARM テンプレートでは、次の 4 つのサブネットを含む新しい仮想ネットワークがデプロイされます。

  • AksSubnet: AKS クラスターがホストされます
  • VmSubnet: ジャンプ ボックス仮想マシンとプライベート エンドポイントがホストされます
  • AppGatewaySubnet: Application Gateway WAF2 層がホストされます。
  • AzureBastionSubnet: Azure Bastion がホストされます

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

この AKS クラスターは、次の要素で構成されています。

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

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

Azure Bastion ホストにより、SSL 経由で Azure portal から直接、ジャンプボックス VM への安全かつシームレスな SSH 接続が提供されます。 コンテナー イメージと成果物 (Helm チャートなど) を作成、保存、管理するために Azure Container Registry (ACR) が使用されます。

このアーキテクチャには、イングレス コントローラーによって使用されるアプリケーション ゲートウェイが含まれています。 このアプリケーション ゲートウェイは専用サブネットにデプロイされ、すべてのテナント ワークロードによって共有されるパブリック IP アドレスを介してパブリック インターネットに公開されます。 悪意のある攻撃からテナント ワークロードを保護するため、このアプリケーション ゲートウェイにはルート レベルと HTTP リスナー レベルで Web アクセス ファイアウォール (WAF) ポリシーが関連付けられています。 このポリシーは防止モードで構成されており、OWASP 3.1 が使用されて、規則によって検出される侵入や攻撃がブロックされます。 攻撃者に "403 不正アクセス" の例外が送信され、接続が終了します。 防止モードの場合、このような攻撃は WAF ログに記録されます。

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

サンプル トポロジには、次のプライベート エンドポイントが含まれています。

  • BLOB ストレージ アカウントへのプライベート エンドポイント
  • Azure Container Registry (ACR) へのプライベート エンドポイント
  • Key Vault へのプライベート エンドポイント
  • プライベート AKS クラスターを選択する場合、Kubernetes クラスターの API サーバーへのプライベート エンドポイント

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

  • Azure BLOB ストレージ アカウントに対するプライベート エンドポイントの名前解決用プライベート DNS ゾーン
  • Azure Container Registry (ACR) に対するプライベート エンドポイントの名前解決用プライベート DNS ゾーン
  • Azure Key Vault に対するプライベート エンドポイントの名前解決用プライベート DNS ゾーン
  • クラスターをプライベートとしてデプロイする場合、Kubernetes Server API に対するプライベート エンドポイントの名前解決用プライベート DNS ゾーン

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

  • Azure Kubernetes Service クラスター
  • ジャンプ ボックス仮想マシン
  • Azure Application Gateway
  • Azure Key Vault
  • Azure ネットワーク セキュリティ グループ

Components

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

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

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

  • Azure Application Gateway は、複数のダウンストリーム Web アプリケーションと REST API への受信トラフィックをユーザーが管理できるようにする Web トラフィック ロード バランサーです。 従来のロード バランサーはトランスポート レイヤー (OSI レイヤー 4 - TCP と UDP) で動作し、トラフィックは送信元 IP アドレスとポートに基づいて送信先 IP アドレスとポートにルーティングされます。 それとは異なり、アプリケーション ゲートウェイは、アプリケーション レイヤー (OSI レイヤー 7) のロード バランサーです。 (OSI は開放型システム間相互接続、TCP は伝送制御プロトコル、UDP はユーザー データグラム プロトコルを表します。)

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

  • Azure Bastion は、お使いの仮想ネットワーク内でプロビジョニングする、完全に管理されたサービスとしてのプラットフォーム (PaaS) です。 Azure Bastion では、TLS 経由で Azure portal から直接、仮想ネットワーク内の VM への安全かつシームレスなリモート デスクトップ プロトコル (RDP) および Secure Shell (SSH) 接続が提供されます。

  • Azure Virtual Machines を使用すると、物理的なハードウェアを購入して維持する手間を省き、仮想化がもたらす柔軟性を提供する、オンデマンドのスケーラブルなコンピューティング リソースが提供されます。

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

  • 仮想ネットワーク インターフェイスでは、Azure 仮想マシンによるインターネット、Azure、オンプレミスのリソースとの通信が可能になります。 1 つの Azure VM に複数のネットワーク インターフェイス カードを追加でき、それにより、子 VM で独自の専用ネットワーク インターフェイス デバイスと IP アドレスを使用できます。

  • Azure Managed Disks は、Azure によって Azure VM 上で管理されるブロックレベルのストレージ ボリュームです。 使用できるディスクの種類は、Ultra ディスク、Premium ソリッド ステート ドライブ (SSD)、Standard SSD、Standard ハード ディスク ドライブ (HDD) です。

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

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

代替

このアーキテクチャでは、Application Gateway イングレス コントローラー (AGIC) のインストールに Azure Kubernetes Service (AKS) 用の AGIC アドオンを使用しました。 Helm チャートを使用して Application Gateway イングレス コントローラーをインストールすることもできます。 新規セットアップの場合、Azure CLI で 1 行を使用して、新しいアプリケーション ゲートウェイと新しい AKS クラスターを (AGIC をアドオンとして有効にして) デプロイできます。 このアドオンは、フル マネージド サービスでもあり、自動更新やサポートの強化などの追加のメリットが得られます。 AGIC をデプロイするどちらの方法 (Helm および AKS アドオン) も、Microsoft によって完全にサポートされています。 さらに、アドオンを使用すると、第一級のアドオンとして、AKS とより緊密に統合することができます。

Application Gateway イングレス コントローラー (AGIC) アドオンがお客様の AKS クラスターにポッドとしてデプロイされることに変わりはありません。 しかし、AGIC の Helm デプロイ バージョンとアドオン バージョンにはいくつかの違いがあります。 次のリストでは、2 つのバージョンの違いを示します。

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

    • usePrivateIp は、既定では false に設定される。これは、use-private-ip 注釈によって上書き可能
    • shared は、アドオンではサポートされない

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

  • AGIC アドオンはマネージド サービスであるため、自動的に最新バージョンの AGIC アドオンに更新されます。この点は、Helm を使用してデプロイされた AGIC (手動で AGIC を更新することが必要) と異なります。

  • AKS クラスターあたり 1 つの AGIC アドオンのみをデプロイできます。各 AGIC アドオンがターゲットにできるのは、現時点では、1 つの Application Gateway インスタンスのみです。 クラスターあたり複数の AGIC を必要とする、または 1 つのアプリケーション ゲートウェイをターゲットとした複数の AGIC を必要とするデプロイでは、Helm を通じてデプロイされた AGIC を引き続き使用できます。

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

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

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

    • helm-config.yaml ファイルから watchNamespace キーを完全に削除します。 AGIC ですべての名前空間が監視されることになります。
    • watchNamespace を空の文字列に設定する。 AGIC ですべての名前空間が監視されることになります。
    • コンマで区切って、複数の名前空間を追加する (watchNamespace: default,secondNamespace)。 AGIC でこれらの名前空間が排他的に監視されることになります。

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

複数の名前空間を監視する機能を付けてデプロイすると、AGIC によって次の処理が実行されます。

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

シナリオの詳細

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

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

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

マルチテナントの図

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

Application Gateway イングレス コントローラー (AGIC) は、Azure Kubernetes Service (AKS) のお客様が、コンテナ化されたアプリケーションを Azure アプリケーション ゲートウェイを使用してインターネットに公開できるようにする Kubernetes アプリケーションです。 AGIC では、そのホストとなっている Kubernetes クラスターを監視し、アプリケーション ゲートウェイを継続的に更新して、選択されたサービスがインターネットに公開されるようにします。 イングレス コントローラーは、お客様の AKS インスタンスの専用ポッドで実行されます。 AGIC では、Kubernetes リソースのサブセットに変更がないかを監視します。 AKS クラスターの状態は Application Gateway 特有の構成に変換され、Azure Resource Manager (ARM) に適用されます。 このアーキテクチャ サンプルでは、Azure アプリケーション ゲートウェイと Application Gateway イングレス コントローラー アドオンを使用して、パブリックまたはプライベートの Azure Kubernetes Service (AKS) クラスターをデプロイする実証済みプラクティスを示します。

Azure Application Gateway Kubernetes イングレス コントローラー (AGIC) の単一のインスタンスで複数の名前空間を監視して、それらからのイベントを取り込むことができます。 AKS 管理者が Application Gateway をイングレスとして使用することに決めた場合、Application Gateway の同じインスタンスがすべての名前空間で使用されます。 イングレス コントローラーを 1 回インストールすれば、アクセス可能な名前空間が監視され、それに関連付けられたアプリケーション ゲートウェイが構成されることになります。

考えられるユース ケース

マルチテナント環境の Azure Kubernetes Service (AKS) クラスターで実行されているインターネットに接続されたワークロードを公開および保護するために、Application Gateway イングレス コントローラー (AGIC) を使用できます。

考慮事項

次の考慮事項は、Azure Kubernetes Service (AKS) のマルチテナント機能と関係のない部分もありますが、このソリューションをデプロイする際の不可欠な要件と考えられます。 これには、セキュリティ、パフォーマンス、可用性と信頼性、ストレージ、スケジューラ、サービス メッシュ、監視に関する考慮事項が含まれます。

マルチテナント機能に関する考慮事項

  • AKS クラスターをマルチテナント機能用に設計します。 Kubernetes では、同じクラスター内のチームとワークロードを論理的に分離できる機能が提供されます。 各チームで必要なリソースをスコープとする、最小限の数の特権を提供することを目標にする必要があります。 Kubernetes の名前空間では、論理的な分離境界が作成されます。
  • 論理的な分離を使用して、チームとプロジェクトを分離します。 チームまたはアプリケーションを分離するためにデプロイする物理 AKS クラスターの数を最小限に抑えるようにします。 クラスターを論理的に分離すると、通常、物理的に分離されたクラスターよりもポッド密度が高くなります。
  • 厳密な物理的分離を実装する必要がある場合は常に、専用ノード プールまたは専用 AKS クラスターを使用します。 たとえば、ワーカー ノードのプールやクラスター全体を、1 つのチーム、またはマルチテナント環境における 1 つのテナント専用にすることができます。
    • テイントと容認の組み合わせを使用して、特定のノード プールへのポッドのデプロイを制御できます。 AKS 内のノードは、ノード プールの作成時にのみテイントできることに注意してください。 または、ラベルと nodePool セレクターを使用して、特定のノード プールへのワークロードのデプロイを制御できます。

セキュリティに関する考慮事項

セキュリティに関する次の考慮事項は、AKS のマルチテナント機能と関係のない部分もありますが、このソリューションをデプロイする際の不可欠な要件と考えられます。

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

  • Key Vault、Service Bus、Azure SQL Database など、AKS ワークロードで使用されるあらゆる PaaS サービスのためにプライベート エンドポイントを作成します。 これは、アプリケーションとこれらのサービスの間のトラフィックがパブリック インターネットに公開されないようにするためです。 詳細については、「Azure Private Link とは」を参照してください。
  • ワークロードを HTTPS 経由で公開するように Kubernetes イングレス リソースを構成し、テナントごとに別個のサブドメインとデジタル証明書を使用します。 Application Gateway イングレス コントローラー (AGIC) により、Secure Sockets Layer (SSL) 終端用の Azure Application Gateway リスナーが自動的に構成されます。
  • Web Application Firewall ポリシーを使用するように Azure Application Gateway を構成して、パブリックに公開されているワークロード (AKS で実行されている) を悪意のある攻撃から保護します。
  • 既存の仮想ネットワークやオンプレミスのネットワークと統合する場合は、AKS で Azure CNI ネットワークを使用します。 このネットワーク モデルでは、エンタープライズ環境でリソースとコントロールをさらに分離することもできます。
  • ネットワーク ポリシーを使用し、相互に通信できるコンポーネントを制御することにより、サービス内通信を分離し、セキュリティで保護します。 既定では、Kubernetes クラスター内のすべてのポッドでは制限なしにトラフィックを送受信できます。 セキュリティ向上のため、Azure ネットワーク ポリシーか Calico ネットワーク ポリシーを使用して、異なるマイクロサービス間のトラフィック フローを制御するルールを定義できます。 詳細については、ネットワーク ポリシーに関する記事を参照してください。
  • AKS ノードへのリモート接続は公開しないでください。 管理仮想ネットワーク内に踏み台ホスト (jump box) を作成します。 踏み台ホストを使用すると、AKS クラスターへのトラフィックをリモート管理タスクに安全にルーティングできます。
  • 運用環境でプライベート AKS クラスターを使用することを検討するか、少なくとも Azure Kubernetes Service で許可された IP アドレスの範囲を使用して API サーバーへのアクセスをセキュリティで保護します。
  • Azure DDoS Protection では、アプリケーションの設計に関するベスト プラクティスと組み合わせることにより、DDoS 攻撃からの保護を向上させるための強化された DDoS 軽減機能が提供されます。 すべての境界仮想ネットワークで Azure DDOS Protection を有効にする必要があります。

認証と権限承認

  • Microsoft Entra 統合を使って AKS クラスターをデプロイします。 詳細については、AKS マネージド Microsoft Entra 統合に関する記事を参照してください。 Microsoft Entra ID を使うと、ID 管理コンポーネントが一元化されます。 ユーザー アカウントまたはグループの状態が変わると、AKS クラスターにアクセスしたとき、その変更内容が自動的に更新されます。 Roles か ClusterRoles、および Bindings を使用して、ユーザーまたはグループのスコープを必要最小限の数のアクセス許可に指定します。
  • Kubernetes RBAC を使用して、クラスターのリソースに対するユーザーまたはグループのアクセス許可を定義します。 必要最小限の数のアクセス許可を割り当てるロールとバインディングを作成します。 Kubernetes RBAC を Microsoft Entra ID と統合することで、ユーザーの状態やグループ メンバーシップに変更があった場合は自動的に更新され、クラスター リソースへのアクセスが最新の状態になります。
  • Azure RBAC を使用して、ユーザーまたはグループが 1 つ以上のサブスクリプションの AKS リソースに対して持つ必要最小限のアクセス許可を定義します。 詳細については、Kubernetes RBAC に関する記事と、「Kubernetes 認可に Azure RBAC を使用する」をご覧ください。
  • Microsoft Entra ワークロード ID を使って、Azure リソース用のマネージド ID を個々のマイクロサービスに割り当て、それを使って管理対象リソース (Azure Key Vault、SQL Database、Service Bus、Cosmos DB など) にアクセスできるようにすることを検討します。 使用する接続文字列や資格情報を Kubernetes シークレットから保存および取得する必要がありません。
  • Azure Key Vault 用のシークレット ストア CSI ドライバーを使用して、Kubernetes シークレットからではなく、Key Vault から資格情報や接続文字列などのシークレットにアクセスすることを検討します。
  • Dapr シークレット ストアの構成ブロックを使用し、Kubernetes 上のマネージド ID で Azure Key Vault ストアを使用して、Key Vault からシークレット (資格情報や接続文字列など) を取得することを検討します。

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

  • Kubernetes API-Server へのアクセスをセキュリティで保護することは、クラスターをセキュリティで保護するためにできる最も重要な方法の 1 つです。 Kubernetes のロールベースのアクセス制御 (Kubernetes RBAC) を Microsoft Entra ID と統合して、API サーバーへのアクセスを制御します。 このようなコントロールを使用すると、Azure サブスクリプションへのアクセスをセキュリティで保護する場合と同じ方法で AKS をセキュリティで保護できます。
  • コンテナーで実行できるアクションへのアクセスを制限します。 ポッドの作成と更新をきめ細かく認可できるように、Pod Security Admission を使用します。 最小限のアクセス許可を付与し、ルート/特権エスカレーションの使用を避けます。 その他のベスト プラクティスについては、リソースへのポッドのアクセスをセキュリティで保護する方法に関する記事を参照してください。
  • できる限り、コンテナーをルート ユーザーとして実行しないようにします。
  • AppArmor Linux カーネル セキュリティ モジュールを使用して、コンテナーが実行できるアクションを制限します。
  • 新しい機能とバグ修正を利用するために、AKS クラスターを最新の Kubernetes バージョンに定期的にアップグレードします。
  • AKS により、各 Linux ノードへのセキュリティ修正プログラムのダウンロードとインストールが自動的に行われますが、必要な場合にノードの再起動が自動的に実行されることはありません。 kured を使用して、保留中の再起動を監視し、ノードの cordon と drain を実行して、最後に更新プログラムを適用します。 Windows Server ノードの場合は、ポッドを安全に cordon および drain し、更新されたすべてのノードをデプロイするために、AKS のアップグレード操作を定期的に実行します。
  • すべてのポッド内通信にセキュリティで保護された HTTPS および gRPC トランスポート プロトコルを使用し、OAuth や JWT など、要求のたびにプレーンな資格情報を送信する必要のない、より高度な認証メカニズムを使用することを検討します。 安全なサービス内通信は、Istio、Linkerd または Consul などのサービス メッシュを使用するか、Dapr を使用して実現できます。

Azure Container Registry

  • コンテナー イメージをスキャンして脆弱性を見つけ、検証に合格したイメージのみをデプロイします。 基本イメージおよびアプリケーション ランタイムを定期的に更新し、AKS クラスターにワークロードを再デプロイします。 CI/CD デプロイ ワークフローには、コンテナー イメージをスキャンするプロセスを含める必要があります。 Microsoft Defender for Cloud DevOps security を使用すると、自動パイプラインの構築/デプロイ時の脆弱性のコードをスキャンできます。 または、Prisma Cloud や Aqua などのツールを使用して、検証済みのイメージのみをスキャンしてデプロイできるようにできます。
  • アプリケーション イメージに基本イメージを使用する際には、基本イメージの更新時にオートメーションを使用して新しいイメージをビルドします。 通常、これらの基本イメージにはセキュリティ修正プログラムが含まれているので、すべてのダウンストリーム アプリケーション コンテナー イメージを更新します。 基本イメージの更新の詳細については、「Automate image builds on base image update with Azure Container Registry Tasks」 (Azure Container Registry タスクを使用して基本イメージの更新時のコンテナー イメージ ビルドを自動化する) を参照してください。

パフォーマンスに関する考慮事項

パフォーマンスに関する次の考慮事項は、Azure Kubernetes Service (AKS) のマルチテナント機能と関係のない部分もありますが、このソリューションをデプロイする際の不可欠な要件と考えられます。

  • 低遅延ワークロードの場合は、近接配置グループに専用ノード プールをデプロイすることを検討します。 Azure にアプリケーションをデプロイするときに、複数のリージョンまたは可用性ゾーンに仮想マシン (VM) インスタンスを分散すると、ネットワーク待機時間が発生し、アプリケーションの全体的なパフォーマンスに影響を及ぼす可能性があります。 近接配置グループは、Azure コンピューティング リソースが互いに物理的に近くに配置されるようにするために使用される論理的なグループ化です。 ゲーム、エンジニアリング シミュレーション、高頻度取引 (HFT) などの一部のユース ケースでは、低遅延と、短時間で完了するタスクが必要です。 これらのようなハイ パフォーマンス コンピューティング (HPC) シナリオでは、クラスターのノード プールに近接配置グループ (PPG) を使用することを検討します。
  • より小さなコンテナー イメージを常に使用します。これはより早くビルドを作成するのに役立ちます。 小さいイメージを使用すると、攻撃面が減少するので、攻撃ベクトルに対する脆弱性が低くなります。
  • トラフィックが増加した場合に AKS クラスターのワーカー ノード数を動的にスケールアウトするため、Kubernetes の自動スケールを使用します。 Horizontal Pod Autoscaler とクラスター オートスケーラーを使用すると、ノードとポッドのボリュームがトラフィックの状態に合わせてリアルタイムで動的に調整され、容量の問題によって生じるダウンタイムを回避することができます。 詳細については、「Azure Kubernetes Service (AKS) でクラスターを使用する」を参照してください。

可用性と信頼性に関する考慮事項

可用性と信頼性に関する次の考慮事項は、Azure Kubernetes Service (AKS) のマルチテナント機能と関係のない部分もありますが、このソリューションをデプロイする際の不可欠な要件と考えられます。 AKS クラスターとワークロードの可用性を最適化するため、次の方法をご検討ください。

Containers

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

    • livenessProbe では、コンテナーが実行中かどうかを示します。 Liveness Probe が失敗すると、そのコンテナーは kubelet によって中止させられ、コンテナーはその再起動ポリシーの対象になります。
    • readinessProbe では、コンテナーが要求に応答できる状態かどうかを示します。 Readiness Probe が失敗すると、エンドポイント コントローラーにより、ポッドと一致するすべてのサービスのエンドポイントから、ポッドの IP アドレスが削除されます。 初期遅延に先立つ既定の準備状態は Failure です。
    • startup probe では、コンテナー内のアプリケーションが起動されているかどうかを示します。 Startup Probe が指定されている場合は、これが成功するまで他のすべてのプローブは無効になります。 Startup Probe が失敗すると、そのコンテナーは kubelet によって中止させられ、コンテナーはその再起動ポリシーの対象になります。

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

  • リソース制限を使用して、1 つのコンテナーに許可される合計リソースを制限します。そのようにすると、特定の 1 つのコンテナーが原因で他に不足が生じることはなくなります。

コンテナー レジストリ

  • Azure Container Registry にコンテナー イメージを格納し、Azure Container Registry geo レプリケーションを使用して、そのレジストリを各 AKS リージョンに geo レプリケートすることをお勧めします。 geo レプリケーションは、Premium SKU ACR レジストリの機能です。
  • コンテナー イメージをスキャンして脆弱性を見つけ、検証に合格したイメージのみをデプロイします。 基本イメージおよびアプリケーション ランタイムを定期的に更新し、AKS クラスターにワークロードを再デプロイします。
  • ポッドおよびデプロイで使用できるイメージ レジストリを制限します。 使用可能なイメージを検証および制御する場所である、信頼できるレジストリのみを許可します。
  • アプリケーション イメージに基本イメージを使用する際には、基本イメージの更新時にオートメーションを使用して新しいイメージをビルドします。 通常、これらの基本イメージにはセキュリティ修正プログラムが含まれているので、すべてのダウンストリーム アプリケーション コンテナー イメージを更新します。 コンテナー レジストリにイメージを発行する前に、CI/CD パイプラインの一部としてコンテナー イメージの脆弱性をスキャンすることをお勧めします。 Azure Defender for Containers は、CI/CD ワークフローに統合できます。
  • Azure Container Registry の ACR タスクを使用して、Docker コンテナー用の OS とフレームワークの修正プログラムの適用を自動化します。 ACR タスクでは、いずれかの基本イメージ内で OS またはアプリケーション フレームワークに修正プログラムを適用したときなど、コンテナーの基本イメージが更新されたときのビルド実行の自動化をサポートしています。

リージョン内の回復性

  • 1 つのリージョン内のすべての可用性ゾーンをまたいで AKS クラスターのノード プールをデプロイすることを検討し、ノード プールの前で Azure Standard Load Balancer または Azure Application Gateway を使用します。 このトポロジを使用すると、1 つのデータセンターが停止した場合の回復性が向上します。 この方法では、クラスター ノードは 1 つのリージョンに含まれている 3 つの別個の可用性ゾーンにある、複数のデータセンターにまたがって分散されます。
  • リージョン内の回復性と高可用性を実現するため、Azure Container Registry でゾーン冗長を有効にします。
  • ポッド トポロジの分散制約を使用して、リージョン、可用性ゾーン、ノードなどの障害ドメイン間でポッドを AKS クラスター全体に分散する方法を制御します。
  • ミッション クリティカルなワークロードがホストされる AKS クラスターには、アップタイム SLA の使用を検討します。 アップタイム SLA は、クラスターに対して利用料金に基づく高い SLA を実現するためのオプションの機能です。 アップタイム SLA では、Availability Zones を使用するクラスターに対して、Kubernetes API サーバー エンドポイントの 99.95% の可用性が保証されます。 また、Availability Zones を使用しないクラスターに対しては、99.9% の可用性が保証されます。 AKS では、SLA 要件が満たされることを保証するため、更新および障害ドメイン全体でマスター ノード レプリカを使用します。

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

  • 1 つの地域内の少なくとも 2 組の Azure リージョン ペアにソリューションをデプロイすることを検討します。 また、事業継続とディザスター リカバリーを保証するため、アクティブ/アクティブまたはアクティブ/パッシブなルーティング方法を使用して、Azure Traffic Manager や Azure Front Door などのグローバル ロード バランサーを使用する必要があります。
  • プライマリ リージョンの停止によってコア サービスが影響を受けた場合の予期しない問題を回避するために、すべてのリージョン フェールオーバー プロセスを QA 環境内でスクリプト化、文書化し、定期的にテストする必要があります。
  • これらのテストは、DR アプローチが RPO または RTO ターゲットを満たしているかを、フェールオーバーに必要となる最終的な手動のプロセスおよび介入と組み合わせて検証することをも意図しています。
  • 想定どおりにフェールバック手順が機能するかどうかを確認するため、必ずフェールバック プロシージャをテストしてください。
  • コンテナー イメージを Azure Container Registry に格納し、そのレジストリを各 AKS リージョンに geo レプリケートします。 詳細については、「Azure Container Registry の geo レプリケーション」を参照してください。
  • 可能な場合、サービスの状態をコンテナー内に格納しないでください。 代わりに、マルチリージョン レプリケーションをサポートする Azure のサービスとしてのプラットフォーム (PaaS) を使用します。
  • Azure Storage を使用する場合は、ストレージをプライマリ リージョンからバックアップ リージョンに移行する方法を準備してテストします。
  • GitOps を使用してクラスター構成をデプロイすることを検討してください。 GitOps を使用すると、プライマリ クラスターと DR クラスターの間で統一性が得られ、クラスターが失われた場合に新しいクラスターを簡単に再構築できます。
  • Azure Kubernetes Service backup や Velero などのツールを使用してクラスター構成をバックアップ/復元することを検討します。

ストレージに関する考慮事項

ストレージに関する次の考慮事項は、Azure Kubernetes Service (AKS) のマルチテナント機能と関係のない部分もありますが、このソリューションをデプロイする際の不可欠な要件と考えられます。

  • エフェメラル OS ディスクを使用して AKS クラスターをデプロイすることを検討します。これにより、読み書きの待機時間が短縮し、ノードのスケーリングとクラスターのアップグレードが高速化します。
  • 適切なストレージを選択するためにアプリケーションのニーズを理解します。 運用環境のワークロードには、高パフォーマンスの SSD を基盤とするストレージを使用します。 複数のポッドが同じファイルに同時にアクセスする必要がある場合は、Azure Files などのネットワーク ベースのストレージ システムを計画します。 詳細については、「Azure Kubernetes Service (AKS) でのアプリケーションのストレージ オプション」を参照してください。
  • 各ノード サイズでは、最大数のディスクがサポートされます。 また、さまざまなノード サイズで、さまざまな量のローカル ストレージやネットワーク帯域幅が提供されます。 適切なサイズのノードをデプロイするために、アプリケーション要求について計画します。
  • 管理オーバーヘッドを減らし、スケーリングできるようにするために、永続ボリュームを静的に作成して割り当てないでください。 動的プロビジョニングを使用します。 ポッドが削除された後の不要なストレージ コストを最小限に抑えるため、ストレージ クラスで適切な解放ポリシーを定義します。

スケジューラに関する考慮事項

スケジューラに関する次の考慮事項は、Azure Kubernetes Service (AKS) のマルチテナント機能と関係のない部分もありますが、このソリューションをデプロイする際の不可欠な要件と考えられます。

  • クラスター オペレーターやアプリケーション開発者が Azure Kubernetes Service (AKS) 上でアプリケーションを正常にビルドして実行できるようにするため、必ずベスト プラクティスを確認して実装してください。
  • 名前空間レベルで、すべての名前空間のリソース クォータを計画して適用します。 ポッドでリソースの要求と制限が定義されていない場合は、デプロイを拒否します。 リソースの使用状況を監視し、必要に応じてクォータを調整します。 決まった数のノードを持つ AKS クラスターを複数のチームまたはテナントで共有する場合、リソース クォータを使用することにより、各チームまたはテナントにリソースの適正な分け前を割り当てることができます。
  • CPU とメモリに関して、名前空間でのリソース割り当て (ポッドまたはコンテナーに対する) を制限するには、Limit Range を使用します。
  • アプリケーションをデプロイするために使用する YAML マニフェストまたは Helm チャートで、ポッドに対する CPU とメモリの使用量に関するリソース要求と制限を明示的に定義します。 ポッド内のコンテナーに対するリソース要求を指定すると、Kubernetes スケジューラではこの情報を使用して、ポッドを配置するノードを決定します。 コンテナーに対するリソース制限 (CPU やメモリなど) を指定すると、kubelet はその制限を適用して、設定されている制限よりも多くのリソースを実行中のコンテナーが使用できないようにします。
  • アプリケーションの可用性を維持するには、ポッド中断バジェットを定義して、最低限の数のポッドをクラスターで使用できるようにします。
  • Priority クラスを使用すると、ポッドの重要度を示すことができます。 ポッドをスケジュールできない場合、スケジューラでは、保留中のポッドをスケジュールできるようにするために、低優先度のポッドをプリエンプト (無効化) しようとします。
  • リソースを集中的に使用するアプリケーションを特定のノードに配置したり、"迷惑な隣人" 問題を回避したりするため、Kubernetes の taints と tolerations を使用します。 ノードのリソースをそれが必要なワークロードで使用できるように保ち、他のワークロードがそのノードでスケジュールされないようにします。
  • ノード セレクター、ノード アフィニティ、またはポッド間アフィニティを使用して、ノード上のポッドのスケジュールを制御します。 頻繁に通信が行われているポッドを併置したり、異なるノードにポッドを配置したり、同じノード上で同じ種類のポッドのインスタンスを複数実行することを避けたりするには、ポッド間アフィニティと非アフィニティ設定を使用します。

サービス メッシュに関する考慮事項

サービス メッシュに関する次の考慮事項は、AKS のマルチテナント機能と関係のない部分もありますが、このソリューションをデプロイする際の不可欠な要件と考えられます。

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

  • 回復性があるマイクロサービスのステートレスおよびステートフル アプリケーションをビルドするには、Dapr を使用することを検討します。 任意のプログラミング言語と開発者フレームワークを使用できます。

DevOps の考慮事項

  • CI/CD パイプラインで Helm チャートを使用したり、GitHub Actions または Azure DevOps などの DevOps システムを使用したりして、ワークロードを Azure Kubernetes Service (AKS) にデプロイします。 詳細については、「Azure Kubernetes Service へのビルドとデプロイ」を参照してください。

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

  • 別の方法として、サービス メッシュの実装によって提供されるトラフィック管理機能を使用することもできます。 詳細については、以下を参照してください:

  • Azure Container Registry または別のコンテナー レジストリ (Docker Hub など) を使用して、クラスターにデプロイされているプライベート Docker イメージを格納します。 AKS では、その Microsoft Entra ID を使って Azure Container Registry に対して認証できます。

監視に関する考慮事項

監視に関する次の考慮事項は、Azure Kubernetes Service (AKS) のマルチテナント機能と関係のない部分もありますが、このソリューションをデプロイする際の不可欠な要件と考えられます。

  • AKS クラスターとワークロードの正常性状態を監視するには、Azure 統合監視オプションを検討します。
  • 診断ログとメトリクスを Azure Monitor Log Analytics に収集するように、すべての PaaS サービス (Azure Container Registry や Key Vault など) を構成します。

コストの最適化

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

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

これらの側面を評価したら、Azure 料金計算ツールに移動してコストを見積もります。 価格最適化オプションの詳細については、Microsoft Azure Well-Architected Framework の「コスト最適化の原則」を参照してください。

このシナリオのデプロイ

このシナリオのソース コードは、GitHub で入手できます。 次の図に示すデモ アプリケーションも、この GitHub リポジトリに用意されています。

AKS を使用するこの AGIC アーキテクチャのデプロイを示す図。

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

前提条件

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

Azure へのデプロイ

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

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

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

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

共同作成者

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

プリンシパルの作成者:

次のステップ

Azure Kubernetes Service

Azure Application Gateway

Azure Application Gateway イングレス コントローラー

Azure Application Gateway WAF

アーキテクチャに関するガイダンス

参照アーキテクチャ