Cô lập bằng container hay microVM: so sánh 4 mức, từ tiến trình con đến VM đầy đủ

“Chạy nó trong sandbox” nghe như một chỉ dẫn duy nhất. Trên thực tế có bốn ranh giới phổ biến mà mọi người muốn nói tới, và chúng chặn những thứ rất khác nhau. Chọn sai sẽ khiến bạn bị lộ, hoặc khiến mỗi lần chạy chậm và tốn kém hơn mức cần thiết.

So sánh này giả định đoạn mã thực sự không đáng tin: do mô hình ngôn ngữ viết, do người dùng gửi lên, hoặc đến trong pull request từ người bạn không quen. Mã do chính bạn viết có nhu cầu khác.

Điều gì có thể sai

Trước khi so sánh các ranh giới, nên gọi tên chúng dùng để chống lại điều gì. Mã không đáng tin có thể:

1. Đọc thứ không được phép: biến môi trường, khóa SSH, tệp trong thư mục home, endpoint metadata của đám mây.
2. Vắt kiệt tài nguyên: lặp vô hạn, fork đến khi máy treo, làm đầy ổ đĩa.
3. Lạm dụng mạng: quét máy khác, gửi thư rác, đào tiền ảo, gọi các dịch vụ nội bộ của bạn.
4. Bám rễ: cài một cron job hoặc dịch vụ sống lâu hơn tác vụ.
5. Thoát ra: dùng lỗi ở tầng bên dưới để chạy mã trên chính máy chủ.

Mỗi mức dưới đây xử lý được một phần, không phải tất cả.

Mức 1: một tiến trình

Sandbox đơn giản nhất là một tiến trình con: subprocess.run có giới hạn thời gian, có thể chạy dưới một người dùng riêng, với giới hạn tài nguyên và bộ lọc seccomp nếu bạn kỹ tính.

Chặn được: chạy vô tận (giới hạn thời gian), một phần việc vắt kiệt tài nguyên (giới hạn), một số lệnh gọi hệ thống nguy hiểm (seccomp). Không chặn được: việc đọc mọi thứ người dùng đó đọc được, truy cập mạng, bám rễ qua bất cứ chỗ nào người dùng ghi được, và bất kỳ lỗi kernel nào. Thất bại điển hình: mã đọc một tệp mà bạn quên là có thể đọc được, hoặc một trình thông dịch “bị giới hạn” hóa ra có cửa hậu. Lịch sử đầy những sandbox nằm trong ngôn ngữ đã không trụ nổi.

Thời gian khởi động gần như bằng không. Ổn cho mã của chính bạn; không phải ranh giới cho mã của người khác.

Mức 2: một container

Namespace cho mã cái nhìn riêng về tệp, tiến trình và mạng; cgroup giới hạn CPU và bộ nhớ; capability bị gỡ bỏ cùng seccomp thu hẹp những gì nó có thể yêu cầu từ kernel.

Chặn được: đọc tệp của máy chủ (trừ khi được gắn vào), nhìn thấy tiến trình khác, dùng tài nguyên không giới hạn, phần lớn vấn đề bám rễ nếu container bị vứt bỏ. Không chặn được: lỗi trong kernel dùng chung của máy chủ. Mọi container trên máy đều nói chuyện với cùng một kernel, nên một lỗ hổng kernel có thể chạm tới là một lối thoát. Thất bại điển hình: cấu hình chứ không phải exploit kỳ lạ. Một container đặc quyền, socket của runtime container được gắn vào bên trong, mạng của máy chủ được bật “chỉ để gỡ lỗi”. Mỗi thứ đều âm thầm xóa bỏ ranh giới.

Thời gian khởi động tính bằng mili giây. Có những biến thể được gia cố, trong đó có kernel chạy ở không gian người dùng chặn lệnh gọi hệ thống trước khi chúng tới máy chủ, đổi lại tốc độ và độ tương thích. Với mã từ những người bạn tin tưởng, một container được cấu hình tốt là lựa chọn mặc định hợp lý.

Mức 3: một microVM

MicroVM chạy kernel riêng dưới một hypervisor, giống một VM đầy đủ, nhưng gần như không có phần cứng mô phỏng. Ví dụ nổi tiếng nhất là Firecracker.

Chặn được: mọi thứ container chặn được, cộng thêm vấn đề kernel dùng chung. Để chạm tới máy chủ, mã phải phá được hypervisor hoặc một trong số ít thiết bị ảo, một bề mặt nhỏ hơn nhiều so với giao diện lệnh gọi hệ thống của kernel. Không chặn được: việc lạm dụng những gì bạn trao cho nó. Lưu lượng đi ra được mở vẫn có thể bị lạm dụng; bí mật được đưa vào vẫn có thể rò rỉ. Thất bại điển hình: chính sách, không phải cô lập. Ai đó chuyển một token production vào “để test chạy được”, hoặc để lưu lượng đi ra không giới hạn ở nơi không cần.

Thời gian khởi động từ một phần nhỏ của giây đến khoảng một giây, với overhead vài megabyte. Như vậy đủ nhanh để tạo mỗi tác vụ một cái rồi xóa đi, đồng thời giải quyết luôn chuyện bám rễ: chẳng còn gì để quay lại.

Mức 4: một máy ảo đầy đủ

Một VM thông thường, hay VPS, có cùng loại ranh giới với microVM: ảo hóa phần cứng và một hypervisor. Khác biệt nằm ở mọi thứ xung quanh: mô hình thiết bị đầy đủ, cả một hệ điều hành, IP công khai nếu bạn muốn, và vòng đời tính bằng ngày hoặc tháng.

Chặn được: cùng các loại vấn đề như microVM, với bề mặt tấn công lớn hơn một chút vì phải mô phỏng nhiều phần cứng hơn. Không chặn được: việc lạm dụng danh tính mạng của chính nó. Một VM có IP công khai chạy mã độc hại sẽ khiến IP của nó bị đưa vào danh sách chặn, điều quan trọng nếu chính IP đó gửi email của bạn. (Nếu chuyện đó đã xảy ra, xem phải làm gì khi IP của bạn nằm trong danh sách chặn.) Thất bại điển hình: nó sống quá lâu. Một VM tạo ra cho một thử nghiệm sẽ tích lũy thông tin đăng nhập và trạng thái, rồi dần trở thành chính chiếc máy đáng tin mà nó lẽ ra phải bảo vệ.

Thời gian khởi động từ hàng chục giây đến vài phút, và thường tính phí theo tháng. Đó là hình thức đúng cho một dịch vụ chạy lâu cần cổng vào, và sai cho việc chạy mã trong 20 giây.

Bảng so sánh

Cách chọn

• Mã do bạn hoặc nhóm bạn viết: tiến trình hoặc container là đủ.
• CI cho các nhánh của chính bạn: một container trên runner của bạn.
• Mã từ agent, bài gửi của người dùng, pull request từ bên ngoài: mỗi tác vụ một microVM, xóa sau khi xong.
• Một dịch vụ không đáng tin cần nhận kết nối hoặc chạy nhiều tuần: một VM riêng với IP riêng, tách xa mọi thứ đang giữ thông tin đăng nhập hoặc gửi email của bạn.

Dù chọn gì, luôn có thêm hai quy tắc: đừng đặt vào bên trong bất cứ thứ gì bạn sẽ không giao cho tác giả của đoạn mã, và hãy chủ động quyết định mạng được phép làm gì.

Sản phẩm của chúng tôi nằm ở đâu

Cho mức 3, chúng tôi có sandbox chạy mã: microVM Firecracker khởi động trong khoảng một giây, có internet đi ra, không có cổng vào và tính phí theo giây. Chúng nhắm đúng vào gạch đầu dòng thứ ba ở trên; trang biện pháp bảo vệ MCP giải thích cách giới hạn những gì agent được làm với chúng. Cho mức 4, một VPS như gói AI agent cho bạn nguyên một máy theo tháng. Các ví dụ chi tiết trong sandbox cho AI agent minh họa mô hình microVM từ đầu đến cuối, còn AI agent thực sự cần gì từ hạ tầng xem cô lập là một trong nhiều yêu cầu.