Azure Firewall を使用して AKS クラスターを保護する

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

アーキテクチャ

このアーキテクチャのVisio ファイルをダウンロードしてください。

Workflow

次のワークフローは、上記のダイアグラムに対応しています。

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

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

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

AKS クラスターは次で構成されます。

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

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

Azure Bastion ホストは、ジャンプボックス VM へのセキュリティの強化された Secure Shell (SSH) 接続を提供します。 Azure Container Registryは、Helm チャートなどのコンテナーイメージと成果物をビルド、格納、管理するために使用されます。

AKS には、クラスターと外部ネットワーク間のイングレストラフィックとエグレストラフィックをセキュリティで保護するための組み込みソリューションは用意されていません。

このため、この記事のアーキテクチャには、宛先ネットワークアドレス変換 (DNAT) 規則を使用して受信トラフィックを制御するAzure Firewallと、ネットワークとアプリケーションの規則を使用した送信トラフィックが含まれています。ファイアウォールは、ソースネットワークアドレス変換 (SNAT) をクラスターからの送信フローに適用します。ポッドの IP アドレスは、ファイアウォールのパブリック IP アドレスのいずれかに置き換えられます。これは、パートナー許可リストのクラスターのエグレス ID になります。ファイアウォールは、脅威インテリジェンスベースのフィルター処理を使用してワークロードを保護します。 Azure FirewallとAzure Bastionは、プライベート AKS クラスターをホストする仮想ネットワークとピアリングされたハブ仮想ネットワークにデプロイされます。ルートテーブルとユーザー定義ルート (UDR) は、AKS クラスターからの送信トラフィックをAzure Firewallに送信します。

Note

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

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

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

仮想ネットワークリンクは、AKS クラスターをホストする仮想ネットワークを、前に説明したプライベート DNS ゾーンに接続します。

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

Components

Azure Firewall は、Azure で実行されているクラウドワークロードに脅威保護を提供する、クラウドネイティブでインテリジェントなネットワークファイアウォールのセキュリティサービスです。このアーキテクチャでは、Azure Firewall は東西両方のトラフィック検査を提供します。 DNAT 規則を使用してプライベートワークロードに受信フローを発行し、送信フローをフィルター処理するネットワークとアプリケーションルール、送信トラフィックをパブリック IP アドレスに変換する SNAT を使用します。また、ハブ仮想ネットワークで脅威インテリジェンスベースのフィルター処理を使用してワークロードを保護します。
Container Registry は、オープンソースの Docker Registry 2.0 が基になっている、マネージド型のプライベート Docker レジストリサービスです。このアーキテクチャでは、コンテナーレジストリは、AKS クラスターにデプロイされる Helm チャートなどのコンテナーイメージと成果物をビルド、格納、管理します。ディザスターリカバリー (DR) シナリオの geo レプリケーションがサポートされています。
AKS は、Kubernetes クラスターのデプロイと管理を簡略化するマネージド Kubernetes サービスです。このアーキテクチャでは、AKS は、スポーク仮想ネットワーク内のシステムノードプールとユーザーノードプールを使用してプライベートクラスターをホストします。
Key Vault は、セキュリティを強化した API キー、パスワード、証明書、暗号化キーなどのシークレットへのアクセスを格納および制御するクラウドベースのサービスです。このアーキテクチャでは、Key Vault は AKS で実行されるワークロードのシークレットストアとして機能します。
Azure Bastionは、トランスポート層セキュリティ (TLS) 経由でAzure ポータルから直接、仮想ネットワーク内の VM にリモートデスクトッププロトコル (RDP) と SSH 接続を提供するフルマネージド PaaS です。このアーキテクチャでは、Azure Bastionは、Azure ポータルから TLS 経由でジャンプボックス VM へのより安全なアクセスを提供するため、パブリックインターネットに VM を直接公開する必要がなくなります。
Azure 仮想マシンは、仮想化の柔軟性を提供する、オンデマンドでスケーラブルなコンピューティングリソースを提供するコンピューティングサービスです。このアーキテクチャでは、Virtual Machinesは、AKS クラスターをホストする仮想ネットワークにデプロイされたジャンプボックスホストとして機能します。システム管理者は、api サーバーへの直接アクセスが制限されている場合に、Virtual Machinesを使用して kubectl 経由でプライベートクラスターを管理します。
Azure Virtual Network は、Azure のプライベートネットワークの基本的な構成ブロックです。 Virtual Network を使用すると、VM などの Azure リソースが、セキュリティを強化して相互、インターネット、およびオンプレミスネットワークと通信できるようになります。このアーキテクチャでは、Virtual Network は、さまざまなコンポーネントの AKS クラスターとサブネットをホストするスポークネットワークとのネットワーク分離と接続を提供します。 Azure FirewallとAzure Bastionを含むハブネットワークにピアリングされます。
仮想ネットワークインターフェイスは、Azure VM がインターネット、Azure、オンプレミスのリソースと通信できるようにするネットワークコンポーネントです。このアーキテクチャでは、ネットワークインターフェイスによってジャンプボックス VM と AKS ノードの接続が提供されます。子 VM が独自の専用ネットワークインターフェイスデバイスと IP アドレスを持てるように、複数の NIC を 1 つのAzure VM に追加できます。
Azure マネージドディスクは、Azure が Azure VM 上で管理するブロックレベルのストレージボリュームです。 Ultra Disks、Premium SSD、Standard SSD、Standard HDD を使用できます。このアーキテクチャでは、マネージドディスクはジャンプボックス VM と AKS クラスターノード用の永続的ストレージを提供します。
Blob Storage は、クラウド用のオブジェクトストレージソリューションです。 Blob Storageは、大量の非構造化データを格納するために最適化されています。このアーキテクチャでは、Blob Storage はジャンプボックス VM のブート診断ログを格納します。
Private Linkは、仮想ネットワーク内のプライベートエンドポイント経由で PaaS サービスAzureアクセスするのに役立つネットワークサービスです。このアーキテクチャでは、Private Link は Blob Storage、Container Registry、Key Vault などのサービスへのセキュリティで保護された接続を提供します。これにより、パブリックインターネットに公開されることなく、トラフィックが Azure バックボーンに残ります。また、これを使用して、所有している Azure でホストされているサービス、または Microsoft パートナーが提供するサービスにアクセスすることもできます。

代替案

Azure Firewallではなく、Microsoft Marketplace からMicrosoft以外のファイアウォールを使用できます。この方法では、AKS クラスターからの受信トラフィックと送信トラフィックを検査および許可または拒否するようにファイアウォールを適切に構成する必要があります。

シナリオの詳細

AKS クラスターは、マネージドまたはカスタムの仮想ネットワークにデプロイされます。クラスターには、そのネットワーク外のサービスに対する送信依存関係が引き続き存在します。管理と運用上の目的で、AKS クラスターノードは、これらの依存関係に関連付けられている特定のポートと完全修飾ドメイン名 (FQDN) にアクセスする必要があります。これらの要件には、クラスターの Kubernetes API サーバーへのアクセス、クラスターコンポーネントのダウンロード用のポートへのアクセス、コンテナーイメージをプルするための Microsoft Container Registry へのアクセスが含まれます。これらの送信依存関係は FQDN で定義されており、静的 IP アドレスがないため、ネットワークセキュリティグループ (NSG) を使用して送信トラフィックをロックダウンできなくなります。その結果、AKS クラスターでは、ノードとサービスが必要な外部リソースに到達できるように、既定で無制限の送信インターネットアクセスが許可されます。

ただし、運用環境では、通常、データ流出やその他の不要なネットワークトラフィックから Kubernetes クラスターを保護することをお勧めします。すべての受信および送信ネットワークトラフィックは、定義されたセキュリティ規則に従う必要があります。この要件を満たすために、エグレストラフィックを制限しながら、定期的なクラスターメンテナンスタスク、送信依存関係、ワークロード要件に必要なポートとアドレスへのアクセスを許可します。

簡単な解決策は、ドメイン名に基づいて送信トラフィックを制御できるファイアウォールデバイスを使用することです。ファイアウォールによって、信頼されたネットワークとインターネットの間にバリアが作成されます。 Azure Firewallを使用して、送信先の FQDN、プロトコル、ポートに基づいて送信トラフィックを制限し、きめ細かいエグレストラフィック制御を提供します。また、AKS クラスターの送信依存関係に関連付けられた FQDN の許可リスト登録も可能になります。これは、NSG では実現できません。また、共有境界ネットワークにデプロイされたAzure Firewallに対する脅威インテリジェンスベースのフィルター処理により、イングレストラフィックを制御し、セキュリティを強化できます。このフィルタリングにより、アラートを生成し、既知の悪意のある IP アドレスやドメインとの間のトラフィックを拒否できます。

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

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

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

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

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

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

考えられるユースケース

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

Azure Firewall経由でエグレスするように AKS クラスターを構成する

Azure Firewall経由で AKS エグレスを強制するには、ファイアウォールとルートテーブルだけでなく、クラスターを構成する必要があります。クラスターを作成するときは、次の決定を行います。

送信の種類を userDefinedRouting に設定します。 この送信の種類では、AKS はエグレス用のパブリック標準ロードバランサーをプロビジョニングせず、独自の SNAT パブリック IP アドレスを追加しません。ノードプールサブネットからのすべての送信トラフィックは、UDR に従ってAzure Firewallプライベート IP アドレスに従います。これによって、すべての送信フローをファイアウォールで完全に可視化できます。詳細については、「 AKS でクラスターの送信の種類を構成する」を参照してください。
必要なエグレス許可リストには、 AzureKubernetesService FQDN タグを使用します。 AKS では、コントロールプレーン通信、イメージプル、ID、およびその他のプラットフォームサービスのために、長く頻繁に更新される FQDN の一覧への送信アクセスが必要です。これらの FQDN を自分で維持する代わりに、AzureKubernetesService FQDN タグを使用するAzure Firewall アプリケーション規則を作成します。 Azure Firewallは、プラットフォームの必要なエンドポイントでこのタグを最新の状態に保ちます。このタグを、ネットワークタイムプロトコル (NTP)、TCP 9000 および UDP 1194 上の API サーバー、ワークロードで使用するコンテナーレジストリの対象となるネットワーク規則と組み合わせます。
API サーバー仮想ネットワーク統合を使用して、プライベートネットワーク上の API サーバートラフィックを保持します。 API サーバー仮想ネットワーク統合は、API サーバーエンドポイントを仮想ネットワーク内の委任されたサブネットに投影します。ノードから API サーバーへのトラフィックはプライベートネットワーク上に残り、Azure Firewallを走査しません。この動作により、AKS トンネルネットワークルールが不要になり、ファイアウォールで検査する必要があるエグレスフローの数が減ります。 API サーバーへのパブリックネットワークアクセスもブロックする場合は、API サーバーの仮想ネットワーク統合をプライベートクラスター設定と組み合わせます。詳しくは、「API サーバー仮想ネットワーク統合を使用した AKS クラスターの作成」をご覧ください。 API サーバー仮想ネットワーク統合は、新しいプライベートクラスターに推奨されるアプローチです。 Private Linkを使用する古いプライベートクラスターの実装はサポートされていますが、仮想ネットワーク統合によって削除される DNS とトンネルの複雑さが増します。

Azure Firewall のパブリック IP アドレスと SNAT 容量を計画する

Azure Firewallでは、すべての送信フローに SNAT が使用されます。ファイアウォールに接続されている各パブリック IP アドレスには、固定数の SNAT ポートが用意されています。バックエンドインスタンスあたり IP アドレスあたり約 2,496 ポートです。運用 AKS クラスターでは、ポッドから多数の同時送信フローが生成されます。特に、ポッドが少数の外部宛先への短時間の接続を多数開いている場合です。パブリック IP アドレスのプロビジョニングが不足している場合、SNAT ポートの枯渇と送信呼び出しは、診断が困難な接続タイムアウトで断続的に失敗し始めます。

AKS でのAzure Firewallによるネットワークトラフィックの制限に関する AKS ガイダンスでは、SNAT ポートの枯渇を回避するために、運用ワークロードに対して、Azure Firewallに少なくとも 20 個のフロントエンドパブリック IP アドレスを推奨しています。この数値は、固定要件ではなく、開始点として扱います。適切な数は、ワークロードの送信コンカレンシー、宛先の多様性、接続の有効期間によって異なります。
NAT ゲートウェイ統合Azure Firewall使用するか、パブリック IP プレフィックスをアタッチして、多数のパブリック IP アドレスの管理を簡略化し、使用可能な SNAT ポートプールを拡張します。 NAT ゲートウェイは SNAT スケールを大幅に向上させ、コンカレンシーの高いエグレスに推奨されるオプションです。
Azure Firewallで SNAT ポート使用率を監視し、パブリック IP アドレスが飽和状態に達する前にファイアウォールでスケーリングします。詳しくは、Azure Firewall を監視するを参照してください。
少数のワークロードが送信フロープロファイルを支配している場合 (たとえば、すべてのノードで実行されるが、トラフィックを 1 つまたは 2 つのエンドポイントにのみ送信するログシッパーやスクレーパーなど)、1 つのノイズの多いワークロードに対応するためにファイアウォール IP アドレスをスケーリングするのではなく、静的エグレスゲートウェイを介した専用のエグレスパスを検討してください。

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

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

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

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

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

詳細については、「Azure ポータルを使用したAzure Firewallのデプロイと構成」を参照してください。

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

Azure DevOps を使用するときにプライベート AKS クラスターにワークロードをデプロイする

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

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

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

または、AKS クラスターをホストする仮想ネットワークまたはピアリングされた仮想ネットワークで、Managed DevOps プールを構成することもできます。マネージド DevOps プールは、開発チームが特定のニーズに合わせて調整されたAzure DevOpsエージェントプールを作成するのに役立ちます。セキュリティのベストプラクティスを実装し、コストとパフォーマンスのバランスを取るためのオプションを提供し、一般的なシナリオのパスを提供し、カスタムプールの作成と管理に費やす時間を大幅に短縮します。詳細については、「Microsoft Managed DevOps Pools アーキテクチャの概要」を参照してください。

仮想ネットワーク内の Managed DevOps プールからエージェントを追加して、CI/CD パイプラインがプライベート AKS クラスターの Kubernetes API サーバーと対話できるようにします。これらのエージェントにより、パイプラインは、パブリックネットワークアクセスをブロックし、同じ仮想ネットワークまたはピアリングされたネットワークで定義されたプライベートエンドポイント経由でのみ接続を許可する、Container Registry などのAzure リソースにアクセスすることもできます。詳細については、「マネージド DevOps プールのネットワークを構成する」を参照してください。

パブリックロードバランサーの前でAzure Firewallを使用する

このシナリオでは、AKS で実行されるワークロードは、クラスターのノードリソースグループ内のパブリック Azure ロードバランサー (Kubernetes LoadBalancer サービス) を介して公開されます。 Azure Firewallロードバランサーの前に配置され、専用のパブリック IP アドレスと DNAT 規則を使用して、受信トラフィックをロードバランサーのパブリック IP アドレスとポートに変換します。このパターンは、ファイアウォールでの受信検査、DNAT、脅威インテリジェンスベースのフィルター処理を一元化し、AKS が Kubernetes サービスのロードバランサーを引き続き管理できるようにします。この方法は、ワークロードにインターネットから到達できる必要があるが、すべてのイングレストラフィックがクラスターに到達する前にハブファイアウォールを通過する必要がある場合に使用します。

この図は、シナリオのネットワークトポロジを示しています。

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

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

内部ロードバランサーの前でAzure Firewallを使用する

このシナリオでは、ASP.NET Core アプリケーションは AKS クラスターによってサービスとしてホストされ、内部ロードバランサーが公開するイングレスコントローラーによって前面に配置されます。 AKS のイングレスに推奨される方法は、アプリケーションルーティングゲートウェイ API の実装または Application Gateway for Containers です。アプリケーションルーティングゲートウェイ API の実装では、Kubernetes Gateway API 標準と Istio ベースのコントロールプレーンを使用して、クラスター内のイングレストラフィック管理を行います。 Application Gateway for Containers は、フルマネージドの Azure ネイティブレイヤー 7 ロードバランサーであり、ゲートウェイ API もサポートし、高度なトラフィック管理、TLS 終了、クラスター外でのマルチサイトホスティングを提供します。どちらのオプションでも、AKS クラスターをホストするスポーク仮想ネットワーク内のプライベート IP アドレスを持つ内部ロードバランサーの構成がサポートされます。 LoadBalancer注釈をメタデータセクションに含むイングレスコントローラー(通常はClusterIPまたはservice.beta.kubernetes.io/azure-load-balancer-internal: "true" サービス)をデプロイすると、kubernetes-internalと呼ばれる内部ロードバランサーがノードリソースグループに作成されます。詳細については、AKS で内部ロードバランサーを使用する方法をご参照ください。次の図に示すように、Azure Firewallは専用のAzureパブリック IP アドレスを使用してテスト Web アプリケーションを公開します。

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

AKS でホストされるテスト Web アプリケーションの要求は、Azure Firewallがパブリック IP 構成を介して公開するパブリック IP アドレスに送信されます。パブリック IP アドレスとパブリック IP アドレス構成はどちらも、このワークロード専用です。
Azure Firewall DNAT ルールは、Azure Firewallパブリック IP アドレスとポートを、選択したイングレスまたはゲートウェイコントローラーがノードリソースグループの AKS クラスターの内部ロードバランサーで使用するプライベート IP アドレスとポートに変換します。
内部ロードバランサーは、AKS クラスター内のエージェントノードで実行される 1 つの Kubernetes サービスポッドに要求を送信します。
応答メッセージは、UDR を介して元の呼び出し元に返されます。ルートでは、アドレスプレフィックスとして 0.0.0.0/0 を使用し、次ホップの種類として仮想アプライアンスを使用します。
ワークロードによって開始されるすべての送信呼び出しは、UDR によってAzure Firewallのプライベート IP アドレスにルーティングされます。

考慮事項

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

次の考慮事項の一部は、AKS クラスターを保護するためのAzure Firewall固有のガイダンスではなく、一般的な推奨事項です。これらの項目は、ソリューションの必須要件と見なされます。このガイダンスは、セキュリティ、パフォーマンス、可用性と信頼性、ストレージ、サービスメッシュ、監視に関する考慮事項に適用されます。

Reliability

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。詳細については、「信頼性の設計レビューチェックリスト」を参照してください。

AKS クラスターとワークロードの可用性を最適化するには、次の方法を検討してください。

リージョン内の回復性

デプロイ時に、可用性を高めるために Azure Firewall が複数の可用性ゾーンにまたがるように構成できます。アップタイムの割合については、Microsoft オンラインサービスの SLA のAzure Firewallサービスレベルアグリーメント (SLA) を参照してください。また、近接性のためにAzure Firewallを特定のゾーンに関連付けることもできます。ただし、この構成は SLA に影響します。可用性ゾーン間のデータ転送を含め、可用性ゾーンにデプロイされたファイアウォールには追加料金は適用されません。
リージョン内のすべての可用性ゾーンに AKS クラスターのノードプールをデプロイします。ノードプールの前にAzureロードバランサーまたは Application Gateway を使用します。このトポロジでは、データセンターが 1 つ停止した場合の回復性が向上します。クラスターノードは 1 つのリージョンに含まれている 3 つの別個の可用性ゾーンにある、複数のデータセンターにまたがって分散されます。
コンテナーレジストリでゾーン冗長を有効にして、リージョン内の回復性と高可用性を実現します。
ポッドトポロジの分散制約を使用して、リージョン、可用性ゾーン、ノードなどの障害ドメイン間でポッドを AKS クラスター全体に分散する方法を制御します。
ミッションクリティカルなワークロードをホストする AKS クラスターには、Standard または Premium の価格レベルを使用することを検討してください。これらのレベルには、クラスターの財務的にバックアップされたアップタイム SLA が含まれます。 Standard レベルでは、可用性ゾーンを使用するクラスターでは Kubernetes API サーバーエンドポイントの 99.95% 可用性が保証され、可用性ゾーンを使用しないクラスターでは 99.9% が保証されます。 Premium レベルでは、Kubernetes バージョンに対する追加の長期サポート (LTS) と同じ SLA 保証が提供されます。詳細については、「 AKS の価格レベル」を参照してください。 AKS では、更新ドメインと障害ドメイン間でコントロールプレーンレプリカを使用して、SLA 要件が満たされていることを確認します。
信頼性、セキュリティ、パフォーマンスに関するベストプラクティスが組み込まれたフルマネージドノード管理エクスペリエンスの恩恵を受ける新しいクラスターには、 AKS 自動 SKU を使用することを検討してください。 AKS Automatic では、既定で Standard 価格レベルが使用されます。

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

1 つの地域内の少なくとも 2 組の Azure リージョンペアにソリューションをデプロイすることを検討します。ビジネス継続性とディザスターリカバリー (BC/DR) を保証するには、アクティブ/アクティブまたはアクティブ/パッシブルーティング方法を使用して、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 レプリケートします。詳細については、「コンテナーレジストリの Geo レプリケーション」を参照してください。
リージョンレプリカが低下すると、Container Registry はグローバルエンドポイント (<registry>.azurecr.io) を介してプルを正常なレプリカに自動的に再ルーティングします。このフェールオーバーは数分以内に内部で実行され、AKS 側または DNS 構成の変更は必要ありません。
可能であれば、コンテナーにサービス状態を格納しないようにします。代わりに、複数リージョンのレプリケーションをサポートする Azure PaaS を使用してください。
Storage を使用する場合は、プライマリリージョンからバックアップリージョンにストレージを移行するためのプロセスを準備してテストします。

セキュリティ

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

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

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

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

セキュリティに関するその他の考慮事項は次のとおりです。

Key Vault、Azure Service Bus、Azure SQL Databaseなど、AKS ワークロードが使用するすべての PaaS サービスのプライベートエンドポイントを作成します。アプリケーションとこれらのサービスの間のトラフィックは、パブリックインターネットに公開されません。 AKS クラスター仮想ネットワークとプライベートエンドポイント経由の PaaS サービスのインスタンス間のトラフィックは、Microsoftバックボーンネットワークを通過しますが、通信はAzure Firewallを通過しません。このメカニズムにより、セキュリティが向上し、データ漏えいに対する保護が強化されます。詳細については、「 Private Link」を参照してください。
AKS クラスターの前で Application Gateway を使用する場合は、Web Application Firewall ポリシーを使用して、AKS で実行される一般向けワークロードを攻撃から保護します。
ネットワークポリシーを使用して、サービス内通信を分離し、セキュリティで保護します。相互に通信できるコンポーネントを制御します。既定では、Kubernetes クラスター内のすべてのポッドでは制限なしにトラフィックを送受信できます。 Cilium を使用Azure CNI を使用して、ネットワークポリシーを適用します。既存のツールとの互換性のために必要な場合は、Calico もサポートされます。詳細については、「 AKS のネットワークポリシー」を参照してください。
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ログとメトリック」を参照してください。
ゲートウェイ API ベースのイングレスコントローラーの前でAzure Firewallを使用して、HTTPS 経由でワークロードを公開し、アプリケーションごとに個別のサブドメインと証明書を使用できます。 AKS に推奨されるマネージドイングレスソリューションは、 Application Gateway for Containers とアプリケーションルーティングゲートウェイ API の実装です。 Application Gateway for Containers は、Kubernetes Gateway API とマルチサイトホスティングをサポートするクラスター外のフルマネージド Azure ネイティブレイヤー 7 ロードバランサーです。アプリケーションルーティングゲートウェイ API の実装では、Istio ベースのコントロールプレーンを使用して、Kubernetes Gateway および HTTPRoute リソースを介したクラスター内トラフィックルーティングを提供します。新しいデプロイには AGIC を使用しないでください。
ゲートウェイ API ベースのイングレスコントローラーの前でAzure Firewallを使用して、HTTPS 経由でワークロードを公開し、アプリケーションごとに個別のサブドメインと証明書を使用できます。 AKS に推奨されるマネージドイングレスソリューションは、 Application Gateway for Containers とアプリケーションルーティングゲートウェイ API の実装です。 Application Gateway for Containers は、Kubernetes Gateway API とマルチサイトホスティングをサポートするクラスター外のフルマネージド Azure ネイティブレイヤー 7 ロードバランサーです。アプリケーションルーティングゲートウェイ API の実装では、Istio ベースのコントロールプレーンを使用して、Kubernetes Gateway および HTTPRoute リソースを介したクラスター内トラフィックルーティングを提供します。新しいデプロイには AGIC を使用しないでください。
選択したイングレスで TLS 終了を構成します。 Application Gateway for Containers での TLS については、Application Gateway for Containers を使用した TLS ポリシーに関する説明を参照してください。アプリケーションルーティングを使用した TLS については、アプリケーションルーティングゲートウェイ API の実装を使用したイングレスのセキュリティ保護に関する説明を参照してください。または、cert-manager を使用して Let's Encrypt で TLS 証明書を自動的に生成することもできます。
Azure Firewall オペレーターとクラスターチームとワークロードチーム間の厳密な調整は、クラスターの初期デプロイと、ワークロードとクラスターのニーズの進化に伴う継続的な運用に必要です。この調整は、ワークロードがクライアントの認証に使用する認証メカニズム ( OAuth 2.0 や OpenID Connect など) を構成する場合に特に重要です。
この記事で説明されている環境をセキュリティで保護するには、次のガイドラインを使用します。

コストの最適化

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

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

サービス階層
スケーラビリティ (特定の需要をサポートするためにサービスが動的に割り当てるインスタンスの数)
自動化スクリプト
あなたのDRレベル

これらの構成の詳細を評価した後、 Azure 料金計算ツールを使用してコストを見積もります。

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

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

DevOps

CI/CD パイプラインの Helm チャートを使用して、ワークロードを AKS にデプロイします。 GitHub Actions または Azure DevOps などの DevOps システムを使用します。詳細については、AKS へのビルドとデプロイに関するページをご覧ください。
アプリケーションライフサイクル管理で A/B テストとカナリアデプロイを使用して、アプリケーションをユーザーが使用できるようにする前に、アプリケーションを適切にテストします。複数の手法を使用して、同じサービスの異なるバージョンにトラフィックを分割できます。または、サービスメッシュ実装で提供されるトラフィック分割機能を使用することもできます。詳細については、「 Istio Traffic Management」を参照してください。
Azure Container Registryまたは別のコンテナーレジストリ (Docker Hub など) を使用して、クラスターにデプロイされているプライベート Docker イメージを格納します。 AKS では、その Microsoft Entra ID を使って Azure Container Registry に対して認証できます。
実稼働環境のネットワークトポロジとファイアウォール規則をミラー化する別の実稼働前環境で、ワークロードのイングレスとエグレスをテストします。段階的なロールアウト戦略は、新しい機能またはネットワークルールを運用環境にリリースする前に、ネットワークまたはセキュリティの問題を検出するのに役立ちます。
コードとしてのインフラストラクチャ (IaC) パイプラインで管理する Azure Firewall とルーティングリソースと、ネットワークまたはセキュリティ運用担当者が帯域外で管理するリソースを決定します。 Terraform を使用している場合は、Azure Firewall Policy リソースおよび Azure Route Table リソースで、ライフサイクルメタ引数の ignore_changes を使用できます。この構成により、Terraform はリソースを作成して所有し、次の適用で元に戻すことなく、ルートテーブル上のファイアウォールポリシーと UDR の DNAT、アプリケーション、およびネットワークルールを Terraform の外部で管理できるようにします。このシナリオのサンプル Terraform モジュールでは、このパターンを使用します。

モニタリング

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

Azure Firewall構造化されたログを有効にして、クエリと分析を簡略化するスキーマベースの詳細なログ記録を実現します。構造化ログは、トラフィックパターン、ルールヒット、脅威インテリジェンスアクション、侵入検出および防止システム (IDPS) 信号を、Azure Monitor Log Analytics、Microsoft Sentinel、Microsoft以外の SIEM ツールと統合された形式で可視化します。
Azure Monitorで Kubernetes 監視を使用して、AKS クラスターとワークロードの正常性状態を監視します。
診断ログとメトリックを収集するために、すべての PaaS サービス (Container Registry または Key Vault など) を構成します。

貢献者達

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

主要著者:

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

その他の共同作成者:

サム・コーガン |シニアクラウドソリューションアーキテクト

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

AKS のWell-Architected Framework サービスガイド

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-06-23