Workload IdentityはホームAIスタック内のサービスをどのように認証するのか?

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

ワークロードIDは、ネットワークアドレスや保存されたパスワードではなく、短期的な暗号資格情報を検証済みプロセスに結び付けることで、家庭内AIサービスを認証します。

ローカルRAG API、モデルサーバー、ベクターデータベース、エージェントツールゲートウェイは、1つのホームネットワークを共有していても、権限は大きく異なる場合があります。ワークロードIDを使うと、各プロセスはデータや資格情報を受け取る前に、自分が承認済みのどのサービスであるかを証明できます。検証者は実行時の証拠を確認して名前付きIDを発行し、リソースの認可は別のポリシー判断に委ねます。

アテステーションによって実行中のプロセスと宣言されたIDを結び付ける

IDエージェントは、サービスアカウント、実行ファイル、コンテナイメージ、名前空間、ホスト、署名済みワークロードメタデータなど、検証可能な実行時プロパティを監視します。登録ポリシーは、自己申告されたラベルを信頼するのではなく、承認された組み合わせを安定したサービス名に対応付けます。

実用的な実行時ワークロードアテステーションのデモでは、SPIFFEとSPIREがホムラボ内でIDを発行する前にワークロードをアテステーションする方法を紹介しています。ブートストラップ時の信頼は、すべてのコンテナにコピーされた秘密情報ではなく、ノードと登録プロセスに置かれます。

これにより、最初の認証における問いは「どのIPが接続したか」から「どの承認済みワークロードがこのIDを保持していることを証明したか」へと変わります。動的アドレスやコンテナの再起動のたびに、新しい静的資格情報を用意する必要はありません。この違いは、後の家庭内テストでも確認できます。

ID認証局が短期的で検証可能な資格情報を発行する

アテステーションの後、認証局はワークロード識別子と限られた有効期間を含むX.509またはJWT資格情報を発行します。ローカルエージェントは保護されたワークロードインターフェースを通じてそれを配布し、有効期限前にローテーションします。自動化を進める前に、中間結果を検査可能な状態に保つ必要があります。

短期ワークロード資格情報の概要では、SPIFFE IDが短期的で暗号学的に検証可能であり、ハードコードされたサービス秘密情報への依存を減らすことを説明しています。受信側のサービスは、発行者、オーディエンス、時刻、鍵所有の証明を検証します。この境界は、現実的な運用条件下で個別に測定する必要があります。

有効期間を短くすることで、サービスが削除または侵害された後の露出を抑えられます。期限切れの証明書はフェイルクローズで拒否されるべきであり、運用担当者が長期間有効な鍵を復元するよう促されないよう、ローテーションは自動化する必要があります。複数のソースが限られたコンテキストを奪い合うとき、この実際的な影響が現れます。

認証はIDを提供するが、アクセスを許可するのはポリシーである

有効なワークロードIDは、どのサービスが呼び出しているかを証明します。しかし、モデルサーバーがすべてのコレクションを読み取れることや、エージェントが特定のユーザーの代理として動作することまでは証明しません。認可では、IDに加えて、リソース、操作、ユーザー委任、現在のポリシーを評価します。

ワークロードIDとエージェントIDの分析では、ワークロードID、相互認証、接続上位で伝達されるユーザーまたはエージェントのコンテキストを区別しています。この分離により、信頼されたサービス証明書が万能の権限になるのを防げます。この依存関係は、最終インターフェースでも明示したままにする必要があります。

障害の境界となるのは、侵害されたID認証局、ノードアテスター、または登録ルールです。暗号学的な証明は、発行されたIDを忠実に強制します。たとえ発行ポリシーが、攻撃者に制御されたプロセスを誤ったサービスに対応付けていたとしてもです。

アテステーションから認可まで、1つのサービス呼び出しを追跡する

RAGからベクターストアへのリクエストを1つ選び、ワークロードセレクター、登録済みID、発行者、証明書またはトークンの有効期間、鍵の場所、ピア検証、要求されたリソース、委任されたユーザー、ポリシー判断、ローテーション、失効、監査識別子を記録します。したがって、その結果は元の証拠と照合する必要があります。

セルフホストAIのID制御と比較してください。正当な再起動、コピーされた資格情報、未登録のコンテナ、誤ったオーディエンス、期限切れのID、変更されたサービスアカウント、有効なIDによる禁止コレクションへの要求をテストします。この違いは、後の家庭内テストでも確認できます。

認証されたワークロードが自動的に再接続し、なりすましや過剰な権限行使がすべて名前付きの境界で失敗する場合にのみ合格とします。ID認証局は個別に保護し、リソース認可はサービス認証よりも狭く保ちます。自動化を進める前に、中間結果を検査可能な状態に保つ必要があります。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.