セキュリティ & アイデンティティ

GKE における AI サプライチェーンの保護: 自動 AI BOM 対応 k8s-aibom のご紹介

2026年7月29日

Glen Messenger

Group Product Manager

Try Gemini Enterprise today

The front door to AI in the workplace

※この投稿は米国時間 2026 年 7 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

セキュリティチームは、シャドー AI にどのように対応すべきでしょうか？デベロッパーが正式に登録せずにデプロイしたワークロードは、多くの場合、従来のセキュリティスキャナを回避できます。特権 DaemonSet、カーネルレベルのアクセス、Pod 仕様の手動編集を求めることで、開発を遅らせて安定性を損なうことに組織が消極的であるためです。

この行き詰まりを打開するため、Google はこのたび k8s-aibom をオープンソース化いたしました。この特権なしの軽量 Kubernetes コントローラは、クラスタ API とコンテナ環境を継続的にモニタリングして、実行中の AI ランタイム（vLLM や Triton など）を自動的に検出し、標準的な CycloneDX Machine Learning Bill of Materials（ML-BOM）を生成します。

k8s-aibom は、ワークロードが正式に登録されているかどうかに関係なく、ランタイム実行から直接、監査に適した可視性を自動的に確保し、デベロッパーに統合の負担をかけることなく AI プロジェクトをパイロットから本番環境に安全に移行できるようチームを支援します。

負担のないアーキテクチャ

k8s-aibom は、総合的な可視性に関する CISO の要件と、クラスタの安定性に関する SRE の要件の両方を尊重するようにゼロから設計されています。k8s-aibom-system Namespace に、特権なしの単一の Deployment としてデプロイされます。デベロッパー側の負担はゼロです。サイドカー、eBPF カーネルモジュール、特権 DaemonSet は不要で、既存のデベロッパー Pod 仕様を変更する必要もありません。

https://storage.googleapis.com/gweb-cloudblog-publish/images/k8s-aibom.max-1700x1700.png

k8s-aibom は AI ワークロードを監視し、BOM を生成します。

検出パイプラインは、次の 4 つの明確な段階を経て実行されます。

クラスタワークロードのスクレイピング: コントローラは、クラスタ全体で KServe リソース、Deployment、StatefulSet、DaemonSet、Job を継続的にモニタリングします。
AI スタックの特定: 高度なパターンマッチングにより、コンテナイメージ、環境変数、コマンドライン引数を検査して、サービングランタイム（vLLM、Triton Inference Server、TGI、Ollama）、自律型エージェントフレームワーク（LangChain、AutoGen、CrewAI）、ベクトルデータベースと RAG ストア（Milvus、Qdrant、pgvector）、分散トレーニングジョブと評価ハーネスを検出します。
標準的なマニフェストの生成: コントローラは、検出されたアーティファクトを正式な OWASP CycloneDX 1.6 Machine Learning Bill of Materials（ML-BOM）ドキュメントにコンパイルします。
シンクへのエクスポート: コントローラは、生成された ML-BOM をクラスタ内の AIBOM カスタムリソース（CR）のカスタムリソースステータス（status.bomDocument）に直接アタッチし、Google Cloud Storage バケットや外部 Webhook エンドポイントなどのオプションの外部シンクにルーティングします。

アプリケーションチームが、Pod 仕様の変更、サイドカーコンテナの挿入、継続的インテグレーションと継続的デリバリー（CI / CD）のパイプラインの変更を行う必要はありません。さらに、k8s-aibom は Kubernetes クラスタの状態を純粋な関数入力として扱うため、同一のクラスタ入力からは、バイト単位で同一の ML-BOM ドキュメントが生成されます。この決定論的プロパティを持つ k8s-aibom は、GitOps ワークフローに最適です。これにより、サイト信頼性エンジニア（SRE）は、AI の依存関係がドリフトしたときに正確な差分を実行し、精密な変更検出アラートをトリガーできます。

既存の AIBOM ツールでカバーできない領域

多くの AI BOM ソリューションはビルド時スキャナを備えており、保存されているアーティファクトから BOM を生成します。これらのツールを使用すると、デプロイする予定だったコードを追跡できます。

商用 AI セキュリティプラットフォームは、クラウドネイティブなポスチャー管理によって可視化できる範囲を拡大しますが、通常はベンダー固有のデータモデルを中心に形成された外部スキャンによってこれを実現します。こうしたツールで、コンプライアンスレビュー担当者、セキュリティ運用（SecOps）チーム、プラットフォームエンジニアが、現在何が実行されているか、どこに接続しているか、アサーションを検証するにはどうすればよいかを把握できることはほとんどありません。

Google は k8s-aibom を、このギャップを埋めるための専用ツールとして構築しました。k8s-aibom は、アーティファクトのスキャンではなく、ライブクラスタの観測から BOM を生成し、ベンダー独自の形式ではなく、より広範な OWASP および Open Source Security Foundation（OpenSSF）サプライチェーンエコシステムと統合する標準準拠の CycloneDX 1.6 ML-BOM を出力します。また、準拠する Kubernetes クラスタで特権なしのコントローラとして実行されるため、既存のビルド時およびポスチャー管理ツールの代わりとなるのではなく、これらを補完するものとなります。

信頼度モデル: 意図と推論の分離

コンプライアンス監査担当者や SecOps エンジニアにとって、未加工のテレメトリーがノイズになることがよくあります。標準的なモニタリングツールは、コンテナが実行中であることを示しますが、AI モデルがプラットフォームエンジニアによって明示的に構成されたのか、実行時に自律スクリプトによって動的に抽出されたのかを証明することはできません。k8s-aibom は、その決定論的な信頼度モデルによってこの曖昧さを解消し、検出されたアセットを明確な階層に分類します。

宣言: ワークロード構成で、顧客またはデベロッパーによって明示的に定義された（例: --model meta-llama/Llama-2-7b など、明示的に渡されたコンテナ引数）。「宣言」の信頼度検出は、人間の明確な意図を表します。
推論: コンテナイメージ、環境変数、実行プロファイルの詳細な検査を通じて、コントローラのパターンマッチングエンジンによって自律的に導出された（例: ^vllm/.* コンテナ署名の特定）。
未解決: アクティブな AI の存在が検出されたが、正確なモデルパラメータ、重み、バージョンを決定論的に確立できないワークロードに適用される。「未解決」の信頼度検出の場合、対象を絞ったセキュリティレビュー向けにワークロードに即座にフラグが付けられます。

この構造化された分類により、コンプライアンスレビュー担当者は、明示的なエンジニアリングの意図と機械の推論を即座に分離し、監査中に揺るぎない信頼の連鎖を確立できます。

不変性と最小権限: 監査に適したセキュリティモデルの構築

侵害されたノードや権限が昇格された管理者によってログや指標が変更、削除、改ざんされる可能性があるため、監査担当者は標準的なオブザーバビリティテレメトリーに対して依然として強い懐疑心を抱いています。k8s-aibom は、厳格な最小権限の分離とデータの不変性をベースにした、監査に適した証拠トレイルを確立します。

このコントローラは、最小限の Identity and Access Management（IAM）Workload Identity にバインドされた専用の Kubernetes サービスアカウントの下で動作します。BOM レコードを外部ストレージシンクに書き込む権限を持つ唯一の ID として機能し、roles/storage.objectCreator 権限のみを必要とします。

Google Cloud Storage の外部シンクの実装では、最も厳格な監査基準と証拠基準を満たすために、オブジェクト作成時に DoesNotExist 事前条件が適用されます。ML-BOM が Cloud Storage バケットに書き込まれると、オブジェクトは暗号化され、変更できなくなります。

侵害されたクラスタアクターや不正なワークロードによって、サイレントに上書き、変更、または遡及的に改ざんされることはありません。SecOps チームは、規制当局に提出された過去の監査ログが、クラスタ実行の変更不可能な記録であることを絶対的に保証できます。

ガバナンス体制の整備の促進: グローバルな規制フレームワークへのマッピング

k8s-aibom は、標準化された CycloneDX 1.6 ML-BOM の生成を自動化することで、低レベルの Kubernetes ランタイム状態と高レベルのガバナンスフレームワークのギャップを直接的に埋めます。また、主要な国際基準に不可欠な基礎的実証データを提供することで、停滞していた GKE AI のデプロイの道を切り拓きます。

EU AI 規則: 組織が第 12 条（継続的なトレーサビリティのための自動ロギングと記録保持）と第 50 条（AI システムの透明性義務）に準拠できるように設計されています。このツールは、サービングランタイムとエージェントスタックを自動的にカタログ化することで、コンプライアンス監査中に必要となる可能性のある技術的証拠の収集を簡素化します。
NIST AI リスク管理フレームワーク（AI RMF）: ガバナンス、マッピング、測定、管理の各機能を実現する、継続的かつ実証的なアセットの可視性がもたらされ、コンプライアンスワークフローを、純粋な手動チェックから、より自動化されたアセットインベントリトラッキングへと移行できます。
ISO/IEC 42001: AI マネジメントシステムのアセットの検出と追跡に関するコンプライアンスの取り組みをサポートし、インベントリの検証における手動のスプレッドシート入力や定期的なスナップショット監査への依存度を低下させます。