データエンジニアとして 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 を分離し、最小権限＋監査しやすい命名とロールで統制。