本番インフラを App Engine から Cloud Run・外部 HTTPS Load Balancer・Cloud Armor へ移行する際、デプロイ認証は運用の要になります。ここでは GitHub Actions から GCP へ、サービスアカウント鍵ファイルをリポジトリに置かずにデプロイする ための考え方を整理します。
なぜ長期鍵を避けるか
従来よくあるのは、GCP サービスアカウントの JSON 鍵を GitHub Secrets に保存し、gcloud auth activate-service-account で使う方法です。実装は単純ですが、鍵の漏洩リスクとローテーション負荷が残ります。
Workload Identity Federation（WIF）を使うと、GitHub OIDC トークンを GCP が信頼し、短命の認証情報 でデプロイできます。
構成の要点
- GCP: Workload Identity Pool と Provider を作成し、GitHub リポジトリ（
owner/repo）と ref（例:refs/heads/main）を条件にバインド - IAM: デプロイ用サービスアカウントに
roles/iam.workloadIdentityUserを Pool 経由で付与 - GitHub Actions:
permissions: id-token: writeを付け、google-github-actions/authで federated 認証 - デプロイ: 認証後に
gcloud run deployや Artifact Registry への push を実行
Terraform で Pool / Provider / SA バインディングをコード化すると、本番・ステージングで同じパターンを再利用しやすくなります。
Cloud Run 移行との接続
ユーザー向け・管理向けで Cloud Run サービスを分け、外部 LB でホストベース振り分けする構成では、CI もサービスごとにデプロイジョブを分けるのが安全です。DB migrate をデプロイ前に走らせる、Cloud Armor の IP 制限を本番切替前に検証する、といった運用手順は Actions の workflow 分割と相性が良いです。
まとめ
- 長期 JSON 鍵は避け、WIF + OIDC を第一候補にする
- リポジトリ・ブランチ条件を Provider に明示する
- インフラ（Terraform）と CI（GitHub Actions）を同じリポジトリで管理すると、移行プロジェクトの再現性が上がる
スターターキット
この記事で話した構成を、そのままデプロイして動かせる実装付きキットです。Rails アプリと Terraform・GitHub Actions が同梱され、デプロイすると Cloud SQL から外部 HTTPS LB・Cloud Armor まで GCP 上に立ち上がります。開発のスタートダッシュにご利用ください。