Application Gateway for ContainersのJWT検証がプレビュー：AuthPolicyの継承と認可の責任分界を検証する

結論：入口のJWT検証とアプリの認可を別々の受入条件にする

【確認済み事実】Application Gateway for ContainersはAuthPolicyを使い、バックエンドへ送る前にJWTの署名、発行者、有効期間、設定したaudienceを検証できます。機能とAPIはプレビューです。ロールや権限、リソース所有者に基づく認可はアプリ側の責任として残ります。根拠は公式資料1・2です。

【編集上の判断】APIやMCPの入口へ共通の検証を置く設計は候補になります。採用時は、到達経路ごとに有効なポリシーを確定し、認証を通過するが対象操作は禁止される要求も試験します。対象製品はApplication Gateway for Containersであり、別製品のApplication Gateway向け設定をそのまま流用しない方針を提案します。

背景と技術的要因：ルート階層によって信頼境界が変わる

【確認済み事実】11月3日登録のAzure公式更新情報は、ApplicationLoadBalancer、Gateway、HTTPRoute、GRPCRoute、MCPRouteへのAuthPolicy適用を案内しています。より具体的なルートの設定は継承を置き換えられます。根拠は公式資料1です。

【編集上の設計案】複数チームが共有Gatewayを使う環境では、親側の設定だけを監査対象にすると、ルート変更で信頼境界が変わる点を見落とします。Gateway管理者とルート所有者の変更権限を棚卸しし、認証設定を変更できる権限そのものをレビュー対象にします。

【編集上の設計案】全ルートが同じ発行者・audienceを使う構成と、ルート別に異なる構成を分けて設計します。設定の集約を目的にせず、ルートの追加・削除・親の変更時にも必要な検証が継続することを完了条件とします。

公表・更新・適用日、対象リソースとバージョン

【日付の区別】公式資料1のロードマップ登録日は2026-11-03、プレビュー欄は2026年11月です。同告知の更新日と厳密な提供開始日は確認できずnullです。GA適用日、移行期限、非推奨化期日もnullです。公式資料2の表示更新日は2026-11-06、資料3・4は2026-11-03ですが、初回公表日とALB Controller 1.13.0の厳密なリリース日は確認できずnullとします。本稿の公開日・確認日は2026-11-10です。

【確認済み事実】公式資料3のAuthPolicy例はalb.networking.azure.io/v1alpha1を使います。公式資料4の最新Helmリリース表はALB Controller 1.13.0、Gateway API v1.6.2、最小Kubernetes v1.32と、JWT検証の追加を記載しています。これは全AKS環境への機能反映を示すものではありません。

【確認済み事実】公式資料4はAKSアドオンのコントローラー版を別表で管理しています。本稿は日本語の最新ページを直接確認して参照しています。sourcesのsourceDateは資料1で登録日、資料2〜4で表示更新日です。

【編集上の確認事項】HelmかAKSアドオンかを先に識別し、実稼働のコントローラー、Gateway API、CRDの版を採取します。クラスターバージョンだけからAuthPolicy対応を推定せず、対応する導入経路と実際の設定受理を検証します。

設計・実装上の確認事項：上書き、例外、Entra IDをIaCへ記録する

【確認済み事実】公式資料2・3は、ルート、Gateway、ApplicationLoadBalancerの順に優先し、設定はマージしないと説明しています。AuthPolicyと対象は同じnamespaceが必要で、個別listenerやルールをsectionNamesで指定できません。ルートのjwt: {}は明示的な公開例外であり、部分的に記述したJWT設定とは異なります。

【確認済み事実】公式資料3のEntra ID例は、APIアプリと呼出し元アプリを分け、api.requestedAccessTokenVersionを2に設定します。このv2.0アクセストークンのaudはAPIアプリのclient IDで、トークン要求のscopeに使うapi://から始まる値とは区別されています。

【編集上の実装案】IaCではtargetRef、namespace、issuer、audiences、jwks.remote.uriをレビュー可能な値として管理します。Entra IDでは実トークンのiss・audと設定値を照合し、client IDとAPIのApplication ID URIを取り違えない試験を追加します。Bearerトークンや資格情報はレビュー記録とログに残さない運用にします。

【編集上の実装案】Terraform・BicepでAzure側を作る工程と、Helm・Kubernetesマニフェストで認証を設定する工程を依存関係として記録します。CRD導入、対象ルート作成、AuthPolicy適用、状態確認、拒否試験の順で受け入れます。jwt: {}の追加、audienceの変更、targetRefの付替えを公開範囲の変更として審査します。

運用・監視・フェイルオーバーと責任分界の技術論点

【確認済み事実】公式資料2・3はAuthPolicyのAccepted・ResolvedRefs等の状態確認と、トークンなしの401、許可されないaudienceの403を説明しています。WAFとJWTが適用される通常の要求ではWAFが先です。OAuth Protected Resource Metadataの取得は別扱いで、公開されたscope情報だけでは認可は強制されません。

【確認済み事実】JWKSのホスト名はデータプレーンから名前解決・到達でき、HTTPS証明書の信頼も成立する必要があります。鍵の更新では、既存トークンが有効な間、新旧の公開鍵を重ねて掲載する計画が必要です。根拠は公式資料2です。

【編集上の監視案】Gateway、ルート、AuthPolicyの状態と、WAF拒否、JWT拒否、アプリ認可拒否を分けて記録します。HTTPコードだけでは拒否した層を断定せず、時刻・経路・相関用IDとバックエンド到達結果を照合します。401や403を下げるために認証設定を外す対応を、標準の復旧手順にはしません。

【編集上のDR設計案】別クラスター・リージョンへ復旧した際も、同じCRD・ポリシー・JWKSへの経路がそろうかを確認します。DNSやJWKS取得障害、鍵の切替、無効ポリシー、公開例外を検証環境で試験し、キャッシュに依存する停止時間や再開条件は実測します。必要な依存を満たさない際の公開停止と復旧の担当を決めます。

【編集上の責任分界案】基盤担当はGateway・CRD・適用状態、ID担当は発行者・鍵更新・アプリ登録、アプリ担当はroles・scope・所有者に基づく認可、運用担当は検知と切戻しを担う案を定めます。バックエンドを直接呼べる経路も棚卸しし、入口だけの検証に依存した認可漏れがないか試験します。

【適用上の前提】本稿は個別環境の設計保証や法的助言を行いません。実装適用にあたっては検証環境での事前テストおよび業務範囲の確認が必要です。プレビュー採用の条件を確認し、以下のチェックリストを環境ごとに具体化してください。