Secretと環境変数の管理

パイプラインからレジストリやクラウドの接続先にアクセスするには、トークンやパスワードが必要です。それらをハードコーディングすると、リポジトリにアクセスできる全員に漏れてしまいます。これを防ぐのがシークレットです。

シークレットは、リポジトリ、Organization、または環境の設定で追加します。保存時には暗号化され、ワークフローにはマスクされた値としてのみ公開されます。

secretsコンテキストを通じてシークレットを参照し、環境変数またはアクションの入力としてステップに渡します。ここではデプロイスクリプトに渡しています。

GitHub はログ内のシークレットを***として自動的にマスクします。それでも、シークレットを出力したり保存したりしてはいけません。base64 のような変換によってマスクをすり抜け、漏えいする可能性があります。

リージョンやビルドフラグなど、機密性のない設定には、varsコンテキストを介した変数を使用します。変数は UI 上で表示されますが、機密情報でなければ問題ありません。

すべての実行には、リポジトリへの認証に使う自動生成のGITHUB_TOKENが付与されます。permissionsキーを使って権限を最小限に絞り込みます。これが最小権限の原則です。

staging や production などの環境では、シークレットをまとめ、デプロイの実行前に必要なレビュアー、待機タイマー、ブランチ制限などの保護ルールを追加できます。

保護された環境では、指定されたレビュアーが承認するまでデプロイジョブが一時停止します。これは本番環境の前に人による意図的な確認を設ける仕組みです。

フォークされた PRからのワークフローにはシークレットが渡されないため、信頼できないコントリビューターがシークレットを盗むことはできません。フォークされた PR でシークレットを必要としないように CI を設計してください。

すべてのシークレットはローテーション可能なものとして扱います。漏えいしたり期限切れになったりした場合は、設定で更新するだけで済みます。次回の実行から新しい値が使われるため、コードの変更は不要です。

基本方針は、機密性のある値にはシークレット、それ以外には変数、権限を厳密に絞ったGITHUB_TOKEN、本番環境を保護する環境、そしてシークレットを決してログに出力しないことです。

シークレットと変数、マスク対象と表示対象を、どのように使い分けるでしょうか。

これでシークレットと変数を安全に管理できるようになりました。暗号化して保存し、secretsコンテキストを介して読み取り、トークンの権限を絞り込み、環境を使ってデプロイを承認制にします。