サンドボックスの異なるアプローチの比較

ソフトウェアエンジニアであれ、プロダクトマネージャーであれ、デザイナーであれ、この名言は私たちの日々のルーティンへのアプローチを根本的に変えるはずです。もはや単にインターフェースを構築するだけではありません。エージェントが最小限の人間の関与で自律的に動作できる環境を創り出しています。そのような環境の根本的な要件は何でしょうか?

一言で言えば:孤立。

従来のソフトウェアとやり取りするユーザーは、そのソフトウェアが許す操作によって制約を受けます。しかしエージェントは非決定論的であり、幻覚や迅速な注射に陥りやすい。一度AIに書き込み権限を与えれば、AIがすべてのデータを削除する rm -rf を実行するのを妨げるものはありません。もちろん、この問題を解決する方法はいくつかあり、その一つはサンドボックスです。これは、周囲のシステムに影響を与えない実験やテストに用いられる隔離された管理された環境です。

そこで、エージェントをサンドボックス化するさまざまな戦略を模索し始めました。最低限のセットアップからクラウドVMのセットアップまで進めていきます。各段階で学んだことは以下の通りです。

1。まずはベースラインから始めましょう

Chrootはファイルシステムの分離を実現する伝統的な方法でした。特定の制限付きディレクトリがマシンの絶対ルートであると認識させたい場合にうまく機能します。

しかし、2つの大きな注意点があります。

1. chroot内のプロセスにルート権限があれば、問題が発生した可能性があります。
2. ファイル分離は可能ですが、プロセス分離は依然として問題です。悪意のあるエージェントは、システム上で他のプロセスが動いているのを見て、それらを殺そうとすることもあります。

上の通り、 ls /proc をしてもホスト上で動作しているすべてのプロセスが表示されます。

そこでsystemd-nspawn、別名「chrooton steroids」について知りました。chrootとsystemd-spawnの違いは、後者がファイルシステムに加えてネットワークレベルやプロセスレベルでの隔離を提供している点です。

今、同じ ls /proc を systemd-nspawn mybox containerで行うと、 mybox コンテナ内のプロセスがプロセスレベルの分離を達成しているのが見えます。

メリット

1. Dockerなど他のコンテナプロセスと比べて軽量で、起動時間も速いです。
2. Linuxでのネイティブサポート。

注意事項

1. systemd-nspawn Linuxに深く関わっていない限り、開発者コミュニティではあまり人気がありません。
2. Linuxではうまくいきますが、もしWindowsでエージェントを動かす必要がある場合はどうすればいいのでしょうか?プラットフォームによっては代替案を探す必要があります。

2。コンテナだけで十分でしょうか?

孤立した環境を考えると思い浮かぶもう一つの技術はDockerです。そして、これまでに話した概念とは異なり、Dockerはより広範なエコシステムと強力なコミュニティを持っています。

コンテナを使うと、分離されたファイルシステム、ネットワークインターフェース、プロセスツリーも得られます。また、Mac、Windows、Linuxをまたぐクロスプラットフォーム対応も備えています。これらの利点により、異なるプラットフォーム間でエージェントを作成・運用することが非常に容易になり、コンテナが明白な選択肢となります。

しかし、コンテナがエージェントの開発プラットフォームになると、モデルはより複雑になります。多くの場合、エージェントは生成されたコードを別々の環境で実行する必要があり、実際には必要に応じて新しいDockerコンテナを立ち上げることになります。これにより、コンテナ内コンテナ(Docker-in-Docker)パターンが導入され、コンテナ内で動作するエージェントが他のコンテナを構築・実行する必要があります。 

Docker-in-Dockerを動作させるには、コンテナを特権モード(--privileged)で実行し、これによりコンテナプロセスに権限が付与され、隔離性が大幅に弱まります。この時点で、隔離の保証は大幅に低下します。その結果、コンテナのみを使用するエージェントの完全な隔離は難しくなります。

3。仮想マシンは役に立ちますか?

ご想像の通り、仮想マシン(VM)は最も強力な隔離を提供します。VMがあれば、自分専用のOS、ファイルシステム、ネットワーク全体を手に入れることができます。例えば、私は現在Limaと共にMacOSを運用しています 。Linux VM はLinux専用のワークロードを動かすためです。

しかし、そのトレードオフとしてVMのスピンアップはコストがかかります。そして、もしこれをすべてのエージェントに適用しなければならないなら、スケーラブルではありません。system-nspawnでVMを起動するコストを示す統計もあります。

例えば、以下のスクリーンショットでは、LimaのVMを稼働させるコストがわかります。

4。MicroVMが救いに出てきます

MicroVM(マイクロ仮想マシン)は、孤立問題の完璧な答えのように感じられました。では、MicroVMとは何で、何が優れているのでしょうか?

MicroVMは、従来のVMと同等のセキュリティと隔離性、さらにコンテナの高速さを提供する軽量な仮想化技術です。

1. 強力なセキュリティと隔離が可能になるのは、MicroVMが独自のカーネル(ゲストカーネル)を持つためです。コンテナは共有カーネルを使用します。そのため、ゲストOS内での侵害はホストや他のVMに直接影響しません。
2. 速度:従来のVMとは異なり、最小限のハードウェア(USBやPCIバスなし)でプロビジョニングされており、BIOS/UEFIの起動をバイパスするため、デバイスのエミュレーションオーバーヘッドや起動遅延を大幅に削減します。

Amazonは 2018年にFirecrackerをオープンソース化し、これはMicroVMアーキテクチャの最も初期の採用でした。これによりMicroVMアーキテクチャの促進には寄与しましたが、FirecrackerはLinux環境に限定されていました。そして、ほとんどのエージェントのオーケストレーションは、MacOSやWindowsを搭載した開発者のノートパソコンで行われることが多いです。

Dockerはこのギャップをサン ドボックス で埋めました。最も素晴らしいのは、macOS、Windows、Linuxでネイティブに動作するMicroVMベースのアーキテクチャで、より優れた隔離性、より速い起動時間、そしてよりスムーズな開発者体験を実現していることです。このことについては後ほど詳しく説明します。

5。gバイザー

gVisorは孤立問題を解決するために独自のアプローチを採用しています。従来の戦略でOSカーネルが使われていたのに対し、gVisorはユーザー空間で動作する「アプリケーションカーネル」と呼ばれる独自のカーネルを作成します。

標準的なコンテナ化アプリがファイルを開いたり、メモリを割り当てたり、ネットワークトラフィックを送信したりしたい場合、ホストのLinuxカーネルに直接「システムコール」(syscall)を行います。

gVisorでは、アプリにはSentryというコンポーネントがバンドルされています。

1. Sentryはアプリケーションが行うすべてのシステムコールを傍受します。
2. Linuxネットワーク、ファイルシステム、メモリ管理の独自の実装を用いて、ユーザースペースでそのリクエストを処理します。
3. もしSentryがホストカーネルに何か(実際のディスクI/Oなど)を絶対に必要とする場合、そのリクエストを非常に制限され、厳重にフィルタリングされた安全な呼びかけに変換します。

しかし、systemd-nspawnと同じ問題を抱えています。広いコミュニティのサポートはあまりなく、Linuxのみをサポートしています。

Docker サンドボックス

Docker Sandboxでは、AIコーディングエージェントは隔離されたmicroVM環境で動作します。パフォーマンスはホスト上で動作するのとほぼ同じで、隔離とセキュリティが大幅に強化されています。 これにより、ホストの侵害や意図しないローカル環境へのアクセスを心配せずに自律エージェントを運用できます。 

Sandboxは3つの隔離層によってこのレベルのセキュリティを実現しています。

ハイパーバイザーの隔離: すべてのサンドボックスには独自のLinuxカーネルがあります。したがって、サンドボックスカーネルに影響を与えるものはホストや他のサンドボックスカーネルには影響しません。

ネットワーク分離

• 各サンドボックスは独自の孤立したネットワークを持っています。つまり、複数のサンドボックスが互いに、またホストと通信できないということです。
• さらに、ネットワークポリシーはソースからのトラフィックを許可または拒否する形で強制できます。

Docker Engine Isolation

• これが私がこの新しい建築に惚れ込んだ理由です。すべてのサンドボックスには独自のDockerエンジンが割り当てられています。その結果、エージェントが docker pull や docker composeを実行するたびに、それらのコマンドは外部のDockerデーモンではなく内部エンジンに対して実行されます。
  
• そのため、内部で動作するエージェントはサンドボックス内のDockerサービスしか見ることができず、追加のセキュリティ層が加わります。

Docker Engineの分離を示すために、2つのサンドボックスセッションを作成し、1つでDocker hello-world コンテナイメージを実行し、さらに両方で docker ps -a を実行しました。

以下のスクリーンショットからもわかるように、一方のセッションは hello-world コンテナを持ち、もう一方はそうではありません。これは両者とも異なるDockerエンジンのデーモンを動かしているため可能です。

サンドボックスアーキテクチャの詳細はこちら: https://www.docker.com/blog/why-microvms-the-architecture-behind-docker-sandboxes/

結論

一つだけ教訓があるとすれば;それはこうです。 自律型AIエージェントを構築する際には、セキュリティ ミスの爆発範囲が大きいため、隔離が重要な役割を果たします。 

これまで探ってきたそれぞれのアプローチは、隔離のパズルの異なる部分を解いています。コンテナは移植性と開発者体験を向上させますが、共有カーネルのリスクを引き継ぎます。仮想マシンは強力な隔離を提供しますが、多数のエージェントを起動させるとオーバーヘッドはスケールしません。gVisorは興味深い中間点にありますが、互換性やコミュニティのトレードオフが遅くなるかもしれません。

これらすべての中で、 MicroVMを用いたDocker Sandbox の魅力は、VMレベルのセキュリティ、コンテナのような起動速度、そして開発者がすでに知っているワークフローというこれらの側面を統合している点にあります。サンドボックスごとのDockerエンジンと厳格なネットワーク境界により、信頼できない自律的なワークロードを大規模に運用するための強固な基盤となっています。

さあ、何を待っているのですか?ぜひ今日試してみてください。

macOSの場合: brew install docker/tap/sbx

Windows用: winget install Docker.sbx