はじめに

GitHub ActionsからAWSへアクセスするとき、こう書くことがある。

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789012:role/my-role
    aws-region: ap-northeast-1

👉 アクセスキーがどこにもない。なぜこれでAWSにアクセスできるのか？

答えは OIDC認証 だ。

OIDCトークンで"一時アクセスキー"を発行する

❌ よくある誤解：「OIDCトークンをそのままAWS APIに渡している」

👉 実際は違う。OIDCトークン（JWT）は一時アクセスキーを発行するための証明書として使う。

最終的にAWSへのAPIアクセスに使うのはいつもの3つ：

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN

フローはこうなっている：

GitHub Actions
  1. GitHubからOIDCトークン（JWT）を取得
  2. AWS STS: AssumeRoleWithWebIdentity にJWTを渡す
  3. STSが一時キー（有効期限付き）を返す
     → AWS_ACCESS_KEY_ID
     → AWS_SECRET_ACCESS_KEY
     → AWS_SESSION_TOKEN
  4. その一時キーで通常通りAWS APIを叩く

永続的なアクセスキーをリポジトリやSecretsに置く必要がなくなる。

そのJWT、なぜ信頼できるの？

疑問が出てくる。

「AWSはそのJWTが"許可していいトークン"だとどうやって判断しているの？」

答え：公開鍵暗号（電子署名） でJWTの署名を検証しているから。

JWTの中には署名が入っている。GitHubが秘密鍵でサインしたもので、AWSは公開鍵を使って「本当にGitHubが発行したものか」を検証できる。

公開鍵暗号の2パターン

「公開鍵・秘密鍵」と聞くと混乱しやすいが、用途が2つある。

① 暗号化（encryption）

公開鍵 → lock（暗号化）
秘密鍵 → unlock（復号）

公開鍵で暗号化し、秘密鍵でしか復号できない
例：PGP暗号メール、HTTPSの鍵交換フェーズ（※実データはセッション鍵で対称暗号化）

② 電子署名（digital signature）

秘密鍵 → サイン（署名）
公開鍵 → 本物確認（検証）

秘密鍵を持つ人だけが署名できる
誰でも公開鍵で「この署名は本物か」を確認できる
例：JWTの署名、コード署名

👉 OIDCはこちら（電子署名）を使う

GitHubが秘密鍵でJWTに署名 → AWSが公開鍵で検証

鍵の配置は自分でやる必要がある？

秘密鍵・公開鍵そのものを自分で生成・配置する必要はない。GitHubとAWSがそれぞれ管理してくれる。

GitHubは自動的にOIDCトークンを発行し、公開鍵を Discovery エンドポイント（https://token.actions.githubusercontent.com/.well-known/openid-configuration）経由でJWKSとして公開している
AWSはそのDiscoveryから公開鍵セット（JWKS）を取得・キャッシュし、JWTの署名を検証する

ただし、以下の3つの設定は自分でやる必要がある：

AWS IAMにOIDC Providerを登録する（token.actions.githubusercontent.com をIDプロバイダーとして追加）
IAM RoleのTrust Policyを設定する（誰を信じるかの条件）
GitHub ActionsのワークフローにOIDCトークン取得の権限を付与する（後述）

自分で設定するのは主に 「誰を信じるか」 の部分だ。

IAM RoleのTrust Policyで指定する：

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
      "token.actions.githubusercontent.com:sub": "repo:myorg/my-app:ref:refs/heads/main"
    }
  }
}

条件の意味：

条件	意味
`Federated`	GitHubのOIDC Providerを信頼する
`aud`	トークンの宛先（受信者）が `sts.amazonaws.com` であること
`sub`	特定のリポジトリ・ブランチからのみ許可

👉 sub の条件がポイント。特定リポジトリ・ブランチ以外からはAssumeRoleできない。なお sub の形式はコンテキストによって変わる（PR: repo:ORG/REPO:pull_request、タグ: repo:ORG/REPO:ref:refs/tags/TAG、Environment: repo:ORG/REPO:environment:ENV）。

また、GitHub ActionsのワークフローにOIDCトークンを取得する権限が必要だ。

permissions:
  id-token: write   # OIDCトークンの取得に必要
  contents: read

👉 id-token: write が抜けると Error: Could not assume role で失敗する。

GitHubの機能？AWSの機能？

両方。 GitHubのOIDC機能 × AWSのOIDC Federation機能の掛け合わせ。

GitHub（IdP）
  「私はGitHubです」
  → OIDCトークン（JWT）を発行

        ↓

AWS（Relying Party）
  「GitHub発行か？」（公開鍵で署名検証）
  「repo合ってる？」（sub条件チェック）
  「aud合ってる？」（aud条件チェック）

        ↓

一時IAM Role払い出し
（AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY / AWS_SESSION_TOKEN）

GitHub：IdP（Identity Provider）。OIDCトークンを発行する側
AWS：Relying Party。OIDCトークンを受け取り検証する側

どちらが欠けても動かない。

OIDCが使える条件と対応サービス

前提：発行側（IdP）と受け入れ側（Relying Party）の両方がOIDCを話せること

どちらか一方だけでは成立しない。

IdP（OIDCトークンを発行できる）

サービス	用途
GitHub Actions	CI/CDパイプラインからクラウドへ
GitLab CI/CD	同上
Google（Google Identity / OIDC）	Googleアカウントでのログイン
Okta / Auth0	企業のIdP

Relying Party（OIDCトークンを検証・信頼できる）

サービス	仕組み
AWS	IAM OIDC Federation
GCP	Workload Identity Federation
Azure	Federated Identity Credentials
Kubernetes（EKS等）	Pod Identity / IRSA（SA TokenをIdPとしてAWSが信頼）

👉 Kubernetes はIdPとしてもRelying Partyとしても機能する（APIサーバーに --oidc-issuer-url を設定することで外部OIDCも受け入れ可能）。

👉 GitHub Actions × AWS の組み合わせは代表例の一つ。同じ仕組みで GitHub × GCP や GitHub × Azure も実現できる。

まとめ

疑問	答え
OIDCトークンでAWS APIを叩く？	❌ 一時アクセスキーを取得するために使う
AWSはなぜJWTを信頼できるの？	公開鍵で電子署名を検証しているから
秘密鍵・公開鍵を自分で設置する？	不要。GitHubとAWSが管理
GitHubの機能？AWSの機能？	両方。IdP × Relying Partyの掛け合わせ
他のサービスでも使える？	OIDCを話せるサービス同士なら使える