sandboxのcontrol planeはruntime種別から分離しておく
sandbox platformを作るとき、control planeが特定のruntime実装に直接依存すると、後からthreat modelや運用要件を変えにくい。
process sandbox、通常container、gVisor、VM/microVMでは隔離方式が大きく異なるが、上位から必要になるlifecycle操作には共通部分が多い。
例えば、概念上は次の操作に分けられる。
- create
- start
- stop / suspend
- exec
- attach PTY
- expose port
- snapshot / clone
- destroy
ここで「Docker containerを作る」「Firecracker APIを呼ぶ」といった実装詳細を上位APIに漏らさず、Environment/Sandboxというresource modelに寄せておくと、用途に応じてbackendを変えやすい。
ただし、すべてのruntimeに同じcapabilityがあるわけではない。例えばLandlock-based process sandboxにはguest memory snapshotはなく、Firecracker snapshotにはnetwork connection stateの制約がある。したがって、共通interfaceを最小公倍数にしすぎるより、runtime capabilityを明示的に問い合わせられる設計の方がよい。
例としては次のようなcapabilityが考えられる。
- kernel isolation
- OCI image support
- persistent filesystem
- process-state suspend/resume
- snapshot/clone
- GPU passthrough
- network policy
- nested container support
Kubernetes Agent SandboxがSandboxという上位primitiveとRuntimeClassによる下位runtime選択を分けているのも、この方向の一例として見られる。Kubernetes Agent Sandboxはstateful singletonをSandbox CRDにする
実際のruntime候補については Linuxサンドボックスの隔離境界をどう捉えるか、container/VM選択は AIエージェント用sandboxでcontainerとVMをどう選ぶか、processとenvironmentのlifecycle分離は AI実行環境ではenvironmentとterminal sessionを分けて考える を参照。