Leo

信頼しているすべてのアドミッションフックには抜け道があります。それ自体はスキャンダラスなことではなく、Kubernetesがそれらをどのように結び付けているかに過ぎません。7月30日のCNCF投稿は、その抜け道を塞ぐ方法を提示しています。APIサーバーから署名および証明のチェックを外し、Node Resource Interfaceプラグインを介してコンテナランタイム自体に移すというものです。

その要点を一言で。Supply Chain NRI Pluginは、ランタイム（CRI-Oまたはcontainerd）上のCreateContainerイベントにフックし、ランタイムアノテーションからイメージ参照とダイジェストを取得し、OCIレジストリから証明を取得し、コンテナ起動前に名前空間ごとのポリシーに照らして検証します。チェック対象はSLSA Provenance、VEXドキュメント、VSAの3種類の成果物です。検証に失敗するとコンテナは起動しません。このフックはイメージプル時ではなく作成時に発動するため、数時間前からノード上に存在するイメージでも、実際に実行される前にチェックされます。

アドミッションだけでは不十分な理由

失敗モードはすでにご存じでしょう。CNCF投稿は4つ挙げています。kubeletが直接管理するStatic Podはアドミッションを完全にスキップします（ミラーポッドは失敗してもコンテナは実行されます）。kubeletへ直接アクセスできる人は、APIサーバーをバイパスしてコンテナを起動できます。名前空間セレクタの設定ミスにより、名前空間全体がサイレントに除外される可能性があります。また、アドミッションフックの障害時には、クラスタ全体のロックアップかサイレントバイパスのどちらかを選ばざるを得ません。

Kyverno、OPA Gatekeeper、Sigstore Policy ControllerはいずれもAPIレイヤに存在するため、これらの抜け道をすべて引き継ぎます。問題はレイヤにあり、プロジェクト自体ではありません。チェックをランタイムまで下げることで、どのような経路でスケジュールされたとしても、すべてのコンテナがランタイムを通過せざるを得ないようにします。

落とし穴

ランタイムレベルの検証は無償の昼食ではありません。すべてのノードでプラグインが健全に動作し、OCIレジストリに到達するためのクレデンシャルとネットワークパスを備えている必要があります。フェイルオープンにすればコンプライアンスの茶番劇になります。フェイルクローズにすれば、レジストリの一時的な障害がクラスタ全体の起動停止につながります。投稿では、レジストリに到達できない場合にプラグインがどう振る舞うか、あるいはポリシー更新をノードへどのようにロールアウトするかについては触れていません。本番環境で有効化する前に、両方の答えを用意しておく必要があります。

結論：信頼境界は正しい方向に移動し、4つのバイパス経路は実在します。レジストリが不調な午後にどうなるかの運用手順は自前で用意してください。