Cloud Run の Ingress と IAM — 通信経路に合わせて入口を閉じる
Cloud Run の公開範囲は Ingress、呼び出せる主体は IAM が担う。ブラウザ・ロードバランサ・Cloud Run間で経路を分けると、設定の理由が見える。
TL;DR
- ブラウザからの入口は GCLB 経由にし、Cloud Run は内部 + LB を許可する。
- サービス間は IAM 認証を使い、必要なら Direct VPC Egress で内部だけに閉じる。
- 「Ingress だけ」「IAM だけ」ではなく、経路と主体の二面で設計する。
012つの鍵 — Ingress と IAM
Ingress はどの経路から到達できるか、IAM は誰が起動できるかを決める。両方を使うことで、意図しないネットワーク経路と呼び出し主体を別々に絞れる。
IngressとIAMは別の問いに答える
- Ingress：到達できる経路 — ネットワーク入口を絞る
- IAM：呼び出せる主体 — サービスアカウントで認可
- アプリ認証：エンドユーザー — JWT/IAPなどを使う
02梅・竹・松の構成
LB直結は単純、BFFを挟むと内部サービスは IAM で守れる。VPC経由まで行うと、内部サービスの Ingress を内部に絞れるが設定と運用は増える。
構成は必要な強さで選ぶ
- 梅：LB直結 — 構成を単純に保つ
- 竹：BFF + IAM — 内部サービスを主体で守る
- 松：Direct VPC Egress + IAM — 経路も内部に閉じる
03設計チェックリスト
ブラウザ→LB→BFF、BFF→サービス、サービス→DB を別々に描く。各矢印について、発信者・到達先・経路・認証・失敗時を確認して設定へ落とす。
通信矢印ごとに決める
- ブラウザ→LB：外部経路 — アプリ/IAPで利用者認証
- BFF→サービス：サービス間 — IAM認証
- サービス→DB：VPC経路 — DBの認証と権限
結論
- 外部アクセスは LB に集約し、サービス本体へ直接届く経路を減らす。
- Cloud Run間はサービスアカウント + IAM を基本にする。
- より強い閉域性が必要になった段階で Direct VPC Egress を追加する。