Kubernetes 上で AI エージェントをサンドボックス化する5つの層

コードを生成・実行する自律型 AI エージェントは、共有 Kubernetes インフラストラクチャに新たなセキュリティリスクをもたらします。これに対応するため、Oracle Cloud Infrastructure のエンジニアは、クラスターの効率性を犠牲にすることなくエージェントのワークロードを隔離する、5層のサンドボックス化戦略を定義しました。このアプローチでは、既存のクラウドネイティブツールを活用して、信頼できないコードの実行に対して安全な境界を作成します。

何が起きたか

AI エージェントが開発ワークフローで一般的になるにつれ、パッケージのインストール、スクリプトの実行、コードの反復処理など、より高い自律性を持つようになってきました。このような挙動はローカルノートパソコンでは管理可能ですが、エージェントが他の重要なワークロードと Kubernetes クラスターを共有するエンタープライズ環境では、重大なリスクとなります。標準的なコンテナ分離はホストカーネルに依存しているため、エージェントによって悪用されたカーネル脆弱性がノード全体を侵害する可能性があります。

Oracle Cloud Infrastructure (OCI) のプロダクトリーダーである Mickey Boxell と Kay は、技術的な詳細分析の中で、これらのリスクを軽減するための構造化されたアプローチを詳述しました。彼らは、ワークロードの分離がニッチな強化要件から、AI エージェントを実行するプラットフォームにとっての基本的な必須事項へと変化したと主張しています。提案されているソリューションは車輪の再発明を必要とするものではなく、既存のオープンソースコンポーネントを一貫したスタックとして組み合わせるものです。

このフレームワークは、分離ランタイム、ノード設定、アクセスポリシー、Kubernetes リクエストメカニズム、セッション管理レイヤーという5つの異なる層で構成されています。各層に対処することで、プラットフォームチームは自律的なコード実行の影響範囲（ブラスト半径）を制限しつつ、開発者が期待するパフォーマンスと柔軟性を維持できます。

仕組み

この戦略の中核は、適切な分離境界を選択することにあります。標準的な runc コンテナはホストカーネルを共有しており、高いパフォーマンスを提供しますが、セキュリティは低くなります。より強力な分離が必要な場合、チームはシステムコールを処理するためにユーザースペースアプリケーションカーネルを実装する gVisor を使用でき、ホストに公開される攻撃面を削減します。最高レベルのセキュリティが必要な場合、Kata Containers は各ポッドを軽量仮想マシン内で実行し、ハードウェア仮想化によってホストから分離された独自のゲストカーネルを持ちます。これにより、カーネルレベルのエクスプロイトによるコンテナからの脱出を防ぎますが、リソースオーバーヘッドは高くなります。

ランタイムが選択されると、それをサポートするようにノードを設定する必要があります。これには、特定のシムのインストールや、VM ベースのランタイムに対するハードウェア仮想化サポートの確認が含まれます。次に、アクセスレイヤーがサンドボックス内でのエージェントの権限を制限します。これには、デフォルト拒否のネットワークポリシーの適用、短命な認証情報の発行、書き込みアクセスが明示的に必要な場合を除いてデータボリュームを読み取り専用でマウントすることが含まれます。これらのポリシーにより、エージェントが侵害された場合でも、データの流出や外部システムへの損害を与える能力が最小限に抑えられます。

Kubernetes の RuntimeClass オブジェクトを使用すると、ポッドはこれらの分離ランタイムへ動的に参加できます。つまり、非エージェントワークロードはデフォルトの高パフォーマンスランタイムを引き続き使用でき、エージェントタスクは自動的に、より安全だが重い環境を選択します。最後に、Agent Sandbox プロジェクトはセッション管理を標準化し、リソース使用量と応答性のバランスを取るために一時停止および再開が可能なステートフルな環境を実現します。

主要な詳細

• 分離オプション: runc はホストカーネルを共有します。gVisor はユーザースペースカーネルを使用します。Kata Containers は、個別のゲストカーネルを持つ軽量 VM を使用します。
• ノード要件: Kata Containers は、ハードウェア仮想化サポート（KVM）を持つノードを必要とし、VM 上で実行する場合は入れ子状の仮想化機能も必要です。
• アクセス制御: ネットワークポリシーはデフォルトで送信トラフィックを拒否し、パッケージミラーやモデルエンドポイントなど、特定の宛先のみを許可すべきです。
• 認証情報管理: ポッドにマウントされる長寿命のシークレットではなく、特定のタスクにスコープされた短命なトークンを使用してください。
• リソースオーバーヘッド: サンドボックス化されたランタイムは CPU およびメモリのオーバーヘッドを追加します。正確なスケジューリングのために、RuntimeClass 定義には測定されたオーバーヘッド値を含める必要があります。
• セッション管理: Agent Sandbox API は、エージェントインタラクションのバースト的な性質を処理するために、ウォームプールと永続ストレージをサポートします。

なぜ重要なのか

ソフトウェアエンジニアやプラットフォームリーダーにとって、AI エージェントの普及は、従来のコンテナセキュリティモデルがもはや十分ではないことを意味します。任意にコードを実行できるエージェントは、静的スキャンだけでは完全に対処できない動的な脅威ベクトルを表しています。これらの5層を実装することは、予測不可能なエージェントの挙動から基盤インフラストラクチャを保護する多層防御戦略を提供します。

セキュリティとパフォーマンスのトレードオフは、この議論の中心です。Kata Containers は最も強力な分離を提供しますが、ゲストカーネルの起動と追加リソースの管理のコストは、高スループットかつ低遅延のタスクには許容できない場合があります。gVisor は中間的な選択肢を提供しますが、Linux システムコールのエミュレーションは、複雑な入れ子状ビルドや特定のコンパイラ操作など、すべてのエージェント挙動をサポートしない可能性があります。これらのトレードオフを理解することで、チームは固有のリスク許容度とワークロード要件に基づいた informed な意思決定を行うことができます。

さらに、このアプローチは標準的な Kubernetes API を活用しており、異なるクラウドプロバイダーやオンプレミスセットアップ間での移植性を保証します。gVisor、Kata Containers、Agent Sandbox などのコミュニティ主導プロジェクトに依存することで、組織はベンダーロックインを回避し、広範なエコシステムのコントリビューターからの継続的なセキュリティアップデートと設計レビューの恩恵を受けます。

実施できること

• 現在のエージェントワークロードを評価し、バランスの取れたセキュリティのための gVisor と最大限の分離のための Kata Containers の間で、適切な分離レベルを決定してください。
• Kubernetes ノードに必要なランタイムを設定し、VM ベースのサンドボックスを使用する場合はハードウェア仮想化が有効になっていることを確認してください。
• スケジューリング失敗を防ぐために、正確なリソースオーバーヘッド測定値を含めて、各サンドボックス化ランタイム用の RuntimeClass オブジェクトを定義してください。
• すべての送信トラフィックをデフォルトで拒否し、エージェントタスクに必要なエンドポイントのみを明示的に許可する厳格なネットワークポリシーを実装してください。
• 静的なシークレットの使用をやめ、エージェントセッション用に短命でスコープ限定されたトークンを発行するように認証情報管理をリファクタリングしてください。
• ステートフルなエージェントセッションを管理し、ウォームプールを通じてリソース使用量を最適化するために、Agent Sandbox プロジェクトを検討してください。