こんにちは！チームの開発体験を爆上げするために日夜コードと向き合っている、君の身近な先輩エンジニアです。
突然だけど、毎日のCI/CDパイプラインの設定で、こんなストレスを抱えていないかな？
- 「AWSのアクセスキーとシークレットキーをGitHubのSecretsに登録したはいいものの、90日ごとのローテーションを忘れてビルドが突然止まった…」
- 「退職したメンバーのキーがそのままIAMに残っていて、セキュリティ監査で冷や汗をかいた…」
- 「そもそも、シークレットの管理方法が属人化していて誰も全容を把握していない…」
これ、本当によくある現場の悲劇なんだよね。でも、安心して。今日紹介する「OpenID Connect（OIDC）」をマスターすれば、そんなパスワード管理の悪夢から完全に解放されるだけでなく、セキュリティレベルもプロフェッショナル水準に引き上げることができるんだ。
これをマスターすれば、毎日のデプロイ作業やパイプライン管理が劇的に楽になりますよ！さあ、一緒にパスワードレスな世界へ踏み出そう。
—
1. なぜ従来のIAMユーザーキー管理は危険なのか？
まずは、なぜ今までのやり方が「悪」なのか、その本質を理解しておこう。
これまで、GitHub ActionsからAWSのリソース（S3やLambda、EKSなど）を操作するためには、AWSの「IAMユーザー」を作り、その「アクセスキーID」と「シークレットアクセスキー」を発行して、GitHubの「Repository Secrets」に保存するのが定番だった。
しかし、これには致命的な3つの欠点がある。
1. 有効期限がない（または長い）: シークレットキーは基本的に自動では期限切れにならない。流出した場合、誰でも無限にAWSへアクセスできてしまう。
2. スコープの広さ: 一度発行したキーは、IAMユーザーに付与された権限の範囲内で「いつでも」「どこからでも」使えてしまう。GitHub Actions以外からの不正利用を防ぎづらい。
3. ローテーションの運用負荷: キーを定期的に手動（またはスクリプト）で再発行し、GitHub側も更新し直す必要がある。人間がやる以上、いつか必ずミスや事故が起きる。
救世主「OIDC（OpenID Connect）」とは何か？
OIDCは、一言で言うと「パスワード（シークレット）を一切持たない認証の仕組み」だよ。
イメージとしては、映画館の「入場チケット（一時的なトークン）」に似ている。
GitHub ActionsがAWSにアクセスするとき、こんなやり取りが行われるんだ。
1. GitHub：「私はGitHubのこのリポジトリの、このブランチで動いているビルドです。身分証として、GitHubが署名した身分証明書（JWTトークン）を発行しますね」
2. AWS：「どれどれ…おっ、確かにGitHub公式が発行した本物のトークンだね。じゃあ、あなたには今から1時間だけ有効な『一時的なAWSクレデンシャル』を特別にあげよう」
3. GitHub Actions：（一時クレデンシャルを使って安全にデプロイ実行！）
どう？これなら、リポジトリのどこにもパスワード（シークレットキー）を保存する必要がない。漏洩するリスクのある「永続的な秘密情報」自体が存在しないから、圧倒的に安全なんだよ。
—
2. 全体像の把握：AWSとGitHubの信頼関係を結ぶ
OIDCを使うためのステップは、大きく分けて以下の3つ。
1. AWS側で「IDプロバイダー（OIDCプロバイダー）」を設定する（GitHubを信用するよ、という登録）
2. AWS側で「IAMロール」を作成し、信頼関係（どのリポジトリからのアクセスを許可するか）を定義する
3. GitHub ActionsのワークフローからAWS公式のアクションを呼び出す
言葉だけ聞くと難しそうに感じるかもしれないけれど、一つひとつ優しく紐解いていくから安心してね。
—
3. ステップ・バイ・ステップ実装ガイド
それでは、実際に手を動かして設定していこう。今回は例として、GitHub ActionsからAWSのS3バケットにファイルをアップロードする簡単なパイプラインを想定するよ。
ステップ1：AWSにGitHubをOIDCプロバイダーとして登録する
まずはAWSマネジメントコンソールを開いて、「IAM（Identity and Access Management）」に移動しよう。
1. 左メニューの [アクセス管理] > [IDプロバイダー] をクリック。
2. [プロバイダーの追加] をクリック。
3. 以下のように設定する：
- プロバイダーのタイプ: `OpenID Connect`
- プロバイダーのURL: `https://token.actions.githubusercontent.com`
- サムプリント: [サムプリントを取得] ボタンを押して取得する（GitHubの証明書の指紋だよ）。
- 対象者 (Audience): `sts.amazonaws.com`
4. [プロバイダーを追加] を完了する。
これで、AWSは「`token.actions.githubusercontent.com` から来るトークンは、GitHubからのものとして話を聞こう」と認識してくれるようになったよ。
—
ステップ2：信頼関係を結んだ「IAMロール」を作成する
次に、GitHub ActionsがAWS上で「どの権限を持つか」を決めるIAMロールを作成する。ここが一番重要なセキュリティの肝だ。
1. IAMメニューの [ロール] > [ロールを作成] をクリック。
2. 信頼されたエンティティの種類で [Web アイデンティティ] を選択。
3. 以下のように選択・入力：
- アイデンティティプロバイダー: 先ほど作った `token.actions.githubusercontent.com` を選択。
- Audience: `sts.amazonaws.com`
- GitHubの組織とリポジトリ: 自社の環境に合わせて指定（例: `your-github-username/your-repo-name`）
4. [次へ] を進み、必要な権限（今回はS3にアクセスするので `AmazonS3FullAccess` やカスタムポリシーなど）をアタッチする。
5. ロール名（例: `my-github-actions-oidc-role`）をつけて作成完了！
💡 先輩エンジニアからの極意：条件分岐（StringLike）でセキュリティを強固にする
作成したIAMロールの「信頼ポリシー（Trust Policy）」をJSONで確認してみてほしい。デフォルトではリポジトリ全体を指定しているはずだけど、本番環境なら「mainブランチから実行されたときだけ」といった条件（Condition）を絞るのがプロの技だ。
{
“Version”: “2012-10-17”,
“Statement”: [
{
“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”
},
“StringLike”: {
“token.actions.githubusercontent.com:sub”: “repo:your-github-username/your-repo-name:ref:refs/heads/main”
}
}
}
]
}
この `StringLike` の設定により、「`your-repo-name` リポジトリの `main` ブランチ以外からのアクセスは、絶対にAWSのロールを貸与しない」という鉄壁のガードが完成するよ。これがパスワードレスの真骨頂だ。
—
ステップ3：GitHub Actionsワークフローを書く（HelloWorld）
いよいよ最後のステップ！GitHubリポジトリ側に、OIDCを使ってAWSに認証するワークフローファイル（`.github/workflows/deploy.yml`）を作成しよう。
AWS公式が提供している `aws-actions/configure-aws-credentials` という素晴らしいアクションを使えば、驚くほど簡単に一時クレデンシャルを取得できるんだ。
name: AWS OIDC Deploy HelloWorld
mainブランチへのプッシュをトリガーにする
on:
push:
branches:
- main
OIDCトークンを発行するために必要な権限（permissions）を必ず定義する
permissions:
id-token: write # OIDCトークンの取得に必須！
contents: read # リポジトリのコードをチェックアウトするのに必要
jobs:
deploy:
runs-on: ubuntu-latest
steps:
# 1. リポジトリのコードをチェックアウト
- name: Checkout code
uses: actions/checkout@v4
# 2. AWS公式アクションでOIDC認証（パスワード不要！）
- name: Authenticate to AWS via OIDC
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/my-github-actions-oidc-role # さっき作ったIAMロールのARN
aws-region: ap-northeast-1 # デプロイ先のリージョン
# 3. 認証が成功したか、AWS CLIで動作確認してみる
- name: Verify AWS Identity
run: |
echo “=== 認証成功！現在のAWSアイデンティティを確認します ===”
aws sts get-caller-identity
# （おまけ）S3バケットの一覧を取得してみる
- name: List S3 Buckets
run: |
aws s3 ls
ここで注目してほしいのが、`permissions` ブロックの `id-token: write` だ。これを書き忘れるとOIDCトークンが発行されずにエラーになるので、絶対に忘れないようにしよう。
—
4. 動作確認とまとめ
このファイルをリポジトリにプッシュして、GitHubの「Actions」タブを覗いてみてほしい。
ビルドが走り、「Authenticate to AWS via OIDC」のステップで、シークレットキーを一切渡していないにもかかわらず、一瞬でAWSのセッションが確立されるはずだ。「Verify AWS Identity」のログには、無事にさっき作ったIAMロールとしてログインしていることが表示されるはずだよ。
お疲れ様でした！
これで、君のプロジェクトから「AWSの秘密鍵漏洩リスク」は綺麗さっぱり消え去った。
- アクセスキーのローテーション作業？ もう必要ありません。
- シークレットキーの管理不徹底によるインシデント？ もう起こり得ません。
OIDCは、モダンなCI/CDを構築する上での「マスト・ハブ」の技術だ。一度この快適さを知ってしまったら、もう二度とベタ書きのシークレットキーには戻れなくなるはずだよ。
今日のこの一歩が、君のチームの開発環境をよりセキュアで、よりストレスフリーなものに変えてくれると確信しているよ。それじゃあ、快適なパスワードレス・ライフを！