ToolHive 0.47、MCPサプライチェーン検証とSPIFFEワークロードIDをデプロイ層に統合

ToolHive 0.47.0の焦点は、MCPツールをさらに増やすことではなく、ツール、スキル、実行中のワークロードに検証可能なIDチェーンを追加することにある。スキルとプラグインのプッシュをCosign鍵で署名できるようになり、インストール時には鍵署名の状態が表示される。ロックファイルには固定された公開鍵が保存され、その後の同期やアップグレードでも同じトラストアンカーを使用しなければならない。これはOCI digestの固定だけでなく、パブリッシャーの検証も追加するものであり、イメージ名やスキル名が乗っ取られた後、悪意あるコンテンツが自動アップグレード経路を通じてエージェントに侵入するリスクを軽減できる。

Kubernetes Operatorには、SPIFFE trust domain、証明書ソース、クライアント関連付けのためのCRD設定も追加された。基盤となる型はX.509-SVID、JWT-SVID、およびRFC 8693 token exchangeを介したダウンストリームトークンの取得をサポートする。principalには、完全なSPIFFE IDまたは末尾のワイルドカードを指定できる。Admission検証では、互いに重複するprincipal patternを拒否するとともに、RFC 8707 resource URIをチェックし、2つのルールが同じワークロードを奪い合うことを防ぐ。これにより、MCPサービスは長期間有効なclient secretをPodに格納することなく、動的なワークロードIDに基づいて認可を行える。

そのほかの保護策として、OIDC DiscoveryがプライベートIPを参照することの禁止、OAuth callbackでの`Referer`送信の停止、scopeが指定されていない場合にデフォルト値とプロバイダーの`scopes_supported`の積集合のみを使用する変更が含まれる。プライベートCAもRFC 8693の信頼できるissuerとして使用できるようになり、社内PKIに適した構成となった。

ただし、デプロイ担当者は「SPIFFE対応」を設定不要ですぐ使えるゼロトラストソリューションと見なすべきではない。trust bundle、issuer、audience、resource、principalの対応関係は、引き続き正しく設定する必要がある。公開鍵についても、独立した信頼できるチャネルを通じて取得しなければならない。その後リリースされた0.47.1はCIの調整のみで、上述したランタイム機能に変更はない。今後注目すべき点は、鍵のローテーション手順、keyless Sigstoreのサポート、クラスター間token exchangeのエンドツーエンドテストである。