OpenShellでKubernetes上のAIエージェントを安全に実行する
NVIDIAによるCNCF Sandboxの新規プロジェクト「OpenShell」は、Agent Sandboxとスーパーバイザーベースのポリシー適用を活用し、Kubernetes上のAIエージェントに対して細粒度のランタイム制御を提供します。
英語の原文から自動翻訳されました。
NVIDIAのOpenShellが、Kubernetesクラスター内でAIエージェントを安全に実行するための専用ランタイムとしてCNCF Sandboxに参加しました。2026年後半にリリースされたこのツールは、機密性の高い認証情報を保持しながらシェルコマンドの実行、ファイルアクセス、ネットワーク接続管理を行う自律型エージェントに伴うセキュリティリスクに対処します。SIG AppsのAgent Sandboxプロジェクトと統合することで、OpenShellはプラットフォームエンジニアに対し、標準的なKubernetesオブジェクトへの可視性を犠牲にすることなく、リクエストごとの厳格なポリシー適用を可能にします。
何が起きたか
AIエージェントは、パッケージのインストール、ローカルファイルの読み取り、ネットワークソケットのオープンなど、単純なAPI呼び出しを超えた複雑なタスクを実行できる能力を高めています。これらのエージェントはインターネットから取得した信頼できないデータに基づいて動作することが多いため、実際の認証情報を付与されると重大なセキュリティリスクとなります。OpenShellはすべてのエージェントを信頼できないコードとして扱い、信頼できるスーパーバイザーがすべてのアクションを明示的に承認する隔離されたサンドボックス内で各エージェントを実行するために開発されました。
本プロジェクトはYAMLベースの設定を使用し、4つの特定の制御タイプを宣言します。Landlockによるファイルシステムアクセス、seccompおよび非rootユーザーによるプロセス権限、バイナリとホストごとのネットワークトラフィックルール、そして許可されたエンドポイントでのみプレースホルダーを実際のキーに置き換える認証情報管理です。従来のコンテナセキュリティとは異なり、OpenShellは同じバイナリによる異なるアクション（例えばGitHubへのGETリクエストは許可しつつPOSTリクエストはブロックするなど）を区別でき、再起動なしで稼働中のサンドボックス上のポリシーを更新できます。
Kubernetes管理者にとって、OpenShellは既存のエコシステムツールを活用しており、それらを置き換えるものではありません。独自のスケジューラーは含まず、代わりにAgent Sandboxに依存してエージェント定義をPod、Service、NetworkPolicyなどの標準的なKubernetesリソースに変換します。このアプローチにより、エージェントはkubectl、監査ログ、Kyvernoなどのポリシーエンジンといった既存の運用ツールに対して引き続き可視化されつつ、ネイティブのKubernetesリソースでは提供できない細粒度の制御レイヤーが追加されます。
仕組み
アーキテクチャは、各サンドボックスのライフサイクルを管理するゲートウェイと、特定のエージェントに対するすべての通信を仲介するスーパーバイザーPodを中心に構成されています。ユーザーがOpenShellゲートウェイAPI経由でサンドボックスを作成すると、システムは一時停止状態のAgent Sandboxリソースを生成します。その後、コントローラーは厳格なスケジューリングゲートを備えたワークロードPodを作成し、スーパーバイザーの準備ができるまでアウトバウンドネットワークアクセスが存在しないことを保証します。スーパーバイザーは名前空間とサンドボックスUIDに関連付けられたIDを使用してゲートウェイと認証を行い、ワークロードへの安全なチャネルを確立します。
スーパーバイザーが接続されると、エージェントのコマンドが開始される前に宣言されたポリシーを適用します。エージェントからのすべてのアウトバウンドリクエストはスーパーバイザーによってインターセプトされ、宛先、ポート、呼び出し元バイナリ、HTTPメソッドがアクティブなポリシーに対してチェックされます。リクエストが許可された場合、スーパーバイザーはアップストリーム接続を開きます。拒否された場合、リクエストは即座にブロックされます。このモデルにより動的なポリシー更新が可能になり、変更内容は完全なPodの再起動や一時停止を必要とせず、サンドボックスによって読み込まれ確認されます。
主要な詳細
- OpenShellはSIG Appsの
agents.x-k8s.ioSandboxリソースを使用し、エージェントを標準的なKubernetes PodおよびServiceにマッピングします。 - ファイルシステムの分離はLandlockによって処理され、
/sandboxや/tmpなどの特定のパスへの書き込みアクセスを制限しつつ、システムディレクトリを読み取り専用に保ちます。 - ネットワークポリシーはバイナリごとにトラフィックを検査するスーパーバイザーによって適用され、
curlによる読み取りは許可しつつ書き込みはブロックするといった細粒度のルールが可能になります。 - 認証情報はエージェントに直接公開されることは決してなく、スーパーバイザーは許可されたエンドポイントでのみプレースホルダー値を実際のAPIキーに置き換えます。
- 現時点ではOpenShellサンドボックス用のネイティブKubernetes CRDがないため、作成にはGateway APIを直接呼び出す必要があります。
- デモ環境はKubernetes 1.35、Cilium 1.20、Agent Sandbox v1.0.5、およびアドミッション制御用Kyverno 1.18.2上で稼働しています。
なぜ重要なのか
AI駆動プラットフォームを構築するチームにとって、主な課題はエージェントの自律性とセキュリティコンプライアンスのバランスを取ることです。従来のKubernetes NetworkPolicyはどのPodがどのホストと通信できるかを制限できますが、トラフィックの内容やリクエストを行うアプリケーションの意図を検査することはできません。OpenShellはアプリケーション認識型のポリシー適用を提供することでこのギャップを埋め、コンテナランタイムが侵害された場合でも、エージェントが誤ってまたは悪意を持ってデータを外部流出させたり、本番システムを変更したりできないようにします。
さらに、OpenShellは既存のKubernetes運用ワークフローとの互換性を維持します。エージェントは標準的なPodおよびServiceとして表示されるため、プラットフォームエンジニアはまったく新しい観測性スタックを学ぶ必要がありません。ロギング、モニタリング、ロールベースアクセス制御のために慣れ親しんだツールを引き続き使用しつつ、自律型エージェントの微妙なセキュリティ要件についてはOpenShellに任せることができます。これにより、監査可能性と最小権限アクセスが必須となるエンタープライズ環境においてAIエージェントを採用する際の運用オーバーヘッドが削減されます。
実施可能なこと
- クラスター内でイングレスおよびエグレスのNetworkPolicyが効果的に適用されるよう、CNIとしてCiliumをインストールしてください。
- 必要なインフラストラクチャを確立するため、OpenShellゲートウェイHelmチャートをインストールする前にAgent SandboxコントローラーとCRDsを展開してください。
- サンドボックスイメージ、リソース制限、RBACルールに対するアドミッション制御を適用するために、Kyvernoまたは同様のポリシーエンジンを使用してください。
- エージェント活動の管理および監査を容易にするため、OpenShellでワークスペースを定義し、サンドボックス、ポリシー、ログをグループ化してください。
- 動的なルール変更がエージェントの実行を中断せずに適用されることを検証するため、稼働中のサンドボックスでポリシー更新をテストしてください。
- 大規模環境向けのKubernetesネイティブCRDsサポートや柔軟な展開オプションに関する今後の計画を確認するため、OpenShellロードマップを見てください。
