Skip to content
Latchkey

シークレット管理とは? 認証情報をコードの外に保つ

シークレット管理とは、認証情報を安全に保存し、適切なタイミングで適切なプロセスに渡し、コードやログに決して漏らさないための規律です。

すべての pipeline はシークレットを必要とします。イメージを push するためのトークン、deploy するためのキー、統合テストを実行するためのパスワードなど。シークレット管理は、それらの値をバージョン管理の外に置き、保存時に暗号化し、必要とする人に限定し、監査可能に保つための実践とツールの集合です。うまくやれば目に見えません。まずくやれば、それが侵害の始まりになります。

何がシークレットに該当するか

  • サードパーティサービス向けの API キーとアクセストークン。
  • クラウド認証情報と署名キー。
  • データベースパスワードと connection string。
  • 秘密鍵、証明書、webhook 署名シークレット。

中核となる原則

優れたシークレット管理はいくつかの考えに基づきます。シークレットを暗号化してリポジトリの外に保存する、必要な範囲でアクセスを付与する、値を定期的にローテーションする、誰がいつ何を読んだかを監査する。シークレットは実行時に注入すべきであり、決して commit すべきではありません。

CI がシークレットを利用する仕組み

ほとんどの CI システムは暗号化された store(GitHub Actions のシークレット、GitLab CI の変数)を提供し、ジョブ開始時に値を環境変数やファイルとして注入します。プラットフォームはそれらをログ内でマスクし、誤って出力されないようにします。ジョブがシークレットを使い、その後環境が破棄されます。

よくある間違い

典型的な失敗は、config ファイルにキーを hardcode する、シークレットをログに echo する、ps で見える形でコマンドライン引数として渡す、あるいはジョブが必要とする以上のスコープをトークンに与えることです。それぞれが、何か問題が起きたときの被害範囲を広げます。

保存するシークレットの必要性を減らす

最も強力な手は、そもそも長命なシークレットを保存する数を減らすことです。OIDC 経由でジョブごとに発行される短命なトークンは、常設の認証情報を完全に排除するため、漏れる恒久的なものが何もありません。

シークレットとランナー

シークレットは、それを扱うマシンと同じだけしか安全ではありません。共有された長命なランナーでは、漏れたり残ったりしたシークレットが次のジョブに読まれる可能性があります。isolation された ephemeral なランナー(Latchkey のマネージドランナーなど)は各ジョブの後に環境を破棄するため、シークレットがそれを必要とした作業より長く残ることはありません。

重要なポイント

  • シークレット管理は、認証情報を暗号化し、限定し、ローテーションし、コードの外に保つ。
  • CI は実行時にシークレットを注入してログ内でマスクし、その後環境を破棄する。
  • 短命なトークンと ephemeral ランナーは、シークレットが悪用されうる期間を短縮する。

関連ガイド