- microsandbox มอบการรันโค้ดจากผู้ใช้และ AI ที่ไม่น่าเชื่อถือได้อย่างปลอดภัยด้วย การแยกระดับเครื่องเสมือน
- มีจุดเด่นอย่าง การบูตที่เร็วมาก (ต่ำกว่า 200ms), ความเข้ากันได้กับคอนเทนเนอร์ OCI, และการโฮสต์เอง ซึ่งช่วยแก้ข้อจำกัดของ VM และคอนเทนเนอร์แบบเดิม
- เพิ่มประสิทธิภาพการผสานรวมสำหรับนักพัฒนาและเครื่องมือ AI ให้สูงสุดด้วย SDK สำหรับหลายภาษาโปรแกรมและเครื่องมือ CLI
- เหมาะกับกรณีใช้งานด้าน AI และการพัฒนาที่หลากหลาย เช่น การรันโค้ด, สภาพแวดล้อมการพัฒนา, การวิเคราะห์ข้อมูล, เว็บอัตโนมัติ, และการโฮสต์แอป
- สามารถจัดการทุกงานแบบอิงโปรเจกต์ และรองรับการติดตั้งทั้งระบบ รวมถึงการคงอยู่ของเซสชัน/สภาพแวดล้อมการรันแบบแยกส่วน
- microsandbox เป็น แพลตฟอร์มโอเพนซอร์สแบบโฮสต์เอง ที่ออกแบบมาสำหรับการรัน โค้ดจากผู้ใช้หรือโค้ด AI ที่ไม่น่าเชื่อถือ อย่างปลอดภัย (เช่น AI agent, โค้ดที่ผู้ใช้ส่งเข้ามา, หรือโค้ดทดลอง)
- การรันแบบโลคัลทั่วไปมีปัญหาด้านความปลอดภัย, คอนเทนเนอร์มีการแยกที่ไม่สมบูรณ์เพราะใช้เคอร์เนลร่วมกัน, VM แบบดั้งเดิมบูตช้า, และคลาวด์ก็มีข้อจำกัดด้านความยืดหยุ่น
- microsandbox รองรับ การแยกโปรเซสอย่างแท้จริงบนพื้นฐานของ microVM (เครื่องเสมือนน้ำหนักเบาพิเศษ) พร้อมมอบทั้งความเร็วเริ่มต้นระดับคอนเทนเนอร์และประสบการณ์ที่เป็นมิตรต่อนักพัฒนา
- โดดเด่นด้วย การบูตภายใน 200ms หลังตั้งค่าสภาพแวดล้อมเริ่มต้น, ความเข้ากันได้กับอิมเมจคอนเทนเนอร์ (OCI), การผสานรวม AI บนพื้นฐาน MCP, และการควบคุมการใช้งานบนโครงสร้างพื้นฐานของตนเอง
สรุปคุณสมบัติหลัก
- Bulletproof Security: ใช้ microVM เป็นพื้นฐาน มอบ ความปลอดภัยระดับเครื่องเสมือน ที่ป้องกันช่องโหว่ของคอนเทนเนอร์ (เช่น kernel escape) ได้ตั้งแต่ต้นทาง
- Instant Startup: ใช้เวลาเริ่มต้นบูตต่ำกว่า 200ms ทำให้เริ่มรันโค้ดได้เร็วมากเมื่อเทียบกับ VM ทั่วไป
- Self-Hosting & Full Control: สามารถ ติดตั้งและใช้งานบนเครื่องโลคัลหรือเซิร์ฟเวอร์ของตนเองได้โดยตรง โดยไม่ต้องพึ่งคลาวด์
- เข้ากันได้กับ OCI: สามารถรันอิมเมจคอนเทนเนอร์มาตรฐานได้ทันที จึงเข้ากันได้กับเวิร์กโฟลว์ Docker/คอนเทนเนอร์เดิม
- AI-Ready (รองรับ MCP) : สามารถ ผสานรวมและขยายการทำงานได้อย่างเป็นธรรมชาติ กับ AI ที่ใช้ MCP เช่น Claude และ Agno
เวิร์กโฟลว์การพัฒนาและรันที่รวดเร็ว
1. เริ่มต้นเซิร์ฟเวอร์
- สามารถเริ่มเซิร์ฟเวอร์ microsandbox และตั้งค่าสภาพแวดล้อมการพัฒนาได้ด้วยคำสั่งง่าย ๆ
- เซิร์ฟเวอร์ยังทำหน้าที่เป็น MCP server ด้วย จึงเรียกใช้งานโดยตรงจากเครื่องมือ AI อย่าง Claude ได้
2. ติดตั้ง SDK
- มี microsandbox SDK สำหรับภาษาหลักอย่าง Python, JavaScript, Rust
- รองรับภาษาเพิ่มเติมได้หลากหลาย (มีความยืดหยุ่นในการขยาย SDK) ทำให้มีศักยภาพในการผสานรวมกับนักพัฒนาและ AI อย่างกว้างขวาง
3. รันโค้ดอย่างปลอดภัย
- สามารถเลือกและรันสภาพแวดล้อมแซนด์บ็อกซ์แยกตามภาษา เช่น Python, JavaScript, Rust
- แซนด์บ็อกซ์แต่ละตัวเป็นสภาพแวดล้อมอิสระ ช่วยรับประกันความปลอดภัยของระบบแม้ต้องรันโค้ดจากภายนอก
- ตัวอย่าง SDK ช่วยให้สร้างกระบวนการรันโค้ดอย่างปลอดภัยแบบอะซิงก์และอัตโนมัติได้ง่าย
การจัดการสภาพแวดล้อมแบบอิงโปรเจกต์
- สร้างและจัดการ Sandboxfile (ไฟล์ตั้งค่า) ในระดับโปรเจกต์ โดยมีเวิร์กโฟลว์คล้ายแพ็กเกจเมเนเจอร์ที่เป็นมิตรต่อนักพัฒนา
- สามารถเพิ่มสภาพแวดล้อมแซนด์บ็อกซ์หลายแบบ (เช่น ภาษาและการตั้งค่าที่ต่างกัน) เข้าในโปรเจกต์เพื่อจัดการตามเวอร์ชัน/สภาพแวดล้อมได้
- เมื่อรันโปรเจกต์แซนด์บ็อกซ์ การเปลี่ยนแปลงไฟล์และการติดตั้งจะถูกเก็บไว้ในไดเรกทอรีโลคัล (./menv) โดยอัตโนมัติ
- มีตัวเลือกเปิดใช้แซนด์บ็อกซ์ชั่วคราว (ลบประวัติและสถานะทั้งหมดอย่างสมบูรณ์เมื่อจบเซสชัน พร้อมแยกสภาพแวดล้อม)
การติดตั้งแซนด์บ็อกซ์แบบทั้งระบบ
- สามารถติดตั้งและลงทะเบียนสภาพแวดล้อมหรือแอปที่ใช้บ่อยให้เป็นไฟล์รันแยกต่างหากได้
- เข้าสู่สภาพแวดล้อมแซนด์บ็อกซ์ได้ทันทีจากเทอร์มินัลด้วยคำสั่งบรรทัดเดียว แม้ไม่มีพาธโปรเจกต์
- สามารถตั้งชื่อให้แต่ละแซนด์บ็อกซ์และใช้งานหลายชุดที่มีการตั้งค่าต่างกันได้ โดยสถานะของเซสชันก็ยังคงอยู่ต่อเนื่อง
กรณีใช้งานหลัก
การรันโค้ด AI และสภาพแวดล้อมการพัฒนา
- เมื่อ AI ทำงานอัตโนมัติตั้งแต่การบิลด์ รัน ไปจนถึงดีบักซอร์สโค้ดจริง สามารถจัดเตรียมสภาพแวดล้อมการพัฒนาที่แยกส่วนและทำซ้ำได้อย่างรวดเร็ว
- เหมาะกับงานอัตโนมัติเกี่ยวกับโค้ด เช่น การสร้างเว็บแอป การแก้บั๊ก และการทำต้นแบบ
การวิเคราะห์ข้อมูล
- ใช้งานไลบรารีด้านวิทยาศาสตร์ข้อมูลหลักอย่าง NumPy, Pandas, TensorFlow ภายในแซนด์บ็อกซ์ได้อย่างปลอดภัย
- เหมาะอย่างยิ่งกับเวิร์กโฟลว์การวิเคราะห์ที่ต้องปกป้องข้อมูลส่วนบุคคลหรือข้อมูลอ่อนไหว
เอเจนต์ท่องเว็บ
- ให้ AI ทำงานอัตโนมัติอย่างปลอดภัย เช่น ท่องเว็บไซต์ ส่งฟอร์ม ล็อกอิน และครอว์ลข้อมูล
- มีประโยชน์กับงานอย่างการเก็บคอนเทนต์ การเปรียบเทียบราคา และการทดสอบอัตโนมัติ
การโฮสต์แอปแบบทันที
- ผู้ใช้สามารถแชร์เครื่องมือ เดโม เครื่องคิดเลข หรือการแสดงผลภาพที่สร้างขึ้นเป็นบริการได้ทันที
- แต่ละแอปทำงานในพื้นที่แยกเฉพาะ พร้อมรองรับการสร้างและยุติสภาพแวดล้อมชั่วคราวได้อย่างรวดเร็ว
โครงสร้างระบบ
- ผู้ใช้เรียกใช้ microsandbox SDK จาก บิสิเนสลอจิก ของตนเอง
- ส่งคำขอไปยังโปรเซสเซิร์ฟเวอร์ (microsandbox server) เพื่อ ส่งต่อและรันโค้ดที่ไม่น่าเชื่อถือ
- ภายในเซิร์ฟเวอร์ คำขอรันแต่ละรายการจะทำงานใน microVM แยกจากกัน จึงไม่รบกวนกัน
- แต่ละ microVM สามารถตั้งค่าสภาพแวดล้อม Python/Node แบบอิสระได้
นโยบายโอเพนซอร์ส
- เผยแพร่เป็นโอเพนซอร์สภายใต้ Apache License 2.0
1 ความคิดเห็น
ความเห็นจาก Hacker News
ถ้าทำแบบนี้ คอนเทนเนอร์ที่อาศัยแค่ permission หรือ jail ก็น่าจะได้ใกล้ 0%, Docker อาจเกิน 50%, และ Microsandbox อาจเข้าใกล้ 100%
น่าจะช่วยคลายความสงสัยเชิงสัญชาตญาณต่อคำถามอย่าง “ทำไมไม่ใช้ jail ไปเลย” ได้
อีกอย่าง ถ้าเอา honeypot container ไปเปิดไว้บนเว็บสาธารณะ แล้วถ้าแฮ็กสำเร็จก็ให้รางวัลเป็นเงินสดหรือเหรียญ ก็น่าจะเป็นวิธีที่สนุกในการ “พิสูจน์” ว่าคอนเทนเนอร์ไหนไปถึง 100% ได้จริง
ช่วงหลังมานี้มีช่องโหว่อย่าง Rowhammer หรือ Spectre ที่ทำให้ต้องนิยามความปลอดภัยของการประมวลผลแบบดั้งเดิมและคลาวด์กันใหม่ด้วย
ท้ายที่สุด แรงจูงใจก็คืออยากได้ insight เกี่ยวกับการพัฒนาคอนเทนเนอร์ที่ปลอดภัย 100% โดยไม่ต้องพึ่ง full emulation และการทำให้บริการพื้นฐานของ OS ปลอดภัยขึ้น
เพราะถ้ามีช่องโหว่ kernel LPE (Local Privilege Escalation) ก็เท่ากับนำไปสู่การ escape จากคอนเทนเนอร์ได้ทันที
ปกติอาจไม่ได้ถูกนับว่าเป็น container escape โดยตรง แต่ในวงการ ถ้าบอกว่ามี kernel LPE ก็ถือว่าความปลอดภัยของคอนเทนเนอร์พังแล้วโดยปริยาย
ทางเลือกที่พอจับต้องได้คือจำกัดการใช้ system call (API) ภายใน sandbox อย่างหนัก แต่ถ้าทำแบบนั้นคอนเทนเนอร์ก็จะไม่ใช่แพลตฟอร์มอเนกประสงค์อีกต่อไป และต้องมานั่งปรับจูนใหม่เป็นกรณี ๆ ไปทุกครั้ง
เพราะงั้นจึงมองว่าจำเป็นต้องใช้ virtualization
จนกว่าจะมี OS ที่ทั้ง memory-safe และแข็งแกร่งจริง ๆ ก็คงมีแต่วิธีนี้ และถึงจะมี OS แบบนั้นออกมา ก็ยังไม่แน่ว่าจะเร็วกว่าการรัน MicroVM บน host Linux หรือไม่
เพราะใน Docker หรือ systemd ระดับความปลอดภัยต่างกันมากตามการตั้งค่าหลากหลายแบบ
คิดว่าน่าจะต้องมีชุดข้อมูลการทดลองขนาดใหญ่ที่ชี้ให้เห็นว่าการตั้งค่าแบบไหนนำไปสู่ระดับความเสี่ยง/ความปลอดภัยแบบใด
ในโลกความเป็นจริง production environment เองก็เป็นเป้าการโจมตีของแฮ็กเกอร์จำนวนมาก
โมเดลแรงจูงใจแบบนี้อาจจะสนุกดี แต่ในทางปฏิบัติ ความน่าสนใจของเป้าหมายและแรงจูงใจทางการเงินก็คงยังน้อยกว่าสภาพแวดล้อมจริงมาก
ยกตัวอย่างเช่น เวลารัน VM บน Windows มักต้องรอหลายวินาทีกว่าจะเริ่มมีอะไรเกิดขึ้น
ที่บอกว่า “ยังไม่มีอะไรทำงาน” หมายถึงก่อนรันโปรแกรมผู้ใช้ และก่อนแม้แต่คำสั่งแรกของเฟิร์มแวร์จะเริ่มทำงาน
บางครั้งยังมีช่วงที่ต้องรอนานก่อนการล้างไฟล์ virtual disk หรือแม้กระทั่งก่อนหน้าต่าง VM จะโผล่มาด้วยซ้ำ
อยากรู้ว่าเพราะอะไร
แต่ถ้าเป็น kernel มาตรฐาน จะมีพฤติกรรมที่กินเวลาไม่น้อย เช่น timeout หรือ polling
ในระบบ UEFI/CSM ก็ยังต้องใช้เวลาพอสมควรไปกับการเตรียม virtual hardware และการ initialize system environment
คาดว่า WSL2 ใช้ kernel พิเศษที่ตัด overhead ที่ไม่จำเป็นออกไป
การสตาร์ตบริการต่าง ๆ ของ OS, การเตรียม filesystem, การเตรียม cache, การตั้งค่า network ก็ล้วนมีผล
วิธีแบบดั้งเดิมคือโหลด bootloader → initramfs → main OS แยกกันทีละส่วน
ถ้าจะลด boot time แบบสุด ๆ ก็ใช้วิธีแบบ Amazon Firecracker ที่เอาอิมเมจ VM ที่ initialize ไว้ล่วงหน้าโหลดเข้าหน่วยความจำโดยตรง
แนะนำ Firecracker MicroVM
บน Windows ความเร็วบูตก็ต่างกันไปตาม hypervisor ที่ใช้ เช่น HyperV
UEFI ของ HyperV ค่อนข้างช้า และ Linux distribution หลายตัวก็ไม่ได้มี minimal kernel ที่ปรับแต่งมาโดยเฉพาะ
ถ้าเป็น VirtualBox อาการที่ถามมาจะเห็นชัดมาก และในเวอร์ชันเก่า ๆ ก็ไม่ได้มีดีเลย์แบบนี้
เลยอาจไม่ใช่ข้อจำกัดเชิงแก่นของ “VM แบบดั้งเดิม” แต่เป็นปัญหาเฉพาะของซอฟต์แวร์นั้น
โดยทั่วไป VM จะช้าเพราะจำลององค์ประกอบที่ไม่จำเป็นด้วย
ถ้าสร้าง hypervisor โดยเน้นความเร็วในการบูตและยอมละทิ้งความเข้ากันได้กับระบบเก่า ก็สามารถบูตใน 125ms แบบ Firecracker ได้
ถ้าจัดสรรเป็นหน่วย 1GB ก็อาจเร็วขึ้นอย่างมาก
Windows ก็น่าจะมีกลไกคล้ายกัน
ส่วนตัวเคยใช้ Hyper-V แล้วเข้า Ubuntu 22 GUI ผ่าน XRDP ได้ใน 10 วินาที และเข้า Ubuntu 22 server ผ่าน SSH ได้ภายใน 3 วินาที
ถึงอย่างนั้น ไอเดียหลักเองก็น่าสนใจมาก
เร็ว ๆ นี้น่าจะมีวิธีแจกจ่ายอย่างเป็นทางการ
เป้าหมายคือทำให้สร้าง microVM ได้ง่ายเหมือน Docker container
ถ้ามีคำถามก็ยินดีตอบเสมอ
บางครั้งเจอ error อย่าง “Sandbox is not started. Call start() first”
รูปแบบในเอกสารทางการคือ
async withแต่รูปแบบการใช้งานของผมคืออยาก instantiate แค่ครั้งเดียวต่อคลาส แล้วใช้ต่อเนื่องจากหลายเมธอดเลยอยากรู้ว่ามีวิธีแนะนำหรือ best practice สำหรับกรณีนี้ไหม
อยากรู้ว่า networking ทำงานอย่างไร
เช่น จำกัดให้ microVM เข้าถึงได้เฉพาะ public IP ได้ไหม?
กล่าวคือทำให้ microVM เข้าถึง local network IP ไม่ได้หรือเปล่า
อยากรู้ว่าความสามารถ MicroVM ที่มีมาในตัวรองรับ OCI runtime interface หรือไม่
ใช้กับ Docker/Podman แทน runc/crun ได้ไหม
มันเร็วได้อย่างไร?
เมื่อเทียบกับ VM แบบดั้งเดิมมี trade-off อะไรบ้าง?
มีช่องทางไหนที่อาจทำให้การแยกกันของ VM ถูกลดทอนลงไหม?
เปิด GUI ได้หรือเปล่า?
มองว่ามันคือ Vagrant ตัวใหม่หรือไม่?
รับส่งข้อมูลอย่างไร?
ถ้าเข้าใจไม่ผิด ใช้มันสตาร์ต backend แบบเรียลไทม์ให้ทำงานเหมือนเซิร์ฟเวอร์ได้ไหม?
รายชื่อภาษาที่รองรับน่าประทับใจ รายชื่อภาษาที่ microsandbox รองรับ
อยากให้คู่มือสำหรับผู้ร่วมพัฒนาละเอียดกว่านี้ contributor guide
เมื่อก่อนเคยมีประสบการณ์ว่า VM ช้าและหนักจนใช้งานลำบาก
อยากลองเทียบกับ Orbstack บน macOS โดยเฉพาะฟีเจอร์ “Linux machines”
สงสัยด้วยว่าใน Orb จะ reuse VM แค่ตัวเดียวหรือไม่
การบูต VM ระดับมิลลิวินาทีเป็นความก้าวหน้าที่สำคัญมาก
แต่สิ่งแบบนี้ก็ทำได้คล้ายกันด้วย CloudHypervisor หรือ Firecracker
สิ่งที่คอนเทนเนอร์เหนือกว่า VM คือ runtime performance
สิ่งที่ทำให้ VM ช้าคือการ emulation ของอุปกรณ์ IO
โดยเฉพาะในเวิร์กโหลดแบบ AI agent น่าจะรู้สึกถึง overhead ฝั่งแอปพลิเคชันได้
อยากรู้ว่ามีแผนแก้ปัญหาด้านประสิทธิภาพอย่างไร
Microsandbox ใช้ libkrun และ libkrun ใช้ virtio-mmio สำหรับ block, vsock และ virtio-fs เพื่อลด performance overhead
Firecracker เองก็คล้ายกันในสาระสำคัญ และโปรเจกต์ E2B ก็ใช้ Firecracker เพื่อรองรับเวิร์กโหลด AI แบบ agentic
ตอนนี้นอกจากประเด็นเรื่อง filesystem แล้ว ยังไม่มีแผนปรับปรุงประสิทธิภาพครั้งใหญ่อื่น ๆ
แค่พิมพ์คำสั่ง
mountก็เห็นภาพแล้วว่าหมายถึงอะไรข้อมูลที่ควรถูกซ่อนไว้กลับถูกเปิดให้เห็นหมด ทำให้การใช้คำสั่งง่าย ๆ แบบเดิมเสียประโยชน์ไป
ปัญหาที่หนักกว่าคือผู้ใช้สามารถไปแตะต้องโครงสร้างข้อมูลภายในได้โดยตรง
เหมือนให้สิทธิ์ peek กับ poke กับผู้ใช้ทั้งหมด
ไอเดียของคอนเทนเนอร์เองดีอยู่แล้ว แต่ตราบใดที่ kernel ยังไม่ถูกออกแบบใหม่ วิธีปัจจุบันก็ยังเป็นเพียงทางแก้ชั่วคราว
ช่วยอธิบายหน่อยได้ไหมว่าเวลาเรียก
mountจากในคอนเทนเนอร์ มันมีจุดไหนที่ร้ายแรงขนาดนั้นmount ของ host ถูกเปิดเผยให้คอนเทนเนอร์เห็นจริงหรือ?
ปกติผมเข้าใจว่าจะเกิดขึ้นก็ต่อเมื่อผูกสิ่งอย่าง volume เข้ากับคอนเทนเนอร์แบบชัดเจนเท่านั้น
ผมเองก็สนุกกับ CodeSandbox SDK, E2B มาพอสมควร เลยอยากรู้ว่าต่างจากสองตัวนั้นอย่างไร และทิศทางต่อไปคืออะไร
อยากรู้ด้วยว่าข้างในใช้ Firecracker หรือเปล่า
เป็นโครงสร้างแบบ self-hosted
เป้าหมายคือทำให้การรัน sandbox แบบ microVM ในเครื่อง local environment (Linux, macOS, Windows (เร็ว ๆ นี้)) ทำได้ง่ายเหมือน E2B และย้ายไป production ก็ง่าย
ใช้ libkrun แทน Firecracker
ยังสงสัยเรื่องการดูแลรักษาของโซลูชัน microVM และว่าจะมีการตรวจสอบความปลอดภัยอย่างสม่ำเสมอหรือไม่
ยินดีมากที่มีทางเลือกใหม่ออกมา เพราะ Firecracker กับการเซ็ต OCI image ค่อนข้างยาก
Kata container ก็ใช้งานลำบากเช่นกัน
จุดเด่นที่สุดของคอนเทนเนอร์คือสามารถรันได้อย่างรวดเร็วโดยไม่ต้องระบุทรัพยากรละเอียด ๆ อย่างขนาดดิสก์หรือจำนวน CPU core
และยังสามารถเทียบ image กับ diff ของสถานะนั้น เพื่อดูได้ว่าโปรแกรมเปลี่ยนแปลงอะไรกับระบบระหว่างทำงานบ้าง
ถ้ามี VM ขนาดจิ๋วที่ใช้งานง่ายแบบนี้และช่วยเพิ่มความปลอดภัยในการ sandbox ได้ก็คงดีมาก
บางครั้งก็ใช้ bwrap เหมือนกัน แต่ไม่ใช่เครื่องมือที่เหมาะกับ command line มากนัก
ใช้ template หรือการสร้างแบบ remote/อัตโนมัติก็ได้เช่นกัน
microsandbox ทำให้เริ่มมีความหวังว่าจะสามารถแยกโค้ดพวกนี้ไปทำงานอย่างปลอดภัยได้
ดีเลย์การบูต 200ms ก็แก้ได้ด้วย live sandbox pool
และเมื่อมีความเข้ากันได้กับ OCI ก็อาจจัดให้ทั้งสภาพแวดล้อม sandbox ครบชุดได้เลย
อยากรู้ว่านี่ใช่ use case ที่ดีมากจริง ๆ หรือยังมีทางเลือกที่ดีกว่านี้อีก
เอนจิน runsc สามารถรันได้ใน Docker/Docker Desktop ด้วย
แต่ gVisor มีประสิทธิภาพด้าน network parallelism ฯลฯ อยู่ราว 1/3 ของ docker
เพราะหาทางเลือกที่ดีกว่านี้ไม่เจอ เลยสร้าง microsandbox ขึ้นมาเอง