Cloud RunへデプロイするCI/CDでは、認証の設計が運用の安全性を左右します。この記事では、GitHub ActionsからGCPへサービスアカウント鍵ファイルを渡さずにデプロイする構成を説明します。
長期鍵ではなく短命の認証情報を使う
よくある方法は、GCPサービスアカウントのJSON鍵をGitHub Secretsへ保存し、gcloud auth activate-service-accountで読み込む構成です。実装は単純ですが、鍵が漏洩するリスクと、定期的に鍵を交換する運用負荷が残ります。
Workload Identity Federation（WIF）を使うと、GCPはGitHubのOIDCトークンを検証し、短時間だけ有効な認証情報を発行できます。長期鍵を保管・配布しなくてよい点が、JSON鍵を使う構成との違いです。
構成を4つに分けて考える
- 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で連携する - 認証後に
gcloud run deployやArtifact Registryへのpushを実行する
Pool、Provider、サービスアカウントのバインディングをTerraformでコード化すると、本番とステージングに同じ構成を適用できます。
Cloud Runの運用にどうつなげるか
ユーザー向けと管理向けでCloud Runサービスを分け、外部LBでホスト名に応じて振り分ける場合は、CIのデプロイジョブもサービスごとに分けると安全です。デプロイ前のDB migrateや、本番リリース前のCloud ArmorのIP制限の検証も、Actionsのworkflowごとに組み込めます。
認証情報を短時間だけ有効にし、利用条件を絞る
- 長期JSON鍵を避け、WIFとOIDCを第一候補にする
- Providerにリポジトリとブランチの条件を明示する
- TerraformとGitHub Actionsを同じリポジトリで管理し、環境構築を再現できる状態にする
スターターキット
この記事で説明した構成を、そのままデプロイして動かせる実装付きキットです。Railsアプリ、Terraform、GitHub Actionsを同梱しており、デプロイするとCloud SQLから外部HTTPS LB、Cloud ArmorまでをGCP上に構築できます。開発の初期構築に利用できます。