AIエージェント用sandboxでcontainerとVMをどう選ぶか
AIエージェントがcode executionを行う環境では、「containerかVMか」は性能だけではなく、何をsecurity boundaryとして信頼するかで決めるべきである。
containerが向く場合
自分自身や同一組織内のtrusted repositoryを主に扱い、host kernel共有を許容できるなら、通常containerは実装・運用上かなり有利である。
- OCI imageをそのまま利用しやすい
- toolchainやdependencyをimage化しやすい
- 起動が軽い
- volume、network、resource limitの既存ecosystemが成熟している
ただしnamespaceで環境を分けても、workloadはhost Linux kernelのsystem call実装を直接利用する。任意のrepository、dependency install script、生成コードまで実行する場合、このhost kernel共有をどこまで信頼するかが問題になる。
VMが向く場合
互いに信頼しないtenantを収容する、外部から持ち込まれた任意コードを実行する、あるいはhost kernelを直接attack surfaceに含めたくない場合は、guest kernelを持つVM/microVMの方がthreat modelを説明しやすい。
OCI/Kubernetesの操作体系を保ちたいなら Kata Containers 4.0はOCI UXのままVM境界を使う、microVMやsnapshot lifecycleまで自前で制御したいなら Firecracker snapshotは状態を持つsandbox再開に向く が代表例になる。
中間解もある
二択ではなく、gVisorはユーザー空間カーネルでhost kernel syscall面を減らす のようにuserspace kernelを挟み、OCI compatibilityを保ちながらhost kernelへの直接system call面を減らす選択肢もある。
また、自分自身のprocessの権限を軽量に削る用途なら Landlockは非特権プロセス自身が権限を削るLSM や SandlockはLandlockとseccompを組み合わせた軽量プロセスsandbox のような方式もある。
したがって実際には、次の順で決める方がよい。
- threat modelを決める
- host kernel共有を許容できるか決める
- 必要なLinux compatibilityを確認する
- sandbox数・起動頻度・idle時間を見積もる
- snapshot/suspend/resumeの必要性を確認する
- その後でcontainer、gVisor、VMを選ぶ
「sandbox」という語だけで安全性を比較せず、隔離境界を見るという考え方は Linuxサンドボックスの隔離境界をどう捉えるか にまとめた。