GitHub Actions OIDC完全攻略：ハードコーディングされたクレデンシャルに告げる「永続的な決別」
「`AWS_ACCESS_KEY_ID` と `AWS_SECRET_ACCESS_KEY` をGitHubのSecretsに保存して、期限切れが近づくたびにローテーションする」……そんな前時代的な運用で消耗していませんか？
もし、そのキーがGitHubから流出した場合、あなたのクラウドインフラは即座に攻撃者の踏み台になります。2024年現在、大規模開発の現場で「永続的な認証情報」をSecretsに置くことは、「家の鍵を玄関マットの下に置いて出かける」のと同じレベルの過失です。
今回は、GitHub Actionsの「OpenID Connect (OIDC)」を用い、クレデンシャルを一切保存せずにAWS/GCPと安全に連携する、プロフェッショナルな設計思想を叩き込みます。
—
1. なぜOIDCなのか？：信頼の連鎖を構築する
OIDC（OpenID Connect）は、GitHubを「IDプロバイダー」として、クラウドプロバイダー（AWS/GCP）に「このワークフローは私が認めたものだ」と一時的なチケットを発行させる仕組みです。
- 静的クレデンシャルの排除: Secretsにキーを置かない。
- 最小権限の自動適用: ロールベースの制御で、特定のブランチや環境のみに権限を絞る。
- 自動ローテーション: 認証情報はワークフロー実行中のみ有効な短寿命トークンであり、漏洩リスクがゼロに近い。
—
2. 実践：AWSにおけるOIDC構成の「神」構成
AWS側でOIDCプロバイダーを設定し、IAMロールに信頼ポリシーを記述します。ここで重要なのは、「Condition（条件）」によるガードレールです。
AWS IAM 信頼ポリシー（ベストプラクティス）
単にGitHubを信頼するのではなく、リポジトリとブランチを限定することで、悪意あるフォーク先からの権限奪取を物理的に防ぎます。
{
“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:my-org/my-app:ref:refs/heads/main”
// ↑ ここが肝。mainブランチからの実行のみに権限を限定する
}
}
}
]
}
—
3. GitHub ActionsのYAML設定：プロの実装例
以下は、OIDCを用いたAWS連携のテンプレートです。冗長な記述を避け、`permissions`ブロックを最小限に絞るのが「プロの作法」です。
name: Deploy to Production
on:
push:
branches: [ main ]
permissions:
id-token: write # OIDCトークンの発行に必須
contents: read # ソースコードのチェックアウトに必要
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
aws-region: ap-northeast-1
- name: Deploy
run: |
# ここにはクレデンシャルは一切不要！
aws s3 sync ./dist s3://my-bucket
—
4. チームの生産性を爆上げする「隠れたハック」
① GitHub CLI (`gh`) は必須ツール
ブラウザでポチポチ設定してはいけません。`gh`コマンドでワークフローのステータス確認やログ取得を完結させましょう。
- 神コマンド: `gh run watch`（実行中のフローをターミナルで監視。失敗したら即座に通知）
- 推奨プラグイン: `gh-actions-status` でリポジトリ全体のCI状況をダッシュボード化せよ。
② `CODEOWNERS` による守りの自動化
CI/CD設定（`.github/workflows/`）に変更を加える際は、必ずSREチームやテックリードがレビューするように強制します。
.github/CODEOWNERS
.github/workflows/deploy.yml @my-org/sre-team
③ 再利用可能なワークフロー (Reusable Workflows)
組織内で認証ロジックを共通化し、各プロジェクトにコピー＆ペーストさせないこと。設定の変更が必要な際に、全リポジトリを修正する地獄から解放されます。
—
5. テックリードからの提言：セキュリティは「設定」で強制せよ
OIDCへの移行は、単なるセキュリティ対策ではありません。「クレデンシャル管理」という無駄な作業を開発者の頭の中から完全に消去するための最適化です。
- CIを速くするには: ジョブの並列化だけでなく、認証のオーバーヘッドを減らす。OIDCならセッション開始も爆速です。
- 障害を減らすには: 「Secretsの期限が切れてデプロイ失敗」という初歩的な人為的ミスを、システム的に排除する。
「仕組みで解決できない問題は、個人の努力で解決しようとするな」。これがDevOpsの鉄則です。今すぐGitHub ActionsのSecretsからクラウドのキーを削除し、OIDCに移行してください。それが、あなたのチームがより速く、より安全にデプロイするための最初の一歩です。