Docker सैंडबॉक्सेस – AI एजेंटों के लिए डिस्पोज़ेबल, आइसोलेटेड सैंडबॉक्स
Docker की नई Sandboxes feature का लक्ष्य AI coding agents को disposable microVMs के अंदर चलाना है, outbound firewalls और credential-injection के साथ, ताकि untrusted tools developer की machine या secrets तक खुलकर पहुँच न सकें। टिप्पणीकार पारंपरिक containers की तुलना में मजबूत isolation का स्वागत करते हैं, लेकिन mandatory Docker login, closed-source tooling, और सीमित Linux support की कड़ी आलोचना करते हैं, यह कहते हुए कि इससे trust और long-term viability कमज़ोर होती है। कई लोग open-source VM- और container-based sandboxes के बढ़ते ecosystem की ओर इशारा करते हैं, और कुछ अपनी विशेष workflows और threat models के लिए खुद के समाधान “vibecode” करना पसंद करते हैं।
Docker सैंडबॉक्स वास्तव में क्या हैं
- कई टिप्पणीकार स्पष्ट करते हैं कि यह साधारण Docker container setup नहीं है।
- हर agent/session host hypervisor (Hypervisor.framework, WHP, KVM) पर एक microVM (libkrun-शैली, अपना kernel) में चलता है।
- यह plain containers की तुलना में अधिक मजबूत isolation देता है और agent को sandbox के अंदर Docker चलाने देता है, बिना host को compromise किए।
Security Model: VMs vs Containers vs OS Sandboxes
- कई लोगों का तर्क है कि untrusted AI agents को host के साथ kernel share नहीं करना चाहिए; cgroups-आधारित containers की तुलना में VMs/microVMs को प्राथमिकता दी जाती है।
- अन्य लोग जवाब देते हैं कि unprivileged containers ज़्यादातर developers के लिए “good enough” हैं, और escapes अधिकतर 0-days और खराब configurations से जुड़े होते हैं।
- कुछ layered defenses का उपयोग करते हैं: VM + अंदर containers + outbound firewalls + सीमित mounts।
- bubblewrap, nono, gVisor, libkrun, Kata Containers, Incus/LXC, Flatpak, आदि जैसे वैकल्पिक sandboxing primitives पर सक्रिय चर्चा है।
Login Requirement, Closed Source, and Governance
- local dev tool के लिए mandatory Docker login व्यापक रूप से नापसंद किया गया है।
- कुछ इसे “garbage” UX मानते हैं और भविष्य में paywalls/limits या rug pulls की आशंका जताते हैं।
- centrally sandbox policies लागू करने के लिए एक enterprise “AI Governance” product है।
Credentials Injection & Network Controls
- proxy boundary पर credential injection (secrets host keychain में stored, और केवल matching hostnames/headers के लिए inject) एक standout feature माना गया है।
- इस बात पर बहस है कि यह clever exfiltration attempts के खिलाफ कितना robust है; कुछ लोग secret को agent तक वापस reflect करने के तरीकों को लेकर चिंतित हैं।
- Outbound firewalling / deny-by-default network policies को महत्व दिया जाता है; कुछ alternatives समान controls लागू करते हैं।
Linux Support & Platform Gaps
- Linux support को लेकर भ्रम और निराशा है: marketing page में शुरुआत में इसका उल्लेख नहीं था, जबकि docs और release artifacts दिखाते हैं कि Ubuntu और कुछ RPM-based distros समर्थित हैं।
- कुछ लोग शिकायत करते हैं कि यह सभी Linux distributions या architectures पर व्यापक रूप से उपलब्ध नहीं है।
DIY and Open Source Alternatives
- बहुत से users ने अपने स्वयं के sandboxes बनाए हैं (QEMU/KVM, Firecracker-like microVMs, Incus, devcontainers, bubblewrap, Apple Container, Tart, podman+libkrun, आदि)।
- कई लोग OSS projects का लिंक देते हैं जो microVM-based agents, credential proxies, outbound firewalls, या बेहतर DX प्रदान करते हैं।
- कई लोग कहते हैं कि वे proprietary, login-gated tool के बजाय open, self-controlled setups में निवेश करना पसंद करते हैं।