Google Cloud đã triển khai dịch vụ GKE Agent Sandbox được quản lý, trong khi dự án mã nguồn mở kubernetes-sigs/agent-sandbox mang khả năng tương tự đến với bất kỳ cụm Kubernetes nào. Cả hai đều cung cấp cho các nhà phát triển một container Linux có thể sử dụng một lần cho các AI agent, giúp giữ nguyên phần còn lại của cơ sở hạ tầng.
Tại sao mã do AI tạo ra cần một môi trường thử nghiệm (playpen)
Các AI agent hiện đại không chỉ trả lời câu hỏi. Chúng viết script, duyệt web, thực thi các lệnh shell và thậm chí khởi chạy các dịch vụ web. Sức mạnh đó tạo ra một lỗ hổng bảo mật: mã mà chúng tạo ra có thể bị lỗi, độc hại hoặc quá mức kiểm soát. Một agent chạy lệnh rm -rf / hoặc kết nối với cơ sở dữ liệu nội bộ mà không có sự cho phép có thể làm tổn hại đến toàn bộ hệ thống.
Một sandbox cô lập mỗi agent trong container riêng của nó—một máy ảo nhỏ, có thể vứt bỏ sau khi dùng. Nếu agent hoạt động sai, thiệt hại sẽ chỉ nằm trong container đó; máy chủ (host) và các khối lượng công việc (workloads) khác vẫn được an toàn. Dịch vụ GKE mới và dự án do cộng đồng thúc đẩy đã biến ý tưởng này thành một dịch vụ sẵn sàng sử dụng.
Hai cách để có được một sandbox
- GKE Agent Sandbox – một dịch vụ được quản lý hoàn toàn dành cho khách hàng Google Cloud.
kubernetes-sigs/agent-sandbox– một dự án mã nguồn mở cho bất kỳ cụm Kubernetes nào.
Cả hai đều chia sẻ cùng một kiến trúc cốt lõi, được xây dựng trên các nguyên ngữ (primitives) chuẩn của Kubernetes.
Cách hệ thống được cấu thành
| Thành phần | Vai trò |
|---|---|
| Sandbox | Container cô lập chạy mã của agent. Nó có tên cố định và lưu trữ bền vững (persistent storage) nếu cần. |
| SandboxTemplate | Một bản thiết kế định nghĩa container image và các chính sách bảo mật—một "công thức" để tạo ra các sandbox mới. |
| SandboxClaim | Một yêu cầu được đưa ra bởi một agent (hoặc controller của nó) để khởi tạo một sandbox từ một template cụ thể. |
| SandboxWarmPool | Một nhóm các sandbox đã được tạo sẵn, sẵn sàng để cấp phát ngay lập tức. Việc duy trì các container ở trạng thái "warm" giúp tránh độ trễ khi kéo image và khởi động một pod mới mỗi lần. |
Khi một agent cần một môi trường, nó sẽ gửi một SandboxClaim. Controller sẽ kiểm tra warm pool, chọn một sandbox đang rảnh và liên kết nó với claim đó. Nếu pool trống, nó sẽ tạo một sandbox mới từ template; nếu không, việc bàn giao sẽ diễn ra trong vài mili giây.
Các nút điều chỉnh bảo mật bạn có thể tùy chỉnh
- Default-deny networking – Theo mặc định, sandbox không thể truy cập mạng nội bộ. Bạn phải thêm các quy tắc rõ ràng để cho phép các kết nối đi ra (outbound) hoặc đi vào (inbound), ngăn chặn việc vô tình làm lộ các dịch vụ nội bộ.
- Isolation levels – Chọn container runtime phù hợp với mức độ chấp nhận rủi ro của bạn:
- Standard containers để đạt tốc độ cao,
- gVisor để có thêm một lớp cô lập user-space, hoặc
- Kata Containers để có sự cô lập hỗ trợ bởi phần cứng, hoạt động giống như một VM nhẹ.
- SDKs – Các thư viện client Python và Go cho phép các nhà phát triển tạo, yêu cầu (claim) và hủy sandbox bằng lập trình, phù hợp với quy trình làm việc của các pipeline điều khiển bởi AI.
Ai được hưởng lợi, và ai có thể phản đối
Kết luận
Việc cung cấp cho các AI agent một môi trường Linux riêng biệt có thể vứt bỏ giúp loại bỏ yếu tố không xác định lớn nhất trong tự động hóa dựa trên AI: rủi ro mã được tạo ra sẽ phá hủy máy chủ. Dịch vụ GKE Agent Sandbox được quản lý của Google Cloud và dự án kubernetes-sigs/agent-sandbox do cộng đồng vận hành giúp việc cô lập này trở nên khả thi cho cả môi trường cloud-native và on-prem. Các tổ chức cần cân bằng giữa sự linh hoạt và tính bảo mật giờ đây đã có một công cụ Kubernetes-native cụ thể để giữ mã do AI tạo ra trong một môi trường thử nghiệm (sandbox) an toàn.