技術共有資料

Workload Identity Federation

GitHub Actions から Google Cloud への安全な認証

何をしたか

GitHub Actions を使用して、Cloud Run への自動デプロイを構築しました。 認証方式として Workload Identity Federation（WIF） を採用し、 サービスアカウントキーを使用しない安全な CI/CD パイプラインを実現しています。

トリガー

master ブランチへの push で自動デプロイ

コンテナ

Docker イメージをビルドして Artifact Registry に保存

デプロイ

Cloud Run にデプロイして公開

デプロイの仕組み（全体像）

CI/CD パイプライン フロー

Push to master

GitHub Actions 起動

WIF 認証

Docker ビルド

Cloud Run デプロイ

Step 1 コードの取得

リポジトリのソースコードをチェックアウト

Step 2 Google Cloud 認証（WIF）

Workload Identity Federation を使用して一時的な認証トークンを取得

Step 3 Docker イメージのビルド

Next.js アプリケーションをコンテナ化し、Artifact Registry にプッシュ

Step 4 Cloud Run へデプロイ

新しいイメージでサービスを更新し、公開 URL でアクセス可能に

Workload Identity Federation とは

一言でいうと

外部のID（GitHub Actions）を Google Cloud が信頼して、 サービスアカウントキー無しで認証できる仕組み

技術的な仕組み

WIF 認証フロー

GitHub Actions
  1. 1 ワークフロー実行時に OIDC トークンを発行
  2. 2 トークンにはリポジトリ情報等が含まれる
OIDC Token
Google Cloud
  1. 3 トークンの発行元（GitHub）を検証
  2. 4 属性条件（リポジトリ名等）をチェック
  3. 5 条件を満たせばサービスアカウントとして認証

WIF の構成要素

Workload Identity Pool

外部 ID を管理するためのコンテナ。複数のプロバイダを含めることができる。

github-pool
Workload Identity Provider

外部 ID プロバイダ（GitHub）との接続設定。OIDC 発行元 URL を指定。

github-provider
属性マッピング

外部トークンの属性を Google Cloud 側の属性に変換するルール。

assertion.repository → attribute.repository
属性条件

認証を許可する条件。特定リポジトリからのみ許可するなど。

assertion.repository == "hoge/hoge"

設定例

Workload Identity Provider（GitHub Secrets: WIF_PROVIDER）
projects/123456789012/locations/global/workloadIdentityPools/github-pool/providers/github-provider
Service Account（GitHub Secrets: WIF_SERVICE_ACCOUNT）
github-actions@your-project-id.iam.gserviceaccount.com
GitHub Actions での認証ステップ 
- name: Authenticate to Google Cloud
  uses: google-github-actions/auth@v2
  with:
    workload_identity_provider: ${{ secrets.WIF_PROVIDER }}
    service_account: ${{ secrets.WIF_SERVICE_ACCOUNT }}

サービスアカウントキーとの比較

従来の方法：サービスアカウントキー（JSON キー）

仕組み

  1. 1. GCP コンソールでサービスアカウントキー（JSON）を発行
  2. 2. JSON ファイルを GitHub Secrets に保存
  3. 3. ワークフローでキーを使って認証

問題点

  • 有効期限がない - 漏洩時の被害が長期化
  • 管理が煩雑 - ローテーション作業が必要
  • 漏洩リスク - ログ出力やコード混入の危険
  • 監査が困難 - 誰がいつ使ったか追跡しにくい 
# 従来の方法（非推奨）
- name: Authenticate to Google Cloud
  uses: google-github-actions/auth@v2
  with:
    credentials_json: ${{ secrets.GCP_SA_KEY }}  # JSON キーを直接使用

推奨の方法：Workload Identity Federation

仕組み

  1. 1. GitHub が発行する OIDC トークンを使用
  2. 2. Google Cloud が GitHub を信頼する設定
  3. 3. 一時的な認証トークンで操作

メリット

  • キーレス - 秘密鍵の管理が不要
  • 短命トークン - 漏洩しても被害が限定的
  • 細かい制御 - リポジトリ・ブランチ単位で制限可能
  • 監査が容易 - Cloud Audit Logs で追跡可能 
# 推奨の方法（WIF）
- name: Authenticate to Google Cloud
  uses: google-github-actions/auth@v2
  with:
    workload_identity_provider: ${{ secrets.WIF_PROVIDER }}
    service_account: ${{ secrets.WIF_SERVICE_ACCOUNT }}

比較まとめ

観点 サービスアカウントキー Workload Identity Federation
認証情報 JSON ファイル（永続的） 一時トークン（数分〜1時間）
セキュリティリスク 高い 低い
ローテーション 手動で定期的に必要 不要（自動で新規発行）
アクセス制御 サービスアカウント単位 リポジトリ/ブランチ単位
漏洩時の影響 無効化するまで悪用可能 トークン期限切れで自動失効
セットアップの複雑さ 簡単 やや複雑（初回のみ）
Google 推奨 非推奨 推奨

まとめ

今回実現したこと

  • GitHub Actions から Cloud Run への自動デプロイ
  • Workload Identity Federation による安全な認証
  • サービスアカウントキーの管理が不要に
  • リポジトリ単位でのアクセス制御

ポイント

  • WIF は 一度設定すれば継続的に使える
  • キーのローテーション作業が 完全に不要
  • Google が 公式に推奨 している方式
  • AWS、Azure など 他クラウドでも同様の仕組み あり

参考リンク