CI/CDのシークレット

デプロイスクリプト、GitHub Actionsワークフロー、GitLab CIの設定、Jenkinsfileにシークレットを直接記載すると、リポジトリだけでなくビルドログからも露出するおそれがあります。

このガイドが役立つ場合

.github/workflows/*.yml にトークンを直接記載している場合
Jenkinsfile、.gitlab-ci.yml、デプロイ用シェルスクリプトに認証情報がある場合
ビルド時のトークンを環境変数で渡さず、ファイルに記載している場合

推奨方法

CI/CDプラットフォームのシークレット保存機能を使ってください。
ワークフローファイルには参照だけを残してください。
ログのマスキング、権限の最小化、ローテーション方針を併せて確認してください。
クラウドへのデプロイでは、可能であれば長期固定シークレットよりも、OIDCなどの短期認証情報を使う連携を優先してください。

例

変更前

yaml

steps:
  - name: Deploy
    run: |
      curl -H "Authorization: Bearer ghp_xxxxxxxxx" https://example.com/deploy

変更後

yaml

steps:
  - name: Deploy
    env:
      DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
    run: |
      curl -H "Authorization: Bearer ${DEPLOY_TOKEN}" https://example.com/deploy

担当者の対処手順

露出した既存のトークンをまず失効し、新しい値に置き換えてください。
ワークフロー、Jenkinsfile、CI設定ファイル、デプロイスクリプトからシークレットの実際の値を削除してください。
新たに発行したトークンまたはパスワードをCI/CDのシークレットストアに登録してください。
ファイルには ${{ secrets.NAME }} または各プラットフォームの参照構文だけを残してください。
クラウドプロバイダーへのアクセスでは、OIDCフェデレーションに置き換えられるか検討してください。
最近の実行ログに値が露出していないか確認してください。

担当者への案内例

「ワークフローファイルに保存したトークンを削除し、GitHub Actions Secretsまたは利用中のCI認証情報ストアを使ってください。」
「CI/CDの設定ファイルには、シークレットの実際の値ではなく参照だけを残してください。」
「過去のビルドログに値が残っている可能性があるため、最近の実行履歴も確認してください。」

追加の確認事項

ログのマスキングは機能しているか。
フォークからのプルリクエストなど、外部からのトリガーでシークレットが露出しないか。
デプロイ専用トークンの権限は過剰でないか。
長期アクセスキーをOIDCやワークロードIDに置き換えられるか。