Azure Kubernetes Service (AKS) クラスターの保護に Azure Firewall を使用する

Azure Firewall

Azure Kubernetes Service (AKS)

Azure Private Link

Azure Virtual Network

Azure DevOps

このガイドでは、Terraform と Azure DevOps を使用して、ハブアンドスポークネットワークトポロジでプライベート AKS クラスターを作成する方法について説明します。 Azure Firewall は、Azure Kubernetes Service (AKS) クラスターとの間のトラフィックを検査するために使用されます。このクラスターは、ハブ仮想ネットワークとピアリングされた 1 つ以上のスポーク仮想ネットワークによってホストされています。

アーキテクチャ

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

ワークフロー

Terraform モジュールは、次の 4 つのサブネットをホストする新しい仮想ネットワークをデプロイするために使用されます。

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

AKS クラスターでは、ユーザー定義のマネージド ID を使用して、Azure 内にロードバランサーやマネージドディスクなどの追加リソースを作成します。 Terraform モジュールを使用すると、必要に応じて、次の機能を備えた AKS クラスターをデプロイできます。

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

重要なシステムポッドとサービスのみがホストされるシステムノードプール。
ユーザーワークロードと成果物がホストされるユーザーノードプール。

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

Azure Bastion ホストは、SSL 経由でのジャンプボックス VM へのセキュリティで保護された SSH 接続を提供します。コンテナーイメージと成果物 (Helm チャートなど) を作成、保存、管理するために Azure Container Registry (ACR) が使用されます。

このアーキテクチャには、DNAT ルール、ネットワークルール、およびアプリケーションルールを使用して受信と送信トラフィックを制御するために使用される Azure Firewall が含まれています。また、脅威インテリジェンスベースのフィルター処理を使用して、ワークロードを保護するのにも役立ちます。 Azure Firewall と Bastion は、プライベート AKS クラスターをホストする仮想ネットワークとピアリングされたハブ仮想ネットワークにデプロイされます。ルートテーブルとユーザー定義のルートは、プライベート AKS クラスターから Azure Firewall への送信トラフィックをルーティングするために使用されます。

Note

高度な脅威保護を提供するため、Azure Firewall の Premium SKU を使用することを強くお勧めします。

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

トポロジには、次のサービスのプライベートエンドポイントとプライベート DNS ゾーンが含まれます。

Azure Blob Storage アカウント
Container Registry
Key Vault
Kubernetes クラスターの API サーバー

AKS クラスターをホストするハブアンドスポークの仮想ネットワークと、前に説明したプライベート DNS ゾーンとの間には、仮想ネットワークリンクがあります。

Log Analytics ワークスペースを使用して、Azure サービスから診断ログとメトリックを収集します。

コンポーネント

Azure Firewall は、Azure で実行されているクラウドワークロードに脅威保護を提供する、クラウドネイティブでインテリジェントなネットワークファイアウォールのセキュリティサービスです。組み込みの高可用性とクラウドの無制限のスケーラビリティを備えた、完全にステートフルなサービスとしてのファイアウォールです。これは、東西と北南の両方のトラフィック検査を提供します。
Container Registry は、オープンソースの Docker Registry 2.0 が基になっている、マネージド型のプライベート Docker レジストリサービスです。既存のコンテナー開発およびデプロイパイプラインで Azure コンテナーレジストリを使用するか、Container Registry タスクを使用して Azure にコンテナーイメージをビルドすることができます。
Azure Kubernetes Service を使用すると、運用上のオーバーヘッドが Azure にオフロードされるため、Azure でのマネージド Kubernetes クラスターのデプロイが簡素化されます。 Azure で Kubernetes サービスをホストして、正常性の監視や維持などの重要なタスクを処理します。 Kubernetes マスターは Azure によって管理されるので、お客様はエージェントノードの管理と保守のみを行います。
Key Vault では、API キー、パスワード、証明書、暗号化キーなどのシークレットが、強化されたセキュリティにより格納され、アクセスが制御されます。また、Key Vault を使用することにより、Azure および内部の接続されているリソースで使用するためのパブリックおよびプライベートのトランスポート層セキュリティまたは Secure Sockets Layer (TLS または SSL) 証明書を容易にプロビジョニング、管理、デプロイできます。
Azure Bastion は、お使いの仮想ネットワーク内でプロビジョニングする、完全に管理されたサービスとしてのプラットフォーム (PaaS) です。 Azure Bastion では、TLS 経由で Azure portal から直接、仮想ネットワーク内の VM への、セキュリティが向上したリモートデスクトッププロトコル (RDP) および Secure Shell (SSH) 接続が提供されます。
Azure Virtual Machines では、仮想化の柔軟性を提供する、オンデマンドでスケーラブルなコンピューティングリソースが提供されます。
Azure Virtual Network は、Azure のプライベートネットワークの基本的な構成ブロックです。 Virtual Network により、Azure リソース (VM など) は、強化されたセキュリティにより、他の Azure リソース、インターネット、オンプレミスネットワークと通信できます。 Azure 仮想ネットワークは、オンプレミスの従来のネットワークと似ていますが、スケーラビリティ、可用性、分離などの Azure インフラストラクチャのメリットが得られます。
Virtual Network インターフェイスにより、Azure VM はインターネット、Azure、およびオンプレミスのリソースと通信できます。 1 つの Azure VM に複数のネットワークインターフェイスカードを追加でき、それにより、子 VM で独自の専用ネットワークインターフェイスデバイスと IP アドレスを使用できます。
Azure Managed Disks では、Azure VM 上で Azure によって管理されるブロックレベルのストレージボリュームが提供されます。 Ultra ディスク、Premium ソリッドステートドライブ (SSD)、Standard SSD、Standard ハードディスクドライブ (HDD) を使用できます。
Blob Storage は、クラウド用のオブジェクトストレージソリューションです。 Blob Storage は、テキストデータやバイナリデータなどの大量の非構造化データを格納するために最適化されています。
Private Link を使用して、仮想ネットワーク内のプライベートエンドポイント経由で Azure PaaS サービス (Blob Storage、Key Vault など) にアクセスできます。また、このサービスを使用して、所有している、または Microsoft パートナーによって提供されている Azure ホステッドサービスにアクセスすることもできます。

代替

Azure Firewall ではなく、Azure Marketplace のサードパーティのファイアウォールを使用できます。この場合、AKS クラスターからの受信トラフィックと送信トラフィックを検査して許可または拒否するようにファイアウォールを適切に構成する必要があります。

シナリオの詳細

運用環境では、Kubernetes クラスターとの通信は、一連のセキュリティ規則に基づいて受信および送信ネットワークトラフィックを監視および制御するファイアウォールによって保護されている必要があります。通常、ファイアウォールは、信頼されたネットワークと信頼されていないネットワーク (インターネットなど) との間にバリアを確立します。

Terraform および Azure DevOps を使用すれば、ハブアンドスポークネットワークトポロジにプライベート AKS クラスターをデプロイできます。 Azure Firewall は、Azure Kubernetes Service (AKS) クラスターとの間のトラフィックを検査するために使用されます。このクラスターは、ハブ仮想ネットワークとピアリングされた 1 つ以上のスポーク仮想ネットワークによってホストされています。

Azure Firewall では、さまざまなお客様のユースケースと好みに対応するために、3 つの異なる SKU がサポートされています。

Azure Firewall Premium は、支払処理など、機密性の高いアプリケーションをセキュリティで保護する場合に推奨されます。マルウェアや TLS 検査などの高度な脅威保護機能がサポートされています。
Azure Firewall Standard は、レイヤー 3 からレイヤー 7 のファイアウォールを探していて、最大 30 Gbps のピークトラフィック期間を処理するために自動スケーリングが必要なお客様に推奨されます。脅威インテリジェンス、DNS プロキシ、カスタム DNS、Web カテゴリなどのエンタープライズ機能がサポートされています。
Azure Firewall Basic は、スループットのニーズが 250 Mbps 未満のお客様に推奨されます。

次の表は、3 つの Azure Firewall SKU の機能を示しています。詳細については、「Azure Firewall の価格」を参照してください。

Screenshot that shows features of the three Azure Firewall SKUs

既定で、AKS クラスターは、送信インターネットアクセスが無制限です。このレベルのネットワークアクセスでは、AKS クラスターで実行しているノードやサービスから必要に応じて外部リソースにアクセスできます。エグレストラフィックを制限する場合は、正常なクラスターメンテナンスタスクを維持するために、アクセスできるポートとアドレスの数を制限する必要があります。 AKS などの Kubernetes クラスターからの送信トラフィックにセキュリティを提供する最も簡単な方法は、ドメイン名に基づいて送信トラフィックを制御できるソフトウェアファイアウォールを使用することです。 Azure Firewall では、宛先の完全修飾ドメイン名 (FQDN) に基づいて送信 HTTP および HTTPS トラフィックを制限できます。また、ファイアウォール規則とセキュリティ規則を構成し、これらの必要なポートとアドレスを許可することができます。詳細については、「AKS でクラスターノードに対するエグレストラフィックを制御する」をご覧ください。

同様に、共有境界ネットワークにデプロイされた Azure Firewall で脅威インテリジェンスベースのフィルター処理を有効にすることで、イングレストラフィックを制御し、セキュリティを強化することができます。このフィルター処理では、既知の悪意のある IP アドレスとドメインとの間のアラートを提供し、トラフィックを拒否することができます。

考えられるユースケース

このシナリオでは、Kubernetes クラスターとの間の受信トラフィックと送信トラフィックのセキュリティを強化する必要性について説明します。

非対称ルーティングを回避する

このソリューションでは、ハブ仮想ネットワークに Azure Firewall がデプロイされ、スポーク仮想ネットワークにプライベート AKS クラスターがデプロイされます。 Azure Firewall は、ネットワークおよびアプリケーションのルールコレクションを使用してエグレストラフィックを制御します。このような状況では、AKS で実行されている任意のサービスによって公開されているすべてのパブリックエンドポイントへのイングレストラフィックを構成して、Azure Firewall で使用されるパブリック IP アドレスのいずれかを介してシステムに入る必要があります。

パケットはファイアウォールのパブリック IP アドレスに到着しますが、プライベート IP アドレス経由でファイアウォールに戻ります (既定のルートが使用されます)。これは問題です。これを回避するには、次の図に示すように、ファイアウォールのパブリック IP アドレスに対して、別のユーザー定義ルートを作成します。ファイアウォールのパブリック IP アドレスに到着するパケットは、インターネット経由でルーティングされます。この構成により、ファイアウォールのプライベート IP アドレスへの既定ルートの使用が回避されます。

AKS ワークロードのトラフィックをハブ仮想ネットワーク内の Azure Firewall にルーティングするには、次のことを行う必要があります。

クラスターのワーカーノードをホストする各サブネットにルートテーブルを作成して関連付けます。
0.0.0.0/0 CIDR のトラフィックを Azure Firewall のプライベート IP アドレスに転送するユーザー定義ルートを作成します。 [ネクストホップの種類] として [仮想アプライアンス] を指定します。

詳細については、「チュートリアル:Deploy and configure Azure Firewall using the Azure portal (チュートリアル: Azure portal を使用して Azure Firewall のデプロイと構成を行う)」を参照してください。

詳細については、以下を参照してください:

Azure DevOps を使用する場合のワークロードのプライベート AKS クラスターへのデプロイ

Azure DevOps を使用する場合、Azure DevOps Microsoft ホステッドエージェントを使用して、プライベート AKS クラスターにワークロードをデプロイすることはできないことにご注意ください。それらは API サーバーにアクセスできません。プライベート AKS クラスターにワークロードをデプロイするには、プライベート AKS クラスターと同じ仮想ネットワークまたはピアリングされた仮想ネットワーク内で Azure DevOps セルフホステッドエージェントをプロビジョニングして使用する必要があります。後者の場合は、ノードリソースグループ内の AKS クラスターのプライベート DNS ゾーンと、Azure DevOps セルフホステッドエージェントをホストする仮想ネットワークとの間に仮想ネットワークリンクを作成してください。

仮想マシンに単一の Windows または Linux Azure DevOps エージェントをデプロイすることも、仮想マシンスケールセットを使用することもできます。詳細については、「Azure 仮想マシンスケールセットエージェント」を参照してください。また、Docker を使用して Windows Server Core コンテナー (Windows ホストの場合) または Ubuntu コンテナー (Linux ホストの場合) 内で実行するセルフホステッドエージェントを Azure Pipelines に設定することもできます。プライベート AKS クラスターに 1 つ以上のレプリカを含むポッドとしてデプロイします。詳細については、次のトピックを参照してください。

プライベート AKS クラスターのノードプールをホストするサブネットが、ルートテーブルとユーザー定義ルートを介して Azure Firewall にエグレストラフィックをルーティングするように構成されている場合は、必ずアプリケーションおよびネットワークの適切なルールを作成してください。これらのルールでは、エージェントが外部サイトにアクセスして、Docker、Kubectl、Azure CLI、Helm などのツールをエージェント仮想マシンにダウンロードしてインストールできる必要があります。詳細については、「Docker でセルフホステッドエージェントを実行する」および「AKS 上の Azure DevOps パイプラインエージェントをビルドおよびデプロイする」を参照してください。

パブリック Standard Load Balancer の前で Azure Firewall を使用する

Terraform モジュールのリソース定義では、ライフサイクルメタ引数を使用して、Azure リソースが Terraform コントロールの外部で変更された場合のアクションをカスタマイズします。 ignore_changes 引数は、タグなどの指定されたリソースプロパティの更新を無視するように Terraform に指示するために使用されます。 Azure Firewall ポリシーリソース定義にはライフサイクルブロックが含まれているので、ルールコレクションまたは単一のルールが作成、更新、または削除された場合に Terraform がリソースを更新できません。同様に、Azure ルートテーブルにはライフサイクルブロックが含まれているので、ユーザー定義ルートの作成、削除、または更新時に Terraform がリソースを更新することはできません。これにより、Azure Firewall ポリシーの DNAT、アプリケーション、およびネットワークのルールと、Terraform コントロールの外部にある Azure ルートテーブルのユーザー定義ルートを管理できます。

この記事に関連付けられているサンプルには、セルフホステッドエージェントで実行される Azure DevOps パイプラインを使用して、プライベート AKS クラスターにワークロードをデプロイする方法を示す、Azure DevOps CD パイプラインが含まれています。このサンプルでは、パブリック Helm チャートを使用して Bitnami Redmine プロジェクト管理 Web アプリケーションをデプロイします。次の図は、サンプルのネットワークトポロジを示しています。

メッセージフローを次に示します。

AKS でホストされる Web アプリケーションに対する要求は、パブリック IP 構成を介して Azure Firewall によって公開されるパブリック IP に送信されます。パブリック IP とパブリック IP 構成は両方ともこのワークロード専用です。
Azure Firewall DNAT ルールでは、Azure Firewall パブリック IP アドレスとポートを、ノードリソースグループ内の AKS クラスターの Kubernetes パブリック Standard Load Balancer 内のワークロードによって使用されるパブリック IP とポートに変換します。
ロードバランサーは、AKS クラスターのいずれかのエージェントノードで実行されている Kubernetes サービスポッドの 1 つに要求を送信します。
応答メッセージは、ユーザー定義ルートを介して元の呼び出し元に送り返されます。 Azure Firewall パブリック IP はアドレスプレフィックスで、ネクストホップはインターネットを指定します。
ワークロードによって開始された送信呼び出しは、既定のユーザー定義ルートによって Azure Firewall のプライベート IP アドレスにルーティングされます。 0.0.0.0/0 はアドレスプレフィックスで、ネクストホップは仮想アプライアンスを指定します。

詳細については、「AKS クラスターのパブリック Standard Load Balancer の前で Azure Firewall を使用する」を参照してください。

内部 Standard Load Balancer の前で Azure Firewall を使用する

この記事に関連付けられているサンプルでは、ASP.NET Core アプリケーションは AKS クラスターによってサービスとしてホストされ、NGINX イングレスコントローラーによって前面に表示されます。 NGINX イングレスコントローラーは、AKS クラスターをホストするスポーク仮想ネットワーク内にプライベート IP アドレスを持つ内部ロードバランサーを介して公開されます。詳細については、「AKS で内部の仮想ネットワークにイングレスコントローラーを作成する」を参照してください。 NGINX イングレスコントローラー (より一般的には LoadBalancer または ClusterIP サービス) をデプロイするときに、メタデータセクションの service.beta.kubernetes.io/azure-load-balancer-internal: "true" 注釈を使用して、ノードリソースグループの下に kubernetes-internal という内部標準ロードバランサーが作成されます。詳細については、「AKS で内部ロードバランサーを使用する」を参照してください。次の図に示すように、テスト Web アプリケーションは、専用の Azure パブリック IP 経由で Azure Firewall によって公開されます。

メッセージフローを次に示します。

AKS でホストされるテスト Web アプリケーションに対する要求は、パブリック IP 構成を介して Azure Firewall によって公開されるパブリック IP に送信されます。パブリック IP とパブリック IP 構成は両方ともこのワークロード専用です。
Azure Firewall DNAT ルールでは、Azure Firewall パブリック IP とポートを、ノードリソースグループ内の AKS クラスターの内部 Standard Load Balancer 内の NGINX イングレスコントローラーによって使用されるパブリック IP とポートに変換します。
要求は内部ロードバランサーによって、AKS クラスターのいずれかのエージェントノードで実行されている Kubernetes サービスポッドの 1 つに送信されます。
応答メッセージは、ユーザー定義ルートを介して元の呼び出し元に送り返されます。 0.0.0.0/0 はアドレスプレフィックスで、ネクストホップは仮想アプライアンスを指定します。
ワークロードによって開始された送信呼び出しは、ユーザー定義ルートのプライベート IP アドレスにルーティングされます。

詳細については、「内部 Standard Load Balancer の前で Azure Firewall を使用する」を参照してください。

考慮事項

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

次の考慮事項の一部は、AKS クラスターの保護を向上させるために Azure Firewall を使用する場合に固有ではない一般的な推奨事項です。これらは、このソリューションの不可欠な要件だと考えています。これは、セキュリティ、パフォーマンス、可用性と信頼性、ストレージ、サービスメッシュ、監視に関する考慮事項に適用されます。

セキュリティ

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

Azure プラットフォームは、ネットワーク侵入や分散型サービス拒否 (DDoS) 攻撃など、さまざまな脅威に対する保護を強化します。パブリック HTTPS エンドポイントを公開する AKS でホストされる Web アプリケーションとサービスを保護するには、Web アプリケーションファイアウォール (WAF) を使用する必要があります。 SQL インジェクション、クロスサイトスクリプティング、その他の Web エクスプロイトなど、一般的な脅威からの保護を提供する必要があります。これを行うには、Open Web Application Security Project (OWASP) ルールとカスタムルールを使用します。 Azure Web Application Firewall では、一般的な悪用や脆弱性から Web アプリケーションを一元的に保護します。 Azure WAF は、Azure Application Gateway、Azure Front Door、Azure Content Delivery Network を使用してデプロイできます。

DDoS 攻撃は、アプリケーションをクラウドに移行する組織が直面する最大の可用性とセキュリティの問題の 1 つです。 DDoS 攻撃では、アプリケーションのリソースを使い果たし、正当なユーザーがアプリケーションを使用できなくなるようにすることが試みられます。 DDoS 攻撃は、インターネット経由で一般に到達可能なすべてのエンドポイントが標的になり得ます。 Azure のすべてのプロパティには、追加コストなしで、Azure DDoS インフラストラクチャ保護を介した保護が含まれています。グローバルにデプロイされる Azure ネットワークのスケールと容量が、常時有効なトラフィック監視とリアルタイムのリスク軽減によって、一般的なネットワーク層攻撃からの強化された保護を提供します。 DDoS インフラストラクチャ保護には、ユーザーの構成もアプリケーションの変更も不要です。これは、Azure DNS などの PaaS サービスを含むすべての Azure サービスの保護に役立ちます。

Azure DDoS ネットワーク保護では、アプリケーションの設計に関するベストプラクティスと組み合わせることにより、DDoS 攻撃からの保護を向上させるための強化された DDoS 軽減機能が提供されます。すべての境界仮想ネットワークで Azure DDOS ネットワーク保護を有効にする必要があります。

セキュリティに関するその他の考慮事項を次に示します。

Key Vault、Azure Service Bus、Azure SQL Database など、AKS ワークロードで使用されるあらゆる PaaS サービスのためにプライベートエンドポイントを作成します。アプリケーションとこれらのサービスの間のトラフィックはパブリックインターネットに公開されません。 AKS クラスター仮想ネットワークとプライベートエンドポイントを介した PaaS サービスのインスタンス間のトラフィックは、Microsoft のバックボーンネットワークを経由しますが、通信は Azure Firewall によって渡されません。このメカニズムにより、セキュリティが向上し、データ漏えいに対する保護が強化されます。詳細については、「Azure Private Link とは」を参照してください。
AKS クラスターの前で Application Gateway を使用する場合、Web Application Firewall ポリシーを使用して、AKS 上で実行される一般向けワークロードを攻撃から保護します。
ネットワークポリシーを使用し、相互に通信できるコンポーネントを制御することにより、サービス内通信を分離し、セキュリティで保護します。既定では、Kubernetes クラスター内のすべてのポッドでは制限なしにトラフィックを送受信できます。セキュリティ向上のため、Azure ネットワークポリシーまたは Calico ネットワークポリシーを使用して、異なるマイクロサービス間のトラフィックフローを制御するルールを定義できます。詳細については、「ネットワークポリシー」を参照してください。
AKS ノードへのリモート接続は公開しないでください。管理仮想ネットワーク内に踏み台ホスト (jump box) を作成します。 bastion ホストを使用して、AKS クラスターにトラフィックをルーティングします。
運用環境でプライベート AKS クラスターを使用することを検討するか、少なくとも AKS で許可された IP アドレスの範囲を使用して API サーバーへのアクセスをセキュリティで保護します。パブリッククラスターで許可された IP アドレス範囲を使用する場合は、Azure Firewall ネットワークルールコレクション内のすべてのエグレス IP アドレスを許可します。クラスター内操作では、Kubernetes API サーバーが使用されます。
Azure Firewall で DNS プロキシを有効にした場合、Azure Firewall は 1 つ以上の仮想ネットワークから選択した DNS サーバーに DNS クエリを処理および転送できます。この機能は非常に重要であり、ネットワークルールで信頼性の高い FQDN フィルタリングを行うために必要です。 Azure Firewall とファイアウォールポリシーの設定で DNS プロキシを有効にすることができます。 DNS プロキシログの詳細については、「Azure Firewall ログとメトリック」を参照してください。
Application Gateway の前で Azure Firewall を使用する場合は、HTTPS 経由でワークロードを公開するように Kubernetes イングレスリソースを構成し、テナントごとに個別のサブドメインとデジタル証明書を使用できます。 Application Gateway イングレスコントローラー (AGIC) により、Secure Sockets Layer (SSL) 終端用の Application Gateway リスナーが自動的に構成されます。
NGINX イングレスコントローラーなどのサービスプロキシの前で、Azure Firewall を使用できます。このコントローラーは、リバースプロキシ、構成可能なトラフィックルーティング、Kubernetes サービスの TLS 終端を提供します。個別の Kubernetes サービスのイングレスルールとルートを構成するには、Kubernetes イングレスリソースが使われます。イングレスコントローラーとイングレスルールを使用することにより、1 つの IP アドレスを使用して、Kubernetes クラスター内の複数のサービスにトラフィックをルーティングできます。 TLS 証明書は、認識された証明機関を使用して生成できます。また、Let's Encrypt を使用して、動的パブリック IP アドレスまたは静的パブリック IP アドレスを指定し、TLS 証明書を自動的に作成することもできます。詳細については、「HTTPS イングレスコントローラーを作成し、AKS で独自の TLS 証明書を使用する」を参照してください。
Azure Firewall オペレーターと、クラスターおよびワークロードチームの間では、初期クラスターのデプロイと、ワークロードとクラスターのニーズの進化に伴う継続的な方法の両方で、厳密な調整が必要です。これは、OAuth 2.0 や OpenID Connect など、クライアントを認証するためにワークロードによって使用される認証メカニズムを構成する場合に特に当てはまります。
この記事で説明されている環境をセキュリティで保護するには、次のガイドラインに従います。

高可用性と信頼性

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。詳細については、「信頼性の重要な要素の概要」を参照してください。

ここでの可用性と信頼性に関する考慮事項は、AKS のマルチテナントに固有の考慮事項ではありません。これらは、このソリューションの不可欠な要件だと考えています。 AKS クラスターとワークロードの可用性を最適化するには、次の方法を検討してください。

リージョン内の回復性

デプロイ時に、可用性を高めるために Azure Firewall が複数の可用性ゾーンにまたがるように構成できます。アップタイムの割合については、Azure Firewall SLA を参照してください。また、この構成は SLA に影響しますが、近接性のために Azure Firewall を特定のゾーンに関連付けることもできます。可用性ゾーンにデプロイされるファイアウォールについては追加のコストは発生しません。ただし、可用性ゾーンに関連する受信および送信データ転送については追加のコストが発生します。詳細については、「帯域幅の料金詳細」をご覧ください。
リージョン内のすべての可用性ゾーンに AKS クラスターのノードプールをデプロイします。ノードプールの前で Azure Standard Load Balancer または Application Gateway を使用します。このトポロジでは、データセンターが 1 つ停止した場合の回復性が向上します。クラスターノードは 1 つのリージョンに含まれている 3 つの別個の可用性ゾーンにある、複数のデータセンターにまたがって分散されます。
リージョン内の回復性と高可用性を実現するため、Container Registry のゾーン冗長を有効にします。
ポッドトポロジの分散制約を使用して、リージョン、可用性ゾーン、ノードなどの障害ドメイン間でポッドを AKS クラスター全体に分散する方法を制御します。
ミッションクリティカルなワークロードがホストされる AKS クラスターには、アップタイム SLA の使用を検討します。アップタイム SLA は、クラスターに対して利用料金に基づく高い SLA を実現するためのオプションの機能です。アップタイム SLA では、可用性ゾーンを使用するクラスターに対して、Kubernetes API サーバーエンドポイントの高可用性が保証されます。可用性ゾーンを使用しないクラスターでも使用できますが、SLA は低くなります。 SLA の詳細については、「アップタイム SLA」を参照してください。 AKS は、更新ドメインおよび障害ドメイン全体でマスターノードレプリカを使用して、SLA 要件が満たされるようにします。

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

1 つの地域内の少なくとも 2 組の Azure リージョンペアにソリューションをデプロイすることを検討します。事業継続とディザスターリカバリーを保証するために、”アクティブ/アクティブ”または”アクティブ/パッシブ”のルーティング方法により、Azure Traffic Manager または Azure Front Door などのグローバルロードバランサーを使用します。
Azure Firewall はリージョンサービスです。 2 つ以上のリージョンにソリューションをデプロイする場合は、各リージョンに Azure Firewall を作成する必要があります。グローバルの Azure Firewall ポリシーを作成して、すべてのリージョンハブに適用される組織に必須のルールを含めることができます。このポリシーは、リージョン Azure ポリシーの親ポリシーとして使用できます。空ではない親ポリシーを使って作成されたポリシーは、親ポリシーからすべてのルールコレクションを継承します。親ポリシーから継承されたネットワークルールコレクションは、新しいポリシーの一部として定義されているネットワークルールコレクションより常に優先されます。この同じロジックがアプリケーションルールコレクションに適用されます。ただし、ネットワークルールコレクションは、継承に関係なく、常にアプリケーションルールコレクションより先に処理されます。 Standard および Premium のポリシーの詳細については、「Azure Firewall Manager ポリシーの概要」を参照してください。
QA 環境でリージョン内のフェールオーバープロセスのスクリプト化、文書化、定期テストを行ってください。これにより、コアサービスがプライマリリージョンの停止の影響を受ける場合に、予期しない問題を回避できます。また、これらのテストは、DR アプローチが RPO または RTO ターゲットを満たしているかを、フェールオーバーに必要となる最終的な手動のプロセスおよび介入と組み合わせて検証します。
フェールバックプロシージャをテストして、想定した動作を検証してください。
コンテナーイメージを Container Registry に格納します。レジストリを各 AKS リージョンに geo レプリケートします。詳細については、「Azure Container Registry の geo レプリケーション」を参照してください。
可能であれば、コンテナーにサービス状態を格納しないようにします。代わりに、マルチリージョンレプリケーションをサポートする Azure PaaS を使用します。
Azure Storage を使用する場合は、ストレージをプライマリリージョンからバックアップリージョンに移行するプロセスをテストします。

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

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

DevOps

継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインで Helm チャートを使用して、ワークロードを AKS にデプロイします。 GitHub Actions または Azure DevOps などの DevOps システムを使用します。詳細については、「Azure Kubernetes Service へのビルドとデプロイ」を参照してください。
ユーザーによる使用を可能にする前にアプリケーションを適切にテストするには、アプリケーションライフサイクル管理で A/B テストとカナリアデプロイを使用します。同じサービスの異なるバージョン間でトラフィックを分割するために使用できる手法はいくつかあります。別の方法として、サービスメッシュの実装によって提供されるトラフィック分割機能を使用することもできます。詳細については、「Linkerd Traffic Split 」および「Istio Traffic Management」を参照してください。
Azure Container Registry または別のコンテナーレジストリ (Docker Hub など) を使用して、クラスターにデプロイされているプライベート Docker イメージを格納します。 AKS では、その Microsoft Entra ID を使って Azure Container Registry に対して認証できます。
実稼働環境のネットワークトポロジとファイアウォール規則をミラー化する別の実稼働前環境で、ワークロードのイングレスとエグレスをテストします。段階的なロールアウト戦略は、新しい機能またはネットワークルールを実稼働環境にリリースする前に、ネットワークまたはセキュリティの問題を検出するのに役立ちます。

監視

Azure Firewall は、ファイアウォールによる受信および送信トラフィックをログ記録に関して、Azure Monitor と完全に統合されています。詳細については、「Azure Firewall の脅威インテリジェンスベースのフィルター処理」を参照してください。

次の監視に関する考慮事項は、AKS のマルチテナントに固有の考慮事項ではありません。ただし、このソリューションに不可欠な要件と考えられています。

Container insights を使用して、AKS クラスターとワークロードの正常性状態を監視します。
診断ログとメトリックを収集するために、すべての PaaS サービス (Container Registry または Key Vault など) を構成します。

コストの最適化

結果として得られるアーキテクチャのコストは、次のような構成の詳細によって異なります。

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

これらの構成の詳細を評価した後、Azure 料金計算ツールを使用してコストを見積もります。価格最適化オプションの詳細については、Microsoft Azure Well-Architected フレームワークの「コスト最適化の原則」を参照してください。

このシナリオのデプロイ

このシナリオのソースコードは、GitHub で入手できます。このソリューションはオープンソースであり、MIT ライセンスで提供されます。

前提条件

オンラインデプロイの場合は、Azure アカウントが必要です。お持ちでない場合は、開始する前に無料の Azure アカウントを作成してください。 Azure DevOps を使用して Terraform モジュールをデプロイする前に、次の要件を満たす必要があります。

Terraform 状態ファイルを Azure ストレージアカウントに格納します。ストレージアカウントを使用してリモートの Terraform 状態、状態ロック、保存時の暗号化を格納する方法の詳細については、「Terraform 状態を Azure Storage に格納する」を参照してください。
Azure DevOps プロジェクトを作成します。詳細については、「Azure DevOps でのプロジェクトの作成」を参照してください。
Azure サブスクリプションへの Azure DevOps サービス接続を作成します。サービス接続を作成するときに、サービスプリンシパル認証 (SPA) または Azure マネージドサービス ID を使用できます。いずれの場合も、Azure サブスクリプションへの接続に Azure DevOps によって使用されるサービスプリンシパルまたはマネージド ID に、サブスクリプション全体の所有者ロールが割り当てられている必要があります。

Azure へのデプロイ

Azure サブスクリプション情報を用意します。

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

git clone https://github.com/Azure-Samples/private-aks-cluster-terraform-devops.git

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

共同作成者

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

プリンシパル作成者:

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

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

次のステップ

Microsoft Azure Well-Architected フレームワークの AKS の推奨事項とベストプラクティスを確認します。

Azure Kubernetes Service (AKS) クラスターの保護に Azure Firewall を使用する