こんにちは。Legalscape VPoTの小林です。
Legalscape ではCloud Runを第一選択として利用しており、 Kubernetes は利用していません。 ですが、self-hostedなサービスを構築する際に、 Helm chart が提供されており Kubernetes であれば比較的容易に導入できるという状況が何回か発生しました。
今回は、Cloud Run 上のサービスから GKE 上のサービスへ通信させたい、という場面を題材にZero Trustをどう設計するかを整理してみます。
Zero Trust の概要
Zero Trust は、NIST SP 800-207 の言い方を借りるなら、ネットワーク境界やネットワーク上の位置を信頼の主根拠にせず、リソースごと・リクエストごとにアクセスを評価する考え方です。実務上は「明示的な検証」「最小権限」「侵害前提」といった原則で説明されることも多いです。
Cloud Run → GKE の文脈に当てはめると、「VPC 内に閉じたから安全」とは言えない、ということになります。
なのでこの記事で考えたいのは、経路をどう用意するかではなく、Cloud Run からのリクエストを GKE 側でどう認証するかです。通信経路（Direct VPC Egress や内部ロードバランサーの選び方）は前提として最低限だけ触れますが、主眼ではありません。
前提：通信経路をどう用意するか
通信経路は後で出てくる認証方式が経路の選び方に依存するので、少しだけ紹介します。
Cloud Run 側：Direct VPC Egress
Cloud Run から VPC 内へ到達する手段は、今は Direct VPC Egress が第一候補です。Serverless VPC Access コネクタと違って間にプロキシ VM を挟まないので、設定がシンプルで、コネクタ用の専有サブネットや固定コストも要りません（コストもインスタンス同様ゼロまでスケールします）。
--vpc-egress=private-ranges-only # 内部IP宛のみ VPC 経由（デフォルト）
ひとつ実運用上の注意があって、Direct VPC Egress はインスタンス起動時にネットワーク確立まで1分前後の遅延が出ることがあります。HTTP startup probe で使うエンドポイントの中で egress 先への疎通確認を入れておくとよいです。こうしておくと VPC 確立待ちの間は probe がリトライし続け、疎通が通ってからトラフィックが流れます。
GKE 側：L4 パススルー NLB か、L7 内部 ALB か
GKE 側のサービスをどう公開するかで、Internal passthrough NLB（L4）と Internal ALB（L7, Gateway API）の二択になります。判断軸はシンプルで、L7 の機能（ALB でのフロントエンド mTLS や TLS 終端、パスベースルーティング）が要るかどうかです。
- L4 パススルー NLB: 速くてシンプル。TLS は Pod 自身が HTTPS を喋って初めてエンドツーエンドになります。
- L7 内部 ALB: ALB 層でのフロントエンド mTLS や TLS 終端が使えます。ただし
REGIONAL_MANAGED_PROXYの proxy-only サブネットが要ります。
この L4/L7 の選択が、次に見る認証方式（IAP が使えるか、mTLS をどこで終端するか）に影響してきます。
アクセス制御とチャネル認証：3つの選択肢
経路を用意したうえで、リクエストごとの ID 検証をどう実現するか。ここでは3つの選択肢を挙げます。
(A) アプリ層で OIDC IDトークンを検証する
Cloud Run のサービスアカウントで発行した OIDC IDトークン（audience を呼び先に固定）を Authorization ヘッダに載せて、GKE 側のアプリで検証します。
- 長所
- 追加インフラがほぼ不要。
- audience を呼び先に固定することで、トークンを別サービスに使い回すクロスサービスのリプレイを防げる。
- 短所
- 検証ロジックがアプリ側に乗る。
- これ単体では通信路の暗号化やサーバー認証は提供されない（後述の脅威モデルに直結します）。
(B) 内部 ALB + IAP
IAP（Identity-Aware Proxy）は、ALB の手前で ID 検証をやってくれる仕組みです。元々は人間がブラウザでアクセスする内部ツール向けの機能ですが、サービスアカウント署名 JWT を使えばサービス間通信にも利用できます。
- 長所:
- 認可を ALB 層に外出しでき、IAM で一元管理できる。
- 短所:
- L7 ALB が前提になる。
- GKEでIAPを設定することのハマりどころが多い。（これは今後別記事で紹介するかもしれません）
(C) Cloud Service Mesh による mTLS
SPIFFE ベースの ID と相互 TLS で、Bearer Tokenではなく証明書でピアを認証します。GKE 間（GKE-to-GKE）では Auto mTLS と Secure Naming が GA で使えて、Zero Trust のチャネルとしては第一選択となります。
ただし Cloud Run をクライアントにする経路には、現時点（2026年6月）で大きな制約があります。Cloud Run → GKE のルーティングは Public Preview で、Preview では非GKEワークロード（＝Cloud Run）から GKE への通信に Auto mTLS も Secure Naming も適用されません。つまりこの区間は平文で流れるので、GKE 側は PERMISSIVE の PeerAuthentication で受ける必要があります。
# Preview では Cloud Run からの平文も受けるため PERMISSIVE が必要 apiVersion: security.istio.io/v1 kind: PeerAuthentication metadata: { name: namespace-policy } spec: mtls: { mode: PERMISSIVE } # STRICT だと Cloud Run からの平文が弾かれる
よって、この方式は将来への期待は高いものの、現時点ではまだ Zero Trust としては不十分な状態です。
平文 HTTP + IDトークンは、何を守れていないのか
一番ありがちな構成、「L4 パススルー NLB + 平文 HTTP + OIDC IDトークン」を例に、何が守れていて何が守れていないかを分解してみます。脅威を3つのベクトルに分けて見ていきましょう。
ベクトル1：経路上の盗聴・パケット注入 Google Cloud の virtual network 内の private IP 通信はネットワーク層で暗号化・完全性保護され、盗聴に対する部分的な保険にはなります。
ベクトル2：サーバーなりすまし ここが平文 HTTP の最大の穴です。DNS ゾーンの侵害、NEG／バックエンドサービスへの不正なバックエンド登録、ファイアウォール／ルーティングの誤設定などで、クライアント（Cloud Run）が偽のサーバーに繋がされる可能性があります。平文 HTTP は*サーバー認証をまったく提供しないので、このベクトルは素通しです。
ベクトル3：Bearer Tokenのリプレイ ベクトル2が成立すると、ID Token はチャネルに束縛されていない資格情報なので、攻撃者が抜き取って正規のバックエンドにリプレイできてしまいます。「ID Tokenを付けてるから安全」は、サーバー認証の欠如とセットで考えると崩れる、というわけですね。
塞ぎ方
L4 パススルーを採用した場合は、Pod 自身が HTTPS を提供しないといけません。OSSのアプリケーションなどをそのままホスティングする場合には、実現不可能な可能性があります。
なお、L7 内部 ALB を採用してフロントエンド mTLS を有効にしても、保護されるのは Cloud Run から ALB までの区間です。LB→Pod 区間はデフォルトでは平文なので、この区間も保護したい場合は、BackendTLSPolicy による backend authenticated TLS を併せて検討します。 また、internal DNSを利用している場合には、certificate managerのDNS検証による証明書が利用できないことに留意が必要です。
まとめ
この記事の主題は「Cloud Run → GKE を Zero Trust で設計すること」でした。ネットワーク上の位置を信頼の根拠にせず、用途に応じた認証方式を選ぶ必要があります。 いくつか実現方式はありますが、銀の弾丸はなく、守りたいものと運用制約に応じて選択しましょう。
| 要件 | 推奨構成 |
|---|---|
| アプリを改修でき、インフラを複雑にしたくない | OIDC ID トークンをアプリで検証 + HTTPS |
| アプリを改修したくない / IAM で一元管理したい | 内部 ALB + IAP |
| Cloud Run → GKE でアプリ非改修、チャネル認証も必要 | 内部 ALB + frontend mTLS、必要に応じて BackendTLS |
さいごに
Legalscapeではエンジニア全方面で募集中です。SREに興味がある方、AIを用いた開発の効率化に興味がある方などなど、弊社に興味に湧いた方がいればぜひお気軽にご連絡ください
