GKE 1.36 で GCPAuthzPolicy が Preview — 認可をアプリから Gateway へ剥がすゼロトラスト構成

はじめに

GKE のリリースノートに、8 月 26 日付けで短い一文が入った。

In GKE version 1.36 and later, GCPAuthzPolicy and GCPAuthzExtension resources for GKE Gateway are now available in Preview. You can use these resources to enforce identity-based access control and zero-trust authorization on incoming traffic at the Gateway layer.

一行で流れていく類の告知だが、これは GKE Gateway でできることの境界を動かしている。これまで GKE Gateway に載せられたセキュリティ機構は、TLS 終端、SSL ポリシー、Cloud Armor、そして IAP だった。いずれも「誰からのリクエストか」を細かく見て「このパスのこのメソッドだけ通す」を書くための道具ではない。その粒度の判断は、これまでアプリケーション側のミドルウェアが持っていた。

この記事では、(1) GCPAuthzPolicy が実際に何を書けるリソースなのか、(2) 既存の Cloud Armor / IAP とどう住み分けるのか、(3) GCPAuthzExtension で外部エンジンに投げる構成はどこで効くのか、を順に整理する。あわせて 8 月 31 日に GA になった GCPTrafficDistributionPolicy のセッションアフィニティにも触れる。

何が Preview になったのか

まず事実関係を並べる。

GCPAuthzPolicy / GCPAuthzExtension: 2026 年 8 月 26 日、GKE 1.36 以降で Preview
対象: GKE Gateway に入ってくるトラフィック（north-south）
GCPTrafficDistributionPolicy のセッションアフィニティ: 2026 年 8 月 31 日に GA。対応 GatewayClass は gke-l7-rilb、gke-l7-regional-external-managed、gke-l7-global-external-managed の 3 つで、シングルクラスタ構成のみ
1.36 の位置づけ: 9 月 2 日に 1.36.3-gke.1767000 が Rapid チャネルのクラスタ作成デフォルトになっている

名前から誤解しやすいので先に押さえておくと、GCPAuthzPolicy という CRD 自体は新しくない。Cloud Service Mesh 側で、メッシュ内（east-west）のワークロード間認可を書くためのリソースとしてすでに存在していた。今回入ったのは、同じリソースを GKE Gateway に targetRef で貼れるようになったという拡張だ。つまり「メッシュ内の呼び出しに書けていた認可ルールを、外部からの流入トラフィックにも同じ書き方で適用できる」という統一が起きている。

Gateway 側のポリシー体系は、これまで役割ごとに CRD が分かれていた。GCPGatewayPolicy が Gateway 自体（SSL ポリシー、グローバルアクセス、リージョン）、GCPBackendPolicy が Service（Cloud Armor、IAP、タイムアウト、ロギング）、HealthCheckPolicy がヘルスチェック、といった具合だ。GCPAuthzPolicy はこの並びに「認可」という列を足したことになる。

GCPAuthzPolicy に何が書けるか

CRD の定義を読むと、書ける内容はかなり具体的だ。グループは networking.gke.io、スコープは Namespaced。

targetRefs は最大 10 件、空は不可。group / kind / name で対象を指す。

action は ALLOW / DENY / CUSTOM の 3 値で、デフォルトは ALLOW。

httpRules は最大 10 件の配列で、中身は 3 つのブロックに分かれる。

from（および notSources） — リクエスト元。証明書から取れるピア ID（principals、最大 10）と、クライアント VM のプロパティ（IAM サービスアカウント、リソースタグ値）を指定できる
to（および notOperations） — 許可する操作。HTTP メソッド、URI パス（文字列マッチ条件つき）、ホスト、ヘッダのキーと値（最大 10）
when — CEL 式の文字列。1〜512 文字

構造として重要なのは、この 3 ブロックが「誰が」「何に対して」「どういう条件で」に素直に対応していることだ。よくある認可ミドルウェアの実装で、ルートの登録と認可の判定が別ファイルに散らばって全体像が読めなくなる、という問題がある。ここでは Kubernetes リソース 1 枚に閉じている。

評価順も明示されている。ロードバランサ側の認可ポリシーとしては CUSTOM → DENY → ALLOW の順で評価され、DENY にマッチしたリクエストは ALLOW ルールの内容に関係なく拒否される。deny が allow より先、というのは認可ポリシーとしては期待どおりの挙動だが、明文化されているかどうかで運用の安心感が変わる部分でもある。

identity として認識できるものは、mTLS 証明書の URI SAN / DNS Name SAN / Common Name、それに（内部 Application Load Balancer 限定で）サービスアカウントとセキュアタグだ。「内部 ALB 限定」という但し書きは設計時に効いてくる。外部公開の Gateway で「呼び出し元 GCE インスタンスのサービスアカウント」を条件にした認可を書こうとすると、ここで詰まる。

Cloud Armor / IAP との住み分け

「Gateway で認可」と言ったとき、GKE にはすでに 2 つの答えがあった。混ざりやすいので分けておく。

Cloud Armor は WAF と DDoS 防御であって、認可ではない。IP レンジ、地理情報、リクエストのシグネチャで「怪しいものを弾く」。誰であるかを確かめてから通す仕組みではない。GCPBackendPolicy 経由で Service に貼る。

IAP は認証と認可の両方をやるが、その単位は基本的に「この Service にアクセスしてよい Google アカウント / グループか」だ。パスとメソッドの組み合わせで細かく分けたい場合、IAP の外側に自前のロジックが必要になる。これも GCPBackendPolicy 経由。

GCPAuthzPolicy が埋めているのはこの間だ。identity を確かめたうえで、GET /api/v1/reports は通すが DELETE /api/v1/reports/* は特定の principal だけ、といったルールを Gateway で書ける。これまでアプリケーションのミドルウェアに書いていた層が、そのままインフラ側に移せる。

そして GCPAuthzPolicy の action: CUSTOM が、IAP との関係を面白くしている。CUSTOM を指定すると customProviders が必須になり、そこに Cloud IAP への委譲か、extension への参照（最大 2）を書く。つまり IAP は GCPAuthzPolicy に置き換えられるのではなく、GCPAuthzPolicy から呼び出せる委譲先の 1 つとして再配置されている。既存の IAP 構成を捨てずに、その前後に細かいルールを足せるということだ。

なお IAP には「Cloud CDN と併用できない」という制約が従来からある。認可を Gateway に寄せる設計を検討するとき、CDN を使う経路と使わない経路でどこまで統一できるかは事前に確認しておいた方がいい。

GCPAuthzExtension — 判断そのものを外に出す

もう一方の GCPAuthzExtension は、認可の判断自体を外部サービスに投げるための口だ。裏側は Google Cloud の Service Extensions で、ロードバランサはリクエストヘッダを拡張先に転送し、返答に応じてバックエンドへ通すか拒否するかを決める。

プロトコルは Envoy の ext_proc に加えて ext_authz gRPC API に対応している。これは実務上けっこう大きい。ext_authz は Envoy / Istio 圏で標準的に使われてきたインターフェースで、OPA（Open Policy Agent）をはじめとする既存の認可エンジンがすでに喋る。自前で認可サーバを持っている場合も、Envoy 用に書いたものがあれば流用が効く。

制約もはっきりしている。REQUEST_AUTHZ プロファイルの認可拡張が受け取って評価できるのは HTTP リクエストヘッダのみで、ボディは見ない。そして 1 つの転送ルールにアタッチできる認可拡張は 1 つだけ。ヘッダだけで判断が閉じない認可（リクエストボディの中身で権限が変わるようなもの）は、この層では扱えない。

ちなみに Cloud Load Balancing の認可ポリシーには CONTENT_AUTHZ というプロファイルもあり、こちらはペイロードを深く見てプロンプトインジェクションやデータ漏洩を止める用途で、CUSTOM アクション専用になっている。LLM を後ろに置く構成を意識した並びだが、GKE Gateway の Preview 告知が触れているのは identity ベースの認可の方だ。

エンジニアへの影響

実務でどう効くかを 3 点に絞る。

1. 認可コードの置き場所が選べるようになる。 これまで「認証は Gateway、認可はアプリ」で切らざるを得なかった構成に、もう 1 つ選択肢が増えた。特に、複数言語のサービスが同じ Gateway の後ろに並んでいる場合、各言語で認可ミドルウェアを実装・保守するコストがそのまま消える。ポリシーが YAML 1 枚に集まるので、レビューの対象も明確になる。

2. 監査のしやすさが変わる。 「このエンドポイントに誰がアクセスできるか」を答えるために各サービスのコードを読み回る必要がなくなり、kubectl get gcpauthzpolicy で済む。逆に言えば、ポリシーが Gateway 側にしかない状態で誰かが Service に直接到達できる経路を作ってしまうと、その経路は素通しになる。Gateway 経由以外の到達経路を潰しておくことが前提条件になる。

3. Preview であることの重み。 GKE 1.36 以降・Preview という段階なので、本番の認可判断をこれ 1 本に寄せるのは早い。現実的な進め方は、既存のアプリ側認可を残したまま GCPAuthzPolicy を DENY ルールから入れることだ。DENY は ALLOW より先に評価されるので、「明らかに通してはいけないもの」だけを Gateway で落とし、それ以外は従来どおりアプリで判断する。この形なら Preview の挙動が期待と違っても、フェイルオープンにはならない。

同時に GA になった GCPTrafficDistributionPolicy のセッションアフィニティも、認可とセットで見ると意味がある。認可を Gateway に寄せると、Gateway が持つ状態（誰と判定したか）とバックエンドの振り分けが噛み合っているかが問題になる。対応 GatewayClass が 3 つ・シングルクラスタ限定という制約は、そのまま「この構成なら足並みが揃う」という範囲を示している。

まとめ

GKE 1.36 以降で GCPAuthzPolicy / GCPAuthzExtension が Preview になり、GKE Gateway の流入トラフィックに identity ベースの認可を書けるようになった
GCPAuthzPolicy は Cloud Service Mesh 側にあった CRD の適用先が Gateway に広がったもので、from / to / when（CEL）で「誰が」「何に」「どんな条件で」を 1 リソースに書ける。評価順は CUSTOM → DENY → ALLOW
Cloud Armor（WAF）でも IAP（アカウント単位の認証認可）でもない、パスとメソッドの粒度の認可を埋める。IAP は action: CUSTOM の委譲先として組み込める
GCPAuthzExtension は ext_authz に対応しているため、OPA など Envoy 圏の既存認可エンジンをそのまま持ち込める。ただしヘッダのみ・転送ルールあたり 1 つ
Preview 段階では DENY ルールから段階導入するのが安全。認可を Gateway に寄せる前に、Gateway を迂回してバックエンドへ届く経路がないことを確認しておく

認可をアプリケーションから剥がす動き自体は、サービスメッシュが長くやってきたことだ。今回の変更は、それを東西方向だけでなく南北方向にも、同じリソースの書き方で持ち込めるようにした。GA を待つ間に、自分のクラスタで「Gateway を経由しない到達経路」がどれだけあるかを棚卸ししておくと、移行のときに慌てずに済む。

今日のその他のニュース

Firebase CLI v15.26.0 で 2 段階の非対話ログインが追加。 あわせて AI エージェントのサポートも入った。非対話ログインは CI から Firebase を叩く構成で効いてくる部分で、これまでトークンの取り回しに悩んでいたパイプラインの選択肢が増える。Firebase SDK for Flutter も v4.19.0 に更新された。

Google Cloud CLI が同梱 Python を 3.14.6 に更新。 CVE-2026-34182 への対応で、Windows / Linux の両方が対象。gcloud を CI イメージに焼き込んでいる場合、イメージの再ビルドが必要になる。

Asahi Linux が Apple M3 Mac を公式サポート。 ただし制約付きでの対応。M1 / M2 からの移植がどこまで進んだかは、これから触る人のレポート待ちという状況。