- microsandbox cung cấp khả năng thực thi mã người dùng và mã AI không đáng tin cậy một cách an toàn với mức cô lập cấp máy ảo
- Khắc phục nhược điểm của VM và container truyền thống với các ưu điểm như khởi động siêu nhanh (dưới 200ms), tương thích OCI container, tự lưu trữ
- Tối đa hóa hiệu quả tích hợp cho nhà phát triển và công cụ AI thông qua SDK cho nhiều ngôn ngữ lập trình và công cụ CLI
- Phù hợp cho nhiều trường hợp sử dụng AI và phát triển như thực thi mã, môi trường phát triển, phân tích dữ liệu, tự động hóa web, lưu trữ ứng dụng
- Mọi tác vụ đều có thể được quản lý theo dự án, đồng thời hỗ trợ cài đặt toàn hệ thống và môi trường thực thi duy trì phiên/cô lập
- microsandbox là nền tảng tự lưu trữ mã nguồn mở được thiết kế để thực thi an toàn mã người dùng hoặc mã AI không đáng tin cậy (ví dụ: AI agent, mã do người dùng gửi lên, mã thử nghiệm)
- Việc chạy cục bộ truyền thống có nhược điểm là lỗ hổng bảo mật, container có cô lập chưa hoàn chỉnh do dùng chung kernel, VM truyền thống khởi động chậm, còn cloud thì thiếu linh hoạt
- microsandbox hỗ trợ cô lập tiến trình thực sự dựa trên microVM (máy ảo siêu nhẹ), đồng thời mang lại tốc độ khởi động nhanh và trải nghiệm thân thiện với nhà phát triển tương tự container
- Khác biệt nhờ khởi động trong vòng 200ms sau khi thiết lập môi trường ban đầu, tương thích image container (OCI), tích hợp AI dựa trên MCP, và khả năng kiểm soát việc sử dụng hạ tầng riêng
Tóm tắt các tính năng chính
- Bulletproof Security: dựa trên microVM, cung cấp bảo mật cấp máy ảo giúp chặn tận gốc các lỗ hổng của container như thoát kernel
- Instant Startup: thời gian khởi động ban đầu dưới 200ms, giúp bắt đầu thực thi mã nhanh hơn rất nhiều so với VM
- Self-Hosting & Full Control: có thể triển khai và vận hành trực tiếp trên máy cục bộ hoặc máy chủ riêng mà không phụ thuộc cloud
- Tương thích OCI: có thể chạy trực tiếp bằng image container tiêu chuẩn, tương thích với các workflow Docker và container hiện có
- AI-Ready (hỗ trợ MCP) : có thể tích hợp và mở rộng tự nhiên với các AI dựa trên MCP như Claude, Agno
Workflow phát triển và thực thi nhanh
1. Khởi động server
- Có thể khởi động microsandbox server và thiết lập môi trường phát triển chỉ bằng các lệnh đơn giản
- Server đồng thời đóng vai trò là MCP server, nên có thể được gọi trực tiếp từ các công cụ AI như Claude
2. Cài đặt SDK
- Cung cấp microsandbox SDK cho các ngôn ngữ chính như Python, JavaScript, Rust
- Hỗ trợ thêm nhiều ngôn ngữ khác (khả năng mở rộng SDK), mở ra khả năng tích hợp rộng rãi cho nhà phát triển và AI
3. Thực thi mã an toàn
- Có thể chọn và chạy riêng các môi trường sandbox cho nhiều ngôn ngữ như Python, JavaScript, Rust
- Mỗi sandbox là một môi trường thực thi độc lập, bảo đảm an toàn hệ thống ngay cả khi chạy mã bên ngoài
- Có thể dễ dàng xây dựng quy trình thực thi mã an toàn theo kiểu bất đồng bộ và tự động hóa thông qua các ví dụ SDK
Quản lý môi trường theo dự án
- Tạo và quản lý Sandboxfile (tệp cấu hình) theo từng dự án, với workflow thân thiện cho nhà phát triển tương tự trình quản lý gói
- Có thể thêm nhiều môi trường sandbox vào một dự án (ví dụ: ngôn ngữ hoặc cấu hình khác nhau) để quản lý theo phiên bản/môi trường
- Khi chạy sandbox của dự án, các thay đổi tệp và cài đặt sẽ tự động được lưu trong thư mục cục bộ (./menv)
- Có tùy chọn kích hoạt sandbox tạm thời (xóa hoàn toàn mọi lịch sử và trạng thái, đồng thời cô lập khi phiên kết thúc)
Cài đặt sandbox toàn hệ thống
- Có thể cài đặt và đăng ký các môi trường hoặc ứng dụng dùng thường xuyên thành tệp thực thi riêng
- Ngay trong terminal, có thể vào trực tiếp môi trường sandbox chỉ với một dòng lệnh mà không cần đường dẫn dự án
- Có thể đặt tên cho từng sandbox, vận hành song song nhiều cấu hình khác nhau, và trạng thái phiên cũng được duy trì liên tục
Các trường hợp sử dụng chính
Thực thi mã AI và môi trường phát triển
- Khi AI tự động hóa cả việc build, chạy và debug mã nguồn thực tế, nền tảng này có thể nhanh chóng cung cấp môi trường phát triển cô lập và có thể lặp lại
- Phù hợp cho tự động hóa mã như tạo web app, sửa lỗi, làm prototype
Phân tích dữ liệu
- Có thể sử dụng an toàn các thư viện khoa học dữ liệu phổ biến như NumPy, Pandas, TensorFlow bên trong sandbox
- Lý tưởng cho các workflow phân tích cần bảo vệ dữ liệu cá nhân hoặc dữ liệu nhạy cảm
Agent duyệt web
- AI có thể thực hiện an toàn các tác vụ tự động như duyệt website, gửi form, đăng nhập, thu thập dữ liệu
- Hữu ích cho các mục đích như thu thập nội dung, so sánh giá, kiểm thử tự động
Lưu trữ ứng dụng tức thời
- Có thể chia sẻ ngay các công cụ, bản demo, máy tính, trực quan hóa do người dùng tạo ra thành dịch vụ
- Mỗi ứng dụng hoạt động trong không gian cô lập riêng, hỗ trợ tạo và kết thúc nhanh các môi trường tạm thời
Kiến trúc hệ thống
- Người dùng gọi microsandbox SDK từ business logic của riêng mình
- Yêu cầu server process (
microsandbox server) truyền và thực thi mã không đáng tin cậy
- Bên trong server, mỗi yêu cầu thực thi sẽ được xử lý trong một microVM riêng để cách ly lẫn nhau
- Mỗi microVM có thể cấu hình môi trường Python/Node độc lập
Chính sách mã nguồn mở
- Phát hành mã nguồn mở theo Apache License 2.0
1 bình luận
Ý kiến trên Hacker News
Nếu làm theo cách này thì có lẽ các container đơn thuần dựa trên permission hoặc jail sẽ gần 0%, Docker hơn 50%, còn Microsandbox có thể gần 100%
Có vẻ sẽ giúp giải tỏa thắc mắc bản năng cho những câu hỏi kiểu “sao không dùng jail luôn?”
Ngoài ra, cũng sẽ thú vị nếu chạy các honeypot container trên web công khai và thưởng tiền mặt hoặc coin cho ai hack thành công để “chứng minh” container nào đạt 100%
Gần đây, do các lỗ hổng như Rowhammer hay Spectre, có lẽ còn cần phải định nghĩa lại cả khái niệm bảo mật của điện toán đám mây và điện toán truyền thống
Cuối cùng, động lực là muốn có thêm insight về việc phát triển container bảo mật 100% mà không cần emulation hoàn hảo, cũng như bảo mật hóa các dịch vụ nền tảng của OS
Chỉ cần có lỗ hổng kernel LPE (Local Privilege Escalation) là có thể dẫn thẳng tới container escape
Dù thường không được ghi nhãn là container escape, trong ngành ai cũng hiểu rằng nếu có kernel LPE thì bảo mật container coi như bị phá vỡ
Phương án thay thế rõ ràng nhất là hạn chế mạnh việc dùng system call (API) bên trong sandbox, nhưng như vậy container sẽ không còn là nền tảng đa dụng nữa, và mỗi lần lại phải tinh chỉnh riêng theo từng trường hợp, khá bất tiện
Vì thế có quan điểm cho rằng cần đến virtualization
Trừ khi xuất hiện một OS vừa memory-safe vừa đủ cứng cáp, đây gần như là cách duy nhất, mà kể cả có OS như vậy thì cũng chưa rõ liệu nó có nhanh hơn việc chạy MicroVM trên Linux host hay không
Trong Docker hay systemd, mức độ bảo mật thay đổi rất lớn tùy từng thiết lập
Tôi nghĩ cần một bộ dữ liệu thực nghiệm lớn về việc thiết lập nào dẫn tới mức độ rủi ro/bảo mật nào
Trong thực tế, chính môi trường production là mục tiêu tấn công của vô số hacker
Mô hình khuyến khích kiểu này có thể thú vị, nhưng về độ hấp dẫn của mục tiêu hack thật và động lực tài chính thì có lẽ vẫn kém xa môi trường thực tế
Ví dụ trên Windows, khi chạy VM thường phải đợi vài giây hoặc hơn trước khi bất cứ thứ gì bắt đầu chạy
Ở đây “không chạy gì cả” nghĩa là trạng thái trước cả khi chương trình người dùng chạy, thậm chí trước cả lệnh đầu tiên của firmware
Thậm chí còn có một quãng chờ khá dài trước cả khi làm việc như dọn file đĩa ảo, hoặc trước khi cửa sổ VM hiện lên
Không hiểu vì sao lại vậy
Nhưng với kernel tiêu chuẩn thì có nhiều thao tác tốn thời gian như timeout hoặc polling
Trên hệ thống UEFI/CSM, việc chuẩn bị phần cứng ảo và khởi tạo môi trường hệ thống cũng tốn kha khá thời gian
Có thể WSL2 dùng một kernel đặc biệt để loại bỏ overhead không cần thiết
Việc khởi động các dịch vụ OS, chuẩn bị filesystem, làm nóng cache, cấu hình mạng, v.v. cũng đều ảnh hưởng
Theo kiểu truyền thống thì bootloader → initramfs → OS chính đều được nạp riêng
Muốn cắt giảm thời gian boot đến mức cực hạn thì có thể dùng cách như Amazon Firecracker: đưa thẳng image VM đã được khởi tạo sẵn vào bộ nhớ
Giới thiệu Firecracker MicroVM
Trên Windows, tốc độ boot cũng khác nhau tùy dùng hypervisor nào như HyperV
UEFI của HyperV khá chậm, còn nhiều bản phân phối Linux thì không cung cấp kernel tối giản đã được tối ưu
Với VirtualBox, hiện tượng được hỏi khá rõ ràng, còn bản cũ thì không có độ trễ kiểu này
Có thể đây không phải giới hạn bản chất của “VM truyền thống”, mà chỉ là vấn đề riêng của phần mềm đó
Nói chung VM chậm vì còn emulation cả những thành phần không cần thiết
Nếu tạo hypervisor ưu tiên tốc độ boot và bỏ qua tương thích legacy, thì hoàn toàn có thể boot trong 125ms như Firecracker
Nếu cấp phát theo đơn vị 1GB thì có thể nhanh hơn đáng kể
Có lẽ Windows cũng có cơ chế tương tự
Tôi từng dùng Hyper-V và vào Ubuntu 22 GUI qua XRDP trong 10 giây, còn Ubuntu 22 server qua SSH thì dưới 3 giây
Dù vậy, ý tưởng cốt lõi vẫn cực kỳ thú vị
Sắp tới sẽ có phương thức phân phối chính thức hơn
Mục tiêu là giúp tạo microVM dễ dàng như Docker container
Nếu có gì thắc mắc thì luôn sẵn sàng trả lời
Tôi hay gặp lỗi như “Sandbox is not started. Call start() first”
Mẫu trong tài liệu chính thức là “async with”, nhưng cách tôi dùng là khởi tạo một lần theo từng class rồi tái sử dụng liên tục qua nhiều method
Muốn hỏi cách làm được khuyến nghị hay best practice cho trường hợp này
Tôi tò mò networking hoạt động như thế nào
Ví dụ, có thể giới hạn microvm chỉ được truy cập public IP không?
Tức là có thể chặn microvm truy cập các IP mạng nội bộ hay không
Tôi muốn biết liệu tính năng MicroVM tích hợp sẵn có cung cấp giao diện OCI runtime hay không
Có thể dùng với Docker/Podman thay cho runc/crun không
Vì sao nó có thể nhanh đến vậy?
So với VM truyền thống thì có những trade-off nào?
Có khả năng nào làm suy yếu tính cô lập của VM không?
Có thể bật GUI không?
Có xem nó như một Vagrant mới không?
Dữ liệu vào/ra được xử lý thế nào?
Nếu tôi hiểu đúng, vậy có thể dùng cái này để dựng backend theo kiểu server theo thời gian thực không?
Danh sách ngôn ngữ hỗ trợ rất ấn tượng danh sách ngôn ngữ được microsandbox hỗ trợ
Giá mà hướng dẫn đóng góp chi tiết hơn contributor guide
Trước đây tôi từng khổ sở vì VM chậm và nặng
Muốn so sánh với Orbstack trên macOS, đặc biệt là tính năng “Linux machines”
Cũng tò mò liệu Orb có tái sử dụng chỉ một VM hay không
Khởi động VM ở mức mili giây là một cải tiến cực kỳ quan trọng
Tuy nhiên, điều tương tự cũng có thể làm với CloudHypervisor hoặc Firecracker
Điểm container thắng VM là hiệu năng runtime
Thứ làm VM chậm đi là emulation thiết bị IO
Đặc biệt với workload kiểu AI agent, overhead ở tầng ứng dụng có thể sẽ thấy rõ
Muốn biết kế hoạch giải quyết vấn đề hiệu năng là gì
Microsandbox dùng libkrun, và libkrun dùng virtio-mmio cho block, vsock và virtio-fs để giảm overhead hiệu năng
Firecracker về bản chất cũng tương tự, và dự án E2B dùng Firecracker để xử lý workload AI agentic
Hiện tại ngoài các vấn đề liên quan filesystem thì chưa có kế hoạch cải thiện hiệu năng lớn nào
Chỉ cần gõ lệnh
mountlà sẽ hiểu tôi muốn nói gìMọi thông tin vốn nên bị che đi lại lộ ra hết, làm giảm tính hữu dụng của các lệnh đơn giản vốn có
Vấn đề nghiêm trọng hơn là người dùng có thể trực tiếp đụng vào các cấu trúc dữ liệu nội bộ
Cảm giác như đang trao cho người dùng cả quyền peek lẫn poke
Ý tưởng container thì hay, nhưng chừng nào kernel chưa được thiết kế lại thì cách làm hiện nay vẫn chỉ là giải pháp tạm
Nếu gõ mount bên trong container thì cụ thể điều gì lại nghiêm trọng đến vậy?
Host mount có thực sự bị lộ ra trong container không?
Tôi cứ nghĩ chỉ khi gắn volume hoặc cấu hình tương tự một cách tường minh thì mới xảy ra
Tôi cũng từng dùng CodeSandbox SDK và E2B khá nhiều, nên tò mò nó khác hai bên đó ở điểm nào và định hướng sau này ra sao
Cũng muốn biết bên dưới có dùng Firecracker không
Đây là mô hình tự host
Tương tự E2B ở chỗ giúp dễ chạy sandbox dựa trên microVM trên môi trường cục bộ (Linux, macOS, Windows trong tương lai), đồng thời chuyển sang môi trường production cũng đơn giản
Dùng libkrun thay vì Firecracker
Tôi cũng băn khoăn về vấn đề bảo trì của các giải pháp microVM và liệu việc audit bảo mật có được duy trì đều đặn hay không
Vì Firecracker và việc thiết lập OCI image khá khó, nên bản thân việc có một lựa chọn thay thế đã là điều đáng hoan nghênh
Kata container cũng rất khó làm việc cùng
Ưu điểm lớn nhất của container là có thể chạy nhanh mà không cần chỉ định chi tiết tài nguyên như kích thước đĩa hay số lõi CPU
Cũng có thể diff trạng thái đó với image để xem chương trình đã gây ra những thay đổi gì cho hệ thống trong lúc chạy
Sẽ rất hay nếu có thể tăng cường sandboxing an toàn hơn bằng một VM cực nhỏ nhưng vẫn giữ được sự tiện lợi đó
Thi thoảng tôi cũng dùng bwrap, nhưng đó không phải công cụ hợp với dòng lệnh
Cũng có thể dùng template hoặc tạo từ xa/tự động
Microsandbox khiến tôi có hy vọng có thể cô lập và chạy loại mã này một cách an toàn
Độ trễ khởi động 200ms cũng có thể xử lý bằng một pool sandbox sống sẵn
Vì tương thích OCI nên thậm chí có thể cung cấp luôn cả môi trường sandbox hoàn chỉnh
Tôi muốn biết đây có thực sự là một trường hợp sử dụng rất phù hợp không, hay có lựa chọn nào tốt hơn
Engine runsc có thể chạy cả trong Docker/Docker Desktop
Tuy nhiên, hiệu năng của gVisor trong các tác vụ như xử lý mạng song song chỉ bằng khoảng 1/3 Docker
Chính vì không tìm ra lựa chọn tốt hơn nên tôi mới tự làm microsandbox