最小権限 CI とは何か? パイプラインに必要なものだけを与える

最小権限 CI とは、各パイプラインと job に実際に必要な権限だけを、必要な期間だけ与え、それ以上は何も与えないことを意味します。

何でもできる CI job は、トリガーを待つ災害です。最小権限 CI は、古典的なセキュリティ原則をパイプラインに適用します。job を行うために必要な最小限の権限を付与するのです。build がコードを read するだけでよいなら、deploy キーを保持すべきではありません。何か問題が起きたとき、最小権限こそが侵害を小さく抑えるものです。

広範な権限が危険な理由

すべての job が write アクセス、deploy キー、広範なクラウド認証情報を持っていると、あらゆる侵害 (悪意ある依存関係、汚染された PR) がそれらすべてを引き継ぎます。最小権限は、侵害された job ができることをほとんどなくします。そもそも多くを与えられていなかったからです。

どこに適用するか

job が write を必要としない限り、CI トークンを read-only にスコープする。
job ごとにクラウドのロールを付与し、必要とされる正確なリソースに限定する。
シークレットへのアクセスを、それを使う特定の job に制限する。
どの workflow が本番に deploy できるかを制限する。

デフォルト拒否と明示的な付与

最も強固な姿勢はゼロ権限から始め、各 job が必要だと宣言したものだけを追加します。たとえば GitHub Actions では、デフォルトのトークン権限を read-only に設定し、job ごとに追加を付与することで、権限が明示的かつ監査可能になります。

最小権限と短い有効期間

スコープと有効期間は連携します。狭くスコープされたうえ数分で失効するトークン (エフェメラルな認証情報) は、たとえ盗まれても攻撃者にはほとんど役に立ちません。最良の結果のために、最小権限を短命な job ごとの認証情報と組み合わせましょう。

分離が全体像を完成させる

最小権限は job が行うことを許されるものを制限し、分離は job が到達できるものを制限します。エフェメラルで分離された runner (Latchkey managed runner など) は、job が他の job の状態に触れられないようにするので、完全に侵害された低権限の job でさえ箱の中に閉じ込められたままです。

重要なポイント

最小権限 CI は各 job に本当に必要な権限だけを付与します。
デフォルト拒否から始め、job ごとにスコープを絞った付与を追加し、理想的にはデフォルトを read-only にします。
短命な認証情報と分離を組み合わせて、あらゆる侵害を封じ込めます。