Cloud Run でバッチ処理を構築する際、「どうやってセキュアに認証を通せばいいのか？」「ADC（Application Default Credentials）って具体的にどう動いているのか？」と気になったので調べてみました。
Cloud Run × Cloud Scheduler の認証・権限管理（ADC）
Cloud Run で ADC を使った認証の仕組みを利用すると、「キーファイルを持たない、よりセキュアな環境」の構築が可能になります。
全体構成
Cloud Scheduler から内部 Ingress の Cloud Run を呼び出し、さらに Storage や BigQuery を操作する一連のフローを、図解を使って整理しました。
呼び出し元の Cloud Scheduler、実行環境の Cloud Run、そして認証を司る Google Cloud インフラ の 3 つの境界に分けています。
通信シーケンス
認証情報（トークン）がどのように流れるか、時系列で整理してみました。
ポイントは、SDK（ADC内蔵）が一度取得したトークンをメモリ内で再利用する点です。
ADC（Application Default Credentials）
ADC を利用すると、開発者は「トークンの取得処理」を一切書く必要がありません。
- アプリケーションの役割: 「どのリソースに何をしたいか」というビジネスロジックに集中
- SDK/ADC の役割: 実行環境（メタデータサーバー）から自動で適切なトークンを拾い上げ、リクエストヘッダーにセット
セキュリティ設定の要所
この構成を安全に動かすための IAM 設定のポイントは以下の通りです。
- 呼び出し制限: Cloud Run の Ingress を「Internal」に設定し、外部からの直接アクセスを遮断
- Invoker 権限: Cloud Scheduler のサービスアカウントに、Cloud Run の roles/run.invoker を付与
- 最小権限の原則: Cloud Run に割り当てるサービスアカウントには、Storage の特定バケット（roles/storage.objectViewer）や BigQuery の特定データセットへの権限のみをピンポイントで付与
