4.2暗号化シークレットと外部 Vault 連携

ワークフローはデプロイや外部サービス連携のために シークレット（API トークン・接続情報）を使います。管理者は、これらの秘密が 最小限の範囲 でのみアクセスされ、漏洩しないように統制します。GH-100 では、シークレットの スコープとアクセス、組織/リポジトリレベルの構成、そして 外部 Vault との連携 が問われます。

4.2.1シークレットのスコープとアクセス

GitHub Actions のシークレットは 組織・リポジトリ・環境（environment） の 3 レベルにスコープでき、同名は 狭いスコープが優先（環境 ＞ リポジトリ ＞ 組織）です（GH-200 と共通）。組織レベル のシークレットは複数リポで共有でき、アクセスできるリポジトリを限定 できます。環境シークレット は環境の保護ルール（必須レビュアー等）と組み合わせ、本番デプロイのみで使う、といった統制が可能です。管理者は「必要なワークフローにだけ最小限の秘密を見せる」設計をします。

4.2.2組織/リポジトリレベルの構成

共通の認証情報（例：社内レジストリのトークン）は 組織レベル に置き、許可したリポジトリだけがアクセスできるようにします——リポごとに重複登録せず、ローテーション時も一箇所で更新できます。リポジトリ固有の値は リポジトリレベル に置きます。シークレットはログ上で自動マスクされますが、echo や式に出さない など漏えい防止の運用が前提です。シークレットは REST API からも作成・更新でき（書き込みは公開鍵で暗号化）、多数リポへの配布やローテーションを自動化できます（GH-200 と共通）。

4.2.3サードパーティ Vault 連携

企業が 外部のシークレット管理基盤（Vault）（HashiCorp Vault・Azure Key Vault・AWS Secrets Manager 等）を使っている場合、ワークフローから OIDC 等で Vault に接続し、実行時に動的に秘密を取得 する構成にできます。これにより、GitHub にシークレットを 長期保存せず、企業の Vault を 単一の真実のソース として一元管理できます——ローテーションや監査も Vault 側に集約されます。OIDC（GH-200）と組み合わせると、長期クラウド資格情報も排除できます。

4.2.4この節のまとめ

• シークレットは組織/リポジトリ/環境でスコープ、同名は狭いスコープ優先、組織シークレットは許可リポを限定
• 共通認証情報は組織レベルで一元管理、REST API で配布/ローテーション自動化、echo/式に出さない
• サードパーティ Vault に OIDC 等で接続し実行時に動的取得＝GitHub に長期保存しない
• OIDC と併用して長期クラウド資格情報も排除