MENU

AKSのL7保護を実装する方法｜Application Gateway for ContainersとManaged Cilium

Azure

AKSで公開APIやWebアプリを運用していると、「WAFを置けば十分なのか」「NetworkPolicyだけでPod間の横移動を防げるのか」「L7検査によって通信データやログがどこまで外部に出るのか」を判断しにくいものです。

結論から言うと、2026年7月8日にMicrosoftが公開した「Microsoft documents end-to-end AKS Layer 7 protection with Application Gateway for Containers and managed Cilium」は、既存のAKSクラスタへ新しい防御が自動適用される更新ではありません。Application Gateway for ContainersとWAFでクラスタ外からの通信を検査し、Advanced Container Networking ServicesのCilium L7ポリシーでPod直前やPod間通信を制御する、エンドツーエンドの防御構成を具体化した公式情報です。導入するには、管理者がアドオンを有効化し、Gateway APIやWAF、CiliumNetworkPolicyを明示的に設定する必要があります。(TECHCOMMUNITY.MICROSOFT.COM)

日本企業が最初に確認すべきなのは機能ではなく、利用リージョンとデータ境界です。2026年6月24日時点のApplication Gateway for Containers対応リージョン一覧には、Japan EastとJapan Westが掲載されていません。国内リージョン内での処理が必須の場合は、すぐに本番導入へ進むのではなく、リージョン要件を満たせるかを先に確認する必要があります。(Microsoft Learn)

目次

2026年7月8日の公式情報で何が明確になったのか

Microsoftが示した構成の重要点は、異なる場所で動作する複数の防御を組み合わせることです。

インターネット
    ↓
Application Gateway for Containers
    ↓
WAFによる攻撃パターンの検査
    ↓
Gateway／HTTPRouteによるルーティング
    ↓
Cilium L7ポリシーによるメソッド・パス・送信元の検査
    ↓
AKS上のPod
    ↓
Pod間通信・外向き通信の制御

Application Gateway for Containersは、AKSクラスタ外に配置されるAzure管理のL7データプレーンです。クラスタ内ではALB Controllerが動作し、Gateway、HTTPRoute、IngressなどのKubernetesリソースをApplication Gateway for Containersの設定へ変換します。(Microsoft Learn)

一方、Advanced Container Networking Servicesでは、Ciliumとノード上のEnvoyを利用してL7通信を制御します。ポリシー対象となる通信だけがノードローカルのEnvoyへリダイレクトされ、HTTPメソッド、パス、gRPC、Kafkaなどのアプリケーション情報に基づいて許可・拒否されます。(Microsoft Learn)

なお、Application Gateway for ContainersはAI推論トラフィックのルーティングにも対応していますが、今回の公式情報の中心はAI機能の追加ではありません。主題は、AKSへ到達する通信とクラスタ内部の通信を一つの設計として保護することです。(Microsoft Learn)

Application Gateway for ContainersとManaged Ciliumは補完関係にある

WAFとCilium L7ポリシーは、どちらか一方を選ぶ機能ではありません。検査する場所と、判断に利用する情報が異なります。

制御主な適用場所防げる代表例単独では不足する点
Application Gateway for ContainersのWAFAKSへ入る前の外部通信SQLインジェクション、クロスサイトスクリプティング、既知のWeb攻撃パターンPod間の横移動や、クラスタ内サービスからの不正通信は直接制御できない
Cilium L7ポリシーPodへの入口、Pod間通信、外向き通信許可されていないHTTPメソッド、パス、API、gRPC呼び出しリクエスト本文やパラメーターに含まれる攻撃文字列を網羅的に検出するWAFではない
Kubernetes NetworkPolicyL3／L4の通信経路不要なIP、Pod、ポート間の通信GETとPOST、/productsと/adminを区別できない

例えば、Ciliumで「GET /productsのみ許可」と設定しても、SQLインジェクション文字列をクエリに含むGET /productsは、メソッドとパスだけを見れば許可条件に一致します。この通信を手前のWAFで検査すれば、Web攻撃として遮断できます。

反対に、正規の形式を持つPOST /productsが、本来呼び出しを許可されていないPodから送られた場合、一般的なWAFルールだけでは不正と判断できない可能性があります。ここでは、Podのラベルや通信先、HTTPメソッドを判断できるCilium L7ポリシーが有効です。

Microsoftの公開例でも、WAFが攻撃文字列を含むGETリクエストを止め、Ciliumが許可されていないPOSTやPod間通信を止める役割分担が示されています。(TECHCOMMUNITY.MICROSOFT.COM)

導入前に確認すべき利用条件

Application Gateway for ContainersとACNSのL7制御は、AKSクラスタであれば無条件に利用できるわけではありません。

項目主な利用条件・確認事項
Application Gateway for Containers対応Azureリージョンであること
AKSネットワークAzure CNIまたはAzure CNI Overlayを使用していること
ID基盤OIDC IssuerとWorkload Identityを有効化すること
Kubernetes APIGateway APIアドオンとApplication Load Balancerアドオンを有効化すること
Application Gateway for ContainersのリスナーHTTPまたはHTTPS、ポート80または443が基本
WAFポリシーApplication Gateway for Containersと同一サブスクリプション、同一リージョンに配置すること
ACNSのL7ポリシーAzure CNI Powered by Ciliumを使用すること
対応ノードCiliumデータプレーンはLinuxノードが対象
Kubernetesバージョン公式手順ではKubernetes 1.29以降が対象
Azure CLI当該手順ではAzure CLI 2.79.0以降が案内されている
既存のL7実装Istioなど別のL7ポリシー実装との併用可否を確認すること
料金Application Gateway for Containers、WAF、ACNS、監視基盤の料金を見積もること

Application Gateway for ContainersのAKSアドオンでは、Workload Identity、Gateway API、Application Load Balancerを有効にします。公式手順で示される主なフラグは次のとおりです。

az aks update \
  --resource-group <RESOURCE_GROUP> \
  --name <AKS_CLUSTER> \
  --enable-oidc-issuer \
  --enable-workload-identity \
  --enable-gateway-api \
  --enable-application-load-balancer

ACNSのL7制御を利用する場合は、Ciliumデータプレーンを前提として、ACNSに加えてL7のAdvanced Network Policiesを有効化します。

az aks update \
  --resource-group <RESOURCE_GROUP> \
  --name <AKS_CLUSTER> \
  --enable-acns \
  --acns-advanced-networkpolicies L7

2026年7月8日のブログ記事では構成が簡略化されていますが、実際の設定では--enable-acnsだけでなく、--acns-advanced-networkpolicies L7の指定が必要です。既存クラスタがCiliumを使用していない場合は、先にサポートされる移行経路、ノードプールの更新、メンテナンス時間を確認してください。(Microsoft Learn)

日本リージョンを利用している場合の判断

Application Gateway for Containersの対応リージョン一覧には、2026年6月24日時点でJapan EastとJapan Westが含まれていません。したがって、次の要件があるシステムでは特に注意が必要です。(Microsoft Learn)

  • 個人情報や機密情報を国内リージョン内で処理する必要がある
  • 社内規程で海外リージョンへの通信経路を禁止している
  • 顧客との契約でデータ処理地域を日本国内に限定している
  • BCPや監査の対象リージョンがJapan EastまたはJapan Westに固定されている

対応リージョンにApplication Gateway for Containersだけを配置すれば技術的な検証は可能でも、業務要件を満たすとは限りません。リクエストがどのリージョンで処理されるか、TLSをどこで終端するか、WAFログやアクセスログをどこに保存するかを整理したうえで、セキュリティ部門や法務部門の確認を受ける必要があります。

国内リージョン限定が必須であれば、現時点では本番採用を保留し、既存のApplication Gateway、Azure Front Door、クラスタ内Ingressなどを含めた代替構成を個別に比較するのが現実的です。

通信データとログの境界を分けて考える

エンドツーエンドのL7保護では、「通信を検査する場所」と「ログを保存する場所」を混同しないことが重要です。

境界処理される内容管理上の確認事項
Application Gateway for Containersの管理データプレーンHTTP、HTTPS、gRPCなどの受信通信とルーティング配置リージョン、TLS終端、WAFポリシー、ログ出力先
AKSクラスタ内のALB ControllerGatewayやHTTPRouteなどのKubernetes設定ServiceAccount、Workload Identity、RBAC、変更権限
AKSノード上のCilium／Envoyポリシー対象となるL7通信対象Pod、メソッド、パス、プロトコル、性能への影響
AKSノード上のACNSログ送信元、宛先、ポート、プロトコル、許可・拒否結果など保存量、ローテーション、ノード障害時の保持
Azure Monitorなどへの転送後集約・検索・長期保存するネットワークログ保存リージョン、保持期間、アクセス権、取り込み料金

ACNSのネットワークログは、ContainerNetworkLogリソースで取得対象を指定するまで生成されません。生成されたログは各ノードの/var/log/acns/hubble/events.logへJSON形式で書き込まれ、Azure Monitorを利用しなくてもクラスタ内で生成できます。ホストローカルのログはノードごとにローテーションされるため、長期保存や横断検索が必要な場合は、Azure MonitorまたはOpenTelemetry互換の独自パイプラインへ転送します。(Microsoft Learn)

この仕組みにより、ログを必ず外部サービスへ送信しなければならないわけではありません。一方で、Azure Monitorへ転送した時点で、ログ保存先、保持期間、閲覧権限、料金という新しい管理対象が生まれます。

取得対象は、名前空間、Pod、Service、ポート、プロトコル、通信方向、許可・拒否結果などで絞り込めます。すべての通信を無条件に保存するのではなく、監査対象の名前空間や拒否通信を優先することで、情報量とコストを抑えられます。メトリクスについても、ノードから送信する前に対象を絞り込めます。(Microsoft Learn)

管理者が制御すべき範囲

BYO方式とALB管理方式を使い分ける

Application Gateway for Containersには、Azureリソースを管理者が事前作成するBYO方式と、ALB Controllerにライフサイクルを管理させる方式があります。

方式向いている環境注意点
BYO方式ネットワーク管理者とアプリ開発者の権限を厳密に分離したい環境Kubernetes側でGatewayを削除しても、Azure側のFrontendなどが自動削除されない
ALB管理方式Kubernetesマニフェストを中心に迅速に構築したい環境GatewayやApplicationLoadBalancerの変更権限がAzureリソースのライフサイクルへ影響する
段階的な併用共通基盤は管理者が管理し、ルーティングはアプリチームへ委譲したい環境リソースごとの責任者と削除手順を事前に決める必要がある

基盤チームがサブネット、マネージドID、Application Gateway for Containers本体、WAFポリシーを管理し、開発チームにはHTTPRouteや限定されたCiliumNetworkPolicyだけを変更させる構成にすると、権限分離を実現しやすくなります。(Microsoft Learn)

マネージドIDへ必要最小限の権限を与える

AKSのApplication Load Balancerアドオンを利用すると、専用のユーザー割り当てマネージドIDが作成されます。公式手順では、管理対象のリソースグループに対して、Network Contributor、Reader、AppGw for Containers Configuration Managerなどのロールが割り当てられます。(Microsoft Learn)

注意したいのは、AzureのOwnerやContributorを付与しただけでは、Application Gateway for Containersで必要となるデータアクションを満たさない場合があることです。管理を簡単にするために過剰な権限を与えるのではなく、専用ロールを必要なスコープへ割り当ててください。(Microsoft Learn)

Kubernetesリソースの変更経路を制限する

Gateway、HTTPRoute、SecurityPolicy、WebApplicationFirewallPolicy、CiliumNetworkPolicyを誰でも変更できる状態では、保護を追加しても簡単に迂回されます。

実務では、次のような管理が必要です。

  • 本番環境への変更はGitOps経由に限定する
  • WAFポリシーの参照先をSecurityPolicyで制限する
  • HTTPRouteを変更できる名前空間と担当チームを限定する
  • CiliumNetworkPolicyの削除や許可範囲の拡大をレビュー対象にする
  • 一時的な例外には期限と責任者を設定する
  • ポリシー変更後に許可通信と拒否通信の両方をテストする

WAFはGateway全体だけでなく、HTTPRouteやリスナー単位でも適用できます。複数のサービスを一つのApplication Gateway for Containersで公開する場合でも、決済API、管理画面、一般公開サイトで異なるWAFポリシーを割り当てられます。(Microsoft Learn)

業務や開発で効果を得やすい使いどころ

複数サービスを一つの入口で公開する

一つのフロントエンドに複数のホスト名やHTTPRouteを設定できるため、複数のAKSアプリを共通の入口へ集約できます。

例えば、次のような分割が可能です。

shop.example.com      → 一般向けWebアプリ
api.example.com       → 公開API
admin.example.com     → 管理画面
partner.example.com   → 取引先向けAPI

外部からの通信は共通のApplication Gateway for Containersで受けつつ、ホスト名やパスごとに異なるWAFポリシーとバックエンドを設定できます。Pod側では、各サービスが本当に必要とするHTTPメソッドや通信元だけをCiliumで許可します。(Microsoft Learn)

管理APIや決済APIの操作を限定する

管理APIでは、接続できることと操作できることを分けて制御する必要があります。

例えば、検索用サービスにはGET /ordersだけを許可し、更新処理を担うサービスにだけPOST /ordersを許可します。誤設定や侵害によって検索用Podから更新APIが呼ばれても、Cilium L7ポリシーで拒否できます。

同時に、外部から届くSQLインジェクションやクロスサイトスクリプティングなどの攻撃はWAFで検査します。これにより、「正規の呼び出し元か」と「リクエスト内容が安全か」を別々の制御で確認できます。

マイクロサービス間の横移動を抑える

L3／L4のNetworkPolicyだけでは、同じサービスの同じポートを使う複数のAPI操作を区別できません。

Cilium L7ポリシーを使えば、フロントエンドから注文APIへのPOST /ordersは許可しながら、同じPodから管理用のDELETE /orders/{id}を拒否できます。侵害されたPodがクラスタ内部の別サービスへ自由にアクセスする横移動を抑える用途に向いています。(Microsoft Learn)

不要な外向き通信を止める

受信通信だけを保護しても、侵害されたコンテナが外部へデータを送信できれば被害は残ります。

基本方針として外向き通信を拒否し、DNS、必要なAzureサービス、外部API、更新先などを個別に許可します。ACNSではFQDNを利用した制御も可能ですが、CDNや動的な名前解決を利用するサービスでは、実際の通信先を観測してからポリシーを適用する必要があります。(Microsoft Learn)

実際に確認すべき通信パターン

PoCでは、正常系だけでなく、各防御層が想定どおりに拒否するかを確認します。

テスト期待結果主に確認する制御
許可されたクライアントからGET /products正常応答Gateway、HTTPRoute、Cilium L7
攻撃文字列を含むGET /productsWAFで遮断WAF
許可されていないPOST /productsCiliumで拒否Cilium L7
許可していないPodから同じAPIへ接続接続拒否またはドロップCilium L3／L4、L7
Podから未許可の外部ドメインへ接続接続失敗Egressポリシー
DNS名前解決正常動作DNS例外設定
Application Gatewayからのヘルスプローブ正常動作NSG、UDR、Pod到達性
ポリシー更新中の既存接続アプリ側で再試行されるリトライ設計

HTTPレベルで拒否された場合は403などのアプリケーション応答として確認できる一方、L3／L4でドロップされた通信はタイムアウトとして見える場合があります。監視では、単にエラー件数を見るだけでなく、どの層で拒否されたかを区別してください。(TECHCOMMUNITY.MICROSOFT.COM)

導入時に失敗しやすいポイント

失敗例起きる問題対策
アドオンを有効化しただけで保護されたと思うWAFやCiliumの許可・拒否ルールが存在せず、通信が従来どおり通るGateway、WAF、CiliumNetworkPolicyを別々に確認する
全名前空間へ一度にDefault Denyを適用するDNS、監視、外部API、ヘルスチェックが停止する先に通信を観測し、名前空間単位で段階適用する
WAFとCiliumを同じ機能として扱うWeb攻撃または横移動のどちらかが残る攻撃内容の検査と呼び出し権限の検査を分ける
NSGで受信・送信を一律拒否するヘルスプローブやAGCからAKSへの通信が失敗するAzureLoadBalancer、Podアドレス範囲、必要な制御エンドポイントを許可する
UDRで通信をNVAへ強制転送する戻り経路が非対称になり、接続が不安定になる往復経路と送信元アドレス変換を確認する
BYO方式でKubernetesリソースだけを削除するAzure側のFrontendなどが残るAzureリソースを含む削除手順を用意する
すべてのL7ログを長期保存する取り込み料金と機密情報の露出が増える拒否通信や重要名前空間へ対象を絞る
高負荷APIへ検証せずL7制御を適用するレイテンシーや処理能力が悪化する本番相当のリクエスト数で負荷試験する
IstioのL7制御と重ねて導入するサポート対象外や予期しない通信経路になるL7制御の責任をどちらか一方へ寄せる

Application Gateway for Containersの利用時は、NSGの全拒否ルールやUDRによる非対称ルーティングが障害原因になりやすいため、セキュリティポリシーだけでなくネットワーク経路も確認してください。(Microsoft Learn)

性能と機能制限も導入判断に含める

CiliumのL7制御では、対象通信がEnvoyを経由するため、L3／L4だけの制御より処理負荷とレイテンシーが増えます。Microsoftのドキュメントでは、毎秒3,000リクエストを超える規模で性能低下が目立つ可能性が示されています。これは一律の上限ではなく、負荷試験を開始すべき目安として扱うのが適切です。(Microsoft Learn)

また、Ciliumの展開や更新中に既存セッションが終了する場合があります。クライアント、API Gateway、アプリケーションのいずれかに、タイムアウト、再試行、冪等性の設計が必要です。

ACNSのL7ポリシーには、次の制約があります。

  • CiliumClusterwideNetworkPolicyではL7ルールを利用できない
  • Istioマネージドアドオンなど、別のL7実装との併用に制約がある
  • Linuxノードが対象であり、Windowsワークロードを同じ方式で保護できない
  • L7制御を適用する通信量に応じて、ノード上のCPUやメモリ使用量が増える
  • ポリシー更新やCilium展開時の接続断を考慮する必要がある

WAFについても、Application Gateway for ContainersではDRS 2.1が利用され、従来のCRSや一部の機能とは対応状況が異なります。HTTP DDoSルールセットは現時点でサポートされていないため、WAFだけをDDoS対策として扱うことはできません。カスタムルールで利用できる変数やカスタムブロック応答にも制限があります。(Microsoft Learn)

コストは四つに分けて見積もる

導入コストは、Application Gateway for Containersの料金だけでは判断できません。

  • Application Gateway for Containers本体、Frontend、Association、Capacity Unit
  • WAFを有効化した場合の追加料金と処理量
  • Advanced Container Networking Servicesの料金
  • Azure Monitor、Log Analytics、Managed Prometheus、Grafanaなどの監視・保存料金

Application Gateway for Containersは、リソース、Frontend、Association、Capacity Unitなど複数のメーターで課金されます。WAFの利用は単価と処理量に影響します。ACNSも有料サービスであり、ログをLog Analyticsへ大量に送る場合は取り込み量と保持期間の費用が加わります。(Microsoft Learn)

PoCでは、次の数値を計測してから本番費用を試算してください。

  • FrontendとAssociationの数
  • 通常時とピーク時のリクエスト数
  • WAFで検査する通信量
  • L7ポリシー対象となるPodと通信量
  • 1日あたりのログ生成量
  • ログの保持日数
  • GrafanaやPrometheusで保持するメトリクス数

対応要否を判断するチェックリスト

確認事項判断
Application Gateway for Containersの対応リージョンを利用できる次の条件確認へ進む
Japan East／West内での処理が必須現時点では本番採用を保留し、代替構成を検討する
インターネット公開のHTTP／HTTPS／gRPC APIがあるWAFとCilium L7の組み合わせを優先的に検討する
Pod間の横移動や不要なAPI操作を防ぎたいCilium L7ポリシーの効果が高い
Azure CNI Powered by CiliumとLinuxノードを利用しているACNS L7を比較的導入しやすい
Windowsワークロードが中心適用範囲が限定されるため別方式を検討する
Istioなどで既にL7認可を実装している重複導入せず、既存方式との役割分担を再設計する
毎秒数千件以上の高負荷APIがある本番相当の負荷試験を必須とする
GatewayやNetworkPolicyを誰でも変更できる導入前にRBACとGitOpsの変更経路を整備する
ログの保存先と保持期間が決まっていないデータ境界と監視コストを先に決める

次の条件がそろっている場合は、対応優先度が高いと判断できます。

  • 対応リージョンを利用できる
  • 外部公開APIまたは複数テナント向けサービスを運用している
  • LinuxとCiliumを採用している
  • WAFだけではPod間の横移動を防げない
  • Gateway APIとGitOpsを運用できる
  • 負荷試験とログ設計を実施できる

反対に、国内リージョン限定、Windows中心、既存のIstio認可を全面利用、高負荷かつ超低遅延が必須といった環境では、現時点での全面導入を急ぐ必要はありません。

安全に導入するための進め方

  1. リージョンとデータ境界を確認する
    Application Gateway for Containersを配置できるリージョン、TLS終端場所、ログ保存先、監査要件を整理します。
  2. 現在の通信を可視化する
    Pod間通信、外部API、DNS、監視、ヘルスチェックなど、正常動作に必要な通信を洗い出します。
  3. 非本番クラスタでアドオンを有効化する
    Workload Identity、Gateway API、Application Load Balancer、Cilium、ACNS L7の前提条件を確認します。
  4. 一つのサービスだけを対象にする
    まずは公開範囲と依存関係が明確なAPIを選び、Gateway、HTTPRoute、WAF、CiliumNetworkPolicyを設定します。
  5. 許可と拒否のテストを実施する
    正常なGET、攻撃文字列を含むGET、不正なPOST、未許可Pod、未許可の外向き通信をそれぞれ確認します。
  6. 性能を測定する
    L7ポリシー適用前後のレイテンシー、CPU、メモリ、エラー率、最大スループットを比較します。
  7. 監視対象を限定してログを保存する
    最初は拒否通信と重要名前空間を中心に取得し、必要性を確認してから対象を広げます。
  8. 名前空間単位で段階的に展開する
    全クラスタへ一度に適用せず、ロールバック手順と例外申請の期限を決めたうえで拡大します。

今回の公式情報によって、AKSのL7保護は「入口のWAF」だけでも「クラスタ内のNetworkPolicy」だけでも不十分であり、複数の境界を連携させる必要があることが明確になりました。

最初に行うべきことは、Application Gateway for Containersの対応リージョンと自社のデータ処理要件を照合することです。条件を満たす場合は、一つの名前空間と一つのAPIを対象にPoCを行い、WAFによる攻撃検知、Ciliumによる不正操作の拒否、Pod間通信、外向き通信、性能、ログ量を確認してください。条件を満たさない場合は、導入を急がず、現行構成で不足している防御層を特定することが次の行動になります。

Azure
WAF Azure Kubernetes Service Cilium Advanced Container Networking Services Application Gateway for Containers

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次