データエンジニアとして CI/CD・IaC・CloudRun・Composer を組み合わせたデータ基盤を構築していると、認証方式の理解は避けて通れません。整理して「どのような順番で理解すればよいか」までを整理してみました。
個人的なメモです。
1. 基本的な認証の大きな2つの流派
(A) シークレットベース認証
-
例: クライアントID/クライアントシークレット、APIキー、アクセスキー/シークレットキー (AWS IAM のペア)
-
特徴
- 固定文字列（パスワードのようなもの）を相手に渡して認証する。
- 長期間有効にできるが、漏洩リスクが高い。
- CI/CD の GitHub Actions で「シークレットに埋め込む」形でよく使われる。
-
GCPの場合
- サービスアカウント（SA）の 鍵ファイル（JSON） を渡して認証するやり方がこの方式に近い。
(B) OIDC (OpenID Connect) & フェデレーション認証
-
例: GitHub Actions → GCP Workload Identity Federation (WIF)、Auth0 → GCP / AWS / Azure
-
特徴
- トークンベースで「短命な認証情報」を発行する。
- GitHub が「自分は GitHub Actions 上で走っているよ」という OIDC トークンを発行 → GCP 側の WIF が検証 → 一時的な SA 権限を付与。
- シークレット管理が不要（鍵ファイルを置かない）。
-
GCPの場合
- Workload Identity Federation (WIF) を使うと、GitHub と GCP を直接 OIDC 連携できる。
- 結果として 短命 SA 権限を払い出す。
2. 関連ワードの整理
-
サービスアカウント (SA)
- GCPリソースにアクセスする「仮想ユーザー」。
- 実体は IAM Identity。
- 認証方式は「鍵ファイルを発行して使う」か「WIF/OIDC経由で一時的に使う」。
-
Auth0
- ID プロバイダ（IdP）の一つ。OIDC や OAuth2.0 の仕組みで外部サービスとつなぐ。
-
リフレッシュトークン
- アクセストークンが短命（数分〜数時間）なので、長期的なセッションを維持するために再発行できるトークン。
- Webアプリやユーザー認証でよく使う。
- CI/CD のマシン間認証ではあまり使わない（短命トークンの再発行は OIDC/WIF に任せる）。
-
シークレットID / クライアントID・シークレット
- OAuth2.0 のクライアント認証に使う固定キー。
- GitHub Actions の
secrets.GCP_SA_KEYに JSON を突っ込むのがこのやり方。
3. GitHub × Terraform × CloudRun × Composer での位置づけ
-
昔のやり方（シークレット方式）
- GitHub Secrets に GCP サービスアカウント鍵（JSON）を保存
- Actions で
gcloud auth activate-service-accountしてデプロイ - 問題: 鍵が漏れると権限悪用される、管理が大変
-
今の推奨（OIDC + WIF）
- GitHub → OIDC トークンを発行
- GCP Workload Identity Federation が受け取って SA に一時認証
- 鍵管理が不要、セキュリティが高い
-
CloudRun / Composer 側
- 実行環境に「どの SA で動くか」を設定する。
- その SA に最低限の IAM 権限をアタッチしておく。
- （ここで使う SA は「アプリ用」なので、CI/CD 用 SA とは分けるのがベストプラクティス）
4. 学習の順序（おすすめの段取り）
-
サービスアカウント (SA) の概念を理解
- 人間ユーザーと違う「マシン用アカウント」。
- どの GCP リソースでも「この SA として動く」が基本。
-
シークレット方式（SA鍵ファイル）の仕組みを理解
- GitHub Secrets に JSON を保存して使う方法を試す。
- 「なぜこれが危険なのか」を体感。
-
OIDC & WIF を理解・導入
- GitHub Actions → GCP にシークレットなしでデプロイできるように設定する。
- GCP 側の
workload_identity_poolとworkload_identity_providerを Terraform で作る。
-
リフレッシュトークン・Auth0 などのユーザー認証シナリオを理解
- データエンジニア的には BtoC アプリ連携や SaaS API 利用で出てくる。
- 基盤設計では SA & WIF が中心。
5. 要約（質問に対する回答）
- OIDC と シークレットアクセスキーは、大きく2種類の認証方式として整理してOK。
- サービスアカウントは「権限を持つ主体」であり、認証方式は鍵ファイル方式（シークレット）か OIDC/WIF（フェデレーション）。
- CI/CD（GitHub Actions → GCP）の場合、推奨は OIDC + WIF。
- CloudRun や Composer は「どの SA で動くか」を指定する。
- 段取りとしては SA理解 → 鍵方式 → OIDC/WIF → ユーザー系認証（Auth0, リフレッシュトークン） の順で学ぶのがベスト。
シーケンス図
「GitHub Actions → GCP OIDC/WIF 認証」
GitHub Actions → GCP（シークレット／SA鍵ファイル方式）
要点
- 固定の秘密（SA鍵JSON） を GitHub Secrets に格納し、ワークフロー実行時に取り出して認証。
- 秘密管理・ローテーション・失効のオペレーション負荷／漏洩リスクがある。
- OIDC/WIF と違い、GCP側で“信頼できる外部発行者”の検証はなく、鍵の所持＝権限行使が可能。
OIDC/WIF vs シークレット（SA鍵）— 実務観点の比較
| 観点 | OIDC/WIF（推奨） | シークレット（SA鍵JSON） |
|---|---|---|
| 認証情報の形 | 短命のIDトークン→一時クレデンシャル | 長期の秘密鍵（JSON） |
| 秘密の保管 | 不要（鍵レス） | 必要（GitHub Secrets等に保存） |
| 漏洩時の影響 | 影響限定（短命＋発行元検証・属性制約） | 影響大（失効まで恒常的に悪用可能） |
| スコープ制御 |
attribute.repository/workflow/ref 等で厳格に制約
|
IAM/ロールのみ。発行先の絞り込みは困難 |
| 監査性 | “どのリポ/ワークフローから来たか”を属性で判断しやすい | 秘密鍵の使用主体特定が難しい |
| 運用負荷 | 低い（鍵ローテ不要） | 高い（鍵発行・配布・ローテ・失効） |
| 初期設定 | 若干手間（Pool/Provider/IAM条件） | シンプル（鍵を作って置く） |
| ベストプラクティス | こちら | レガシー互換/やむを得ない時のみ |
まとめ（設計判断の指針）
- 原則：CI/CD は OIDC/WIF（鍵レス） を第一候補。
- 例外：一部ツールや外部環境の制約で WIF が使えない時のみ、短命・限定用途のSA鍵を採用し、速やかな移行計画を持つ。
- ランタイム（Cloud Run/Composer）は、実行SA と CI用SA を分離し、最小権限＋監査しやすい命名とロールで統制。