こんにちは！日々のデプロイ作業やCI/CDパイプラインの構築、本当にお疲れ様です。
突然ですが、皆さんはGitHub ActionsからAWSやGCPなどのクラウド環境へデプロイするとき、こんな「秘密情報（シークレット）」の管理に悩んだことはありませんか？
- 「AWSのアクセスキーを発行して、GitHubの `Settings > Secrets` に長期間有効なクレデンシャルをベタッと貼り付けている…」
- 「キーの有効期限が切れるたびに、手動で発行し直して設定を更新する悪夢のローテーション作業が発生している…」
- 「万が一、リポジトリに誤ってキーが漏洩（ハードコード）したらどうしようという夜しか眠れない不安を抱えている…」
……もし一つでも心当たりがあるなら、今日でその不安とはお別れしましょう。
今回解説する「OpenID Connect (OIDC)」をマスターすれば、そんな面倒で危険なアクセストークンの管理から完全に解放されます。
これを導入すれば、セキュリティが劇的に向上するだけでなく、鍵のローテーション作業からも解放されて毎日の開発が本当に楽になりますよ。さあ、一緒にOIDCの世界へ踏み出しましょう！
—
1. なぜ従来のアクセストークン管理は「悪夢」なのか？
まずは、これまでの一般的な方法と、何が危ないのかを整理しておきましょう。
これまで、GitHub ActionsからAWSなどのクラウドへアクセスするには、AWS側で「アクセスキーID」と「シークレットアクセスキー」を発行し、それをGitHubのシークレット機能に保存するのが主流でした。
しかし、これには致命的なデメリットがあります。
1. 有効期限がない（または長い）: 一度発行したキーは、誰かが明示的に無効化しない限り半永久的に使えてしまいます。
2. 漏洩リスク: 悪意あるコードやログ出力のミスによって、キーが外部に流出した場合、無限にクラウド資源を悪用されるリスクがあります。
3. 管理コスト: 定期的なキーのローテーション（再発行と設定更新）を人間が手動で行うのは、ヒューマンエラーの温床になります。
救世主「OIDC（OpenID Connect）」とは？
OIDCは、パスワードやアクセスキーの代わりに、「信頼できる第三者（この場合はGitHub）」が身元を証明したデジタル証明書（IDトークン）を一時的に発行し、クラウド側がそれを検証して信頼する仕組みです。
イメージとしては、GitHubが発行する「このワークフローは、確かに〇〇という安全なリポジトリの、〇〇というブランチで動いていますよ」という身分証明書（一時パスポート）をAWSに見せ、AWSが「それなら通しなさい」と一時的な権限をくれるようなものです。
- 長期的なシークレットをリポジトリに保存しなくてよい（パスワードレス！）
- トークンは毎回数分〜数十分で自動失効する（使い捨て！）
- 「どのリポジトリの、どのブランチからのアクセスか」を厳密に制限できる（安全！）
それでは早速、実際にAWSとGitHubをOIDCで結びつける設定を、一緒に一つずつ見ていきましょう。
—
2. 【基礎セットアップ】AWSとGitHubをOIDCで繋ぐ
今回は代表例として、「GitHub ActionsからAWSに安全にログインし、S3バケットの一覧を取得する」というHelloWorld的な動作確認までの手順を解説します。
大まかなステップは以下の3つです。
1. AWS側でGitHubを「信頼できるプロバイダ」として登録する
2. AWS側でGitHub Actionsに与える「ロール（権限）」を作る
3. GitHub Actionsのワークフローを書く
—
ステップ1：AWSにOIDCプロバイダを追加する
まずはAWSコンソールにログインし、「IAM（Identity and Access Management）」を開きます。
1. 左メニューの 「アクセス管理」>「プロバイダ」 を選択し、「プロバイダを追加」をクリックします。
2. 以下のように設定します。
- プロバイダのタイプ: `OpenID Connect`
- プロバイダのURL: `https://token.actions.githubusercontent.com`
- 対象者 (Audience): `sts.amazonaws.com`
3. 「サムネイルを取得」をクリックし、プロバイダを追加します。
これで、AWSが「GitHubという身元確認機関からの手紙を信用する」状態になりました。
—
ステップ2：IAMロールと信頼ポリシーを作成する
次に、GitHub ActionsがAWS上で「何ができるか」の権限を定義するIAMロールを作成します。ここがOIDCセキュリティの心臓部です。
1. IAMメニューの 「ロール」 から 「ロールを作成」 をクリックします。
2. 信頼されたエンティティの種類で 「ウェブアイデンティティ」 を選択します。
3. 先ほど作成したOIDCプロバイダを選択し、Audienceを `sts.amazonaws.com` にします。
4. ロールを作成したら、そのロールの「信頼ポリシー（Trust Policy）」を以下のように編集します。ここが一番重要なポイントです。
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Principal”: {
“Federated”: “arn:aws:iam::あなたのAWSアカウントID: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:あなたのGitHubユーザー名/リポジトリ名:”
}
}
}
]
}
> 💡 現場の知見：ロールマッピングのベストプラクティス
> 上記の `StringLike` の部分（`sub` クレームの検証）に注目してください。ここを `repo:あなたの組織名/リポジトリ名:ref:refs/heads/main` のように絞り込むことで、「メインブランチで動くワークフローからしか、このAWSロールを使わせない」という強固な制限をかけられます。
> 「PRの段階ではデプロイさせない」「特定の環境（Environment）からしか本番用ロールを使わせない」といった制御もここで可能です。セキュリティ事故を防ぐための鉄則です！
最後に、このロールに適当な権限（今回は動作確認用に `AmazonS3ReadOnlyAccess` などのポリシー）をアタッチしておきます。そして、作成したIAMロールのARN（Amazon Resource Name）をコピーしておいてください。
—
3. 【動作確認】Hello World！安全なデプロイワークフローを書く
AWS側の準備ができたら、いよいよGitHub側です。
リポジトリの `.github/workflows/oidc-test.yml` というファイルを新規作成し、以下のコードを記述します。
> 🌟 ここに注目！
> 従来の `aws-actions/configure-aws-credentials` で必要だった `aws-access-key-id` や `aws-secret-access-key` が一切登場しないことに注目してください。代わりに、AWSのロールARNを指定するだけです！
name: OIDC AWS Connection Test
メインブランチへのプッシュ時に実行
on:
push:
branches:
- main
AWSへのアクセスに必要な権限（id-token）をGitHub Actionsに付与
permissions:
id-token: write
contents: read
jobs:
oidc-connect:
runs-on: ubuntu-latest
steps:
# 1. リポジトリのコードをチェックアウト
- name: Checkout repository
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::あなたのAWSアカウントID:role/先ほど作ったIAMロール名
aws-region: ap-northeast-1
# 3. 動作確認：AWSの身元（誰としてログインしているか）を確認する
- name: Verify AWS Identity
run: |
echo “AWSにOIDC経由で正常にログインしました！”
aws sts get-caller-identity
echo “ついでにS3バケットの一覧を取得してみます：”
aws s3 ls
このファイルをコミットして `main` ブランチにプッシュし、GitHubの「Actions」タブを覗いてみてください。
無事にワークフローが成功し、ログの中にあなたのAWSアカウント情報が表示されたでしょうか？
シークレットキーを一切ハードコードしていないのに、安全にAWSのリソースへアクセスできた瞬間です。感動ものですね！
—
4. まとめ：明日からの開発をより安全に、より軽やかに
いかがでしたでしょうか？
今回解説したOpenID Connect (OIDC)を活用すれば：
1. 長期的なシークレット管理の恐怖から解放される
2. キーの有効期限切れやローテーションの手間がゼロになる
3. 「どのブランチから、どのリポジトリから」というアクセス制限を強固にかけられる
という強力なメリットをチームにもたらすことができます。
「鍵を渡さないセキュリティ」は、これからのモダンなCI/CDにおいて必須の教養です。ぜひご自身のプロジェクトや個人開発でも導入し、安全でストレスフリーな開発環境を手に入れてくださいね。
あなたのDevOpsライフが、より快適でエキサイティングなものになりますように！