導入（読者の共感・問題提起）
エンジニアの皆さん、CI/CDパイプラインを構築する際に最も頭を悩ませるのが秘密情報（SECRET_KEY）の取り扱いではないでしょうか？ GitHub Actionsを使ってAWSの開発／検証／本番環境にデプロイする際、うっかりSECRET_KEYを露出させてしまい、後からセキュリティインシデントに発展――なんて事例は意外と多いものです。 本記事では、よくあるアンチパターンを整理しつつ、実務で役立つ安全かつ効率的な管理手法を解説します。
背景や技術の概要（公式情報や社会背景）
- 近年、GitHub ActionsはマネージドなCI/CDとして急速に普及し、AWSへの自動デプロイも定番化。（GitHub公式ドキュメント参照）
- Qiitaでよく読まれる記事では、SECRET_KEYをリポジトリ直下の.envやworkflowファイルにベタ書きする事例が散見される。
- AWS Secrets ManagerやParameter Store、OIDCフェデレーション連携といった公式ソリューションの利用が推奨されているが、導入に手間取るケースも多い。
- 実務でのトラブルとして、「プルリクのログにSECRET_KEYが出力された」「古いキーが使われ続けローテーションできていない」など管理運用上の課題が多発。
具体的な課題・エラー
- リポジトリ直下の設定ファイルにSECRET_KEYをハードコーディング → 誤ってコミット＆プッシュしてしまい、公開リポジトリに流出
- GitHub Actionsのジョブログに
echo ${{ secrets.SECRET_KEY }}と記述 → 実行ログに秘密情報が平文で出力される - 複数環境（dev/stg/prod）で同一のSECRET_KEYを共有 → ローテーション漏れが全環境に波及し、対策コストが膨大に
- 手動ローテーションでヒューマンエラー多発 → 設定ミスで古いキーを残したまま運用し、後追いでトラブル発覚
解決策とコード例
以下の3ステップで安全かつ自動的にSECRET_KEYを管理します。
1. GitHub Secrets に登録
# GitHubリポジトリのSettings → Secrets and variables → Actions
# SECRET_KEY_DEV / SECRET_KEY_STG / SECRET_KEY_PROD
2. AWS側でフェデレーション認証（OIDC）を有効化
# GitHub ActionsのworkflowにOIDCを設定
permissions:
id-token: write
contents: read
# AWS IAMロール設定
- 信頼関係に GitHub の OIDC プロバイダーを追加
- 条件に workflow / repository / environment で限定
3. Workflowで環境ごとに動的に切り替え
name: Deploy to AWS
on:
push:
branches: [ main, develop, staging ]
env:
AWS_REGION: ap-northeast-1
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Configure AWS credentials via OIDC
uses: aws-actions/configure-aws-credentials@v2
with:
role-to-assume: arn:aws:iam::123456789012:role/github-actions-oidc
aws-region: ${{ env.AWS_REGION }}
- name: Select SECRET_KEY by environment
run: |
if [[ "${{ github.ref }}" == "refs/heads/main" ]]; then
echo "AWS_SECRET_KEY=${{ secrets.SECRET_KEY_PROD }}" >> $GITHUB_ENV
elif [[ "${{ github.ref }}" == "refs/heads/staging" ]]; then
echo "AWS_SECRET_KEY=${{ secrets.SECRET_KEY_STG }}" >> $GITHUB_ENV
else
echo "AWS_SECRET_KEY=${{ secrets.SECRET_KEY_DEV }}" >> $GITHUB_ENV
fi
- name: Deploy to S3
run: |
aws s3 sync ./build s3://my-bucket --delete
env:
AWS_SECRET_ACCESS_KEY: ${{ env.AWS_SECRET_KEY }}
ベストプラクティス・運用上の注意
- 最小権限の原則：IAMロールは用途ごとに限定し、不要な権限は付与しない。
- 定期ローテーション：AWS Secrets ManagerやParameter Storeと連携し、自動ローテーションを設定。
- ログ出力時の秘匿：${{ secrets.* }}を直接echoせず、$GITHUB_ENV経由で渡した環境変数もログには残さない。
- 環境分離：開発／検証／本番で別々のSecretsを用意し、誤用を防止。
- 監査とアラート：CloudTrail＋CloudWatchで異常アクセスやロールアサンプションを検知→SNS通知。
まとめと今後の展望
この記事では、GitHub ActionsでAWSの複数環境へデプロイする際にありがちなSECRET_KEY管理のアンチパターンと、その具体的な対策を紹介しました。 環境ごとにSecretsを分け、OIDC連携によるロールアサンプション、自動ローテーション、監査体制の整備を組み合わせることで、安全かつ運用コストを抑えたCI/CDパイプラインを実現できます。 今後はGitHub Actionsの環境保護機能（Environments）や、AWS Systems Manager Parameter Storeの暗号化キーサポートなど、さらに強化されたセキュリティ機能が登場予定です。 本稿を参考に、ぜひ貴社のデプロイフローをリファクタリングしてみてください。