OpenShell trên Kubernetes: kiểm soát AI agent bằng sandbox và policy

OpenShell chạy AI agent trong sandbox trên Kubernetes, mặc định chặn egress và áp policy cho filesystem, process, network và credentials. Đây là lớp kiểm soát đáng chú ý khi agent nội bộ cần chạy lệnh hoặc gọi API có quyền thật.

Một AI agent có thể vừa đọc nội dung từ Internet, vài phút sau đã chạy shell, cài package, đọc file và gọi API bằng credential của công ty. Với đội hạ tầng, đây không chỉ là bài toán triển khai chatbot, mà là vận hành một workload không tin cậy trong cluster có mạng, PVC và secrets thật.

Kubernetes NetworkPolicy có thể giới hạn Pod nào được kết nối đến đâu. Nhưng nó không cho biết binary nào trong Pod gửi request, cũng không phân biệt được curl đọc dữ liệu với curl tạo tài nguyên qua HTTP POST.

OpenShell được thiết kế để bổ sung lớp kiểm soát đó.

OpenShell là gì?

OpenShell là runtime cho AI agent, khởi đầu bởi NVIDIA và hiện là dự án CNCF Sandbox. Mô hình của dự án là coi agent là untrusted code: agent có thể thực hiện hành động dựa trên prompt hoặc dữ liệu mà nó vừa tiếp nhận.

Mỗi agent chạy trong một sandbox. Một supervisor đáng tin cậy ở bên ngoài sandbox quyết định agent được phép truy cập gì. Policy được khai báo bằng YAML và kiểm soát bốn khu vực:

Filesystem: giới hạn các đường dẫn agent được đọc hoặc ghi. Trong demo, /usr, /etc và một số path khác chỉ đọc; /sandbox, /tmp và /dev/null có thể ghi. Process: runtime chuyển agent sang user không phải root, không cấp Linux capabilities và áp dụng seccomp. Network: outbound bị chặn mặc định. Rule có thể xét binary, host, port và HTTP method. Credentials: agent chỉ thấy placeholder cho API key. Supervisor thay bằng khóa thật, và chỉ với endpoint được provider cho phép.

Thay vì đưa Secret trực tiếp vào workload rồi kỳ vọng agent không sử dụng sai, mô hình này đặt thêm một lớp kiểm soát giữa agent và dịch vụ đích.

Trên Kubernetes vẫn là các object quen thuộc

OpenShell không có scheduler riêng. Backend Kubernetes sử dụng Agent Sandbox, resource Sandbox thuộc agents.x-k8s.io từ SIG Apps.

Với đội platform, sandbox được biểu diễn bằng các thành phần quen thuộc:

Pod workload chạy agent; Pod supervisor cho từng agent; Service kết nối supervisor với workload; PVC cho /sandbox; Secrets phục vụ TLS và bootstrap; NetworkPolicies.

OpenShell bổ sung ngữ cảnh mà NetworkPolicy không nhìn thấy. NetworkPolicy có thể cho phép Pod kết nối api.github.com:443, nhưng không thể đặt rule như: chỉ cho curl đọc issue, không cho tạo issue. OpenShell có thể kiểm tra binary gọi request và HTTP request trước khi cho phép kết nối ra ngoài.

Policy cũng có thể được cập nhật trên sandbox đang chạy mà không cần restart.

Luồng tạo và vận hành sandbox

Gateway của OpenShell quản lý vòng đời sandbox, còn Agent Sandbox chuyển mỗi sandbox thành các tài nguyên Kubernetes. Client gọi Gateway qua mTLS thay vì gọi trực tiếp Kubernetes API.

Luồng chính được mô tả như sau:

Gateway xác thực caller, xử lý image, policy, provider và resource. Gateway lưu sandbox record ở trạng thái Provisioning; record này là nguồn trạng thái chính, không phải Pod. Kubernetes driver tạo hoặc kiểm tra NetworkPolicy trước khi tạo workload. Agent Sandbox controller tạo workload Pod và PVC, nhưng scheduling gate giữ Pod chưa chạy. OpenShell đọc lại Pod sau admission và kiểm tra các điều kiện an toàn. Driver tạo supervisor Pod, Service, Secrets TLS/bootstrap và token ngắn hạn cho supervisor. Supervisor xác thực với Gateway, nhận policy rồi kết nối đến workload. Agent chỉ bắt đầu chạy khi các kiểm soát runtime đã được xác nhận.

Workload Pod không có outbound trực tiếp. Supervisor là đường kết nối duy nhất tới workload và là nơi kiểm tra policy cho các request của agent.

Sau admission, OpenShell kiểm tra Pod có chạy non-root, không thêm capabilities, dùng seccomp RuntimeDefault, không dùng host namespace, không nhận ServiceAccount token và có labels तथा volumes đúng như mong đợi hay không. Nếu admission webhook làm thay đổi các điều kiện này, việc tạo sandbox sẽ thất bại.

Đây là điểm cần lưu ý với quản trị viên cluster: OpenShell không thay thế Kyverno, NetworkPolicy hay admission control. Nó dựa vào các lớp này và kiểm tra lại trạng thái cuối cùng của Pod.

Demo xác nhận điều gì?

Demo của dự án chạy trên cluster kind hai node, sử dụng Kubernetes, Cilium, Agent Sandbox, OpenShell và Kyverno. CNI cần thực thi được cả ingress lẫn egress NetworkPolicy; demo thay kindnet bằng Cilium.

Sandbox hiện được tạo qua Gateway API, chưa phải trực tiếp qua Kubernetes API. Dự án đang có issue về OpenShellSandbox CRD và operator.

Trong demo, thao tác tạo sandbox dùng workspace demo, image nicolaka/netshoot và tùy chọn không tự thêm provider. Workspace là nơi nhóm sandbox, policy và logs.

Khi sandbox bắt đầu, request outbound bị chặn. Policy có thể được cập nhật mà không restart sandbox:

bash openshell policy update

Có thể xem log của sandbox bằng:

bash openshell logs policy-demo --source sandbox

Theo demo, curl ban đầu bị chặn. Sau khi cập nhật policy, curl có thể đọc từ api.github.com, nhưng HTTP POST tới /issues nhận kết quả policydenied.

Điểm quan trọng không chỉ là mở cổng 443, mà là giới hạn hành động cụ thể ở lớp HTTP.

Những phần platform team vẫn phải quản lý

OpenShell chỉ kiểm tra những cấu hình Pod cần thiết để duy trì an toàn cho sandbox. Một số quyết định vẫn thuộc về đội platform:

Image nào được phép chạy; Mức tài nguyên cho mỗi sandbox; Credential nào được cấp; Ai có quyền thay đổi RBAC của OpenShell.

Vì vậy, OpenShell nên được xem là một lớp trong kiến trúc phòng thủ, không phải cơ chế thay thế toàn bộ kiểm soát nền tảng.

Network, identity và quyền truy cập

Gateway xác thực caller. Identity của supervisor gắn với namespace, Sandbox UID, Pod UID và runtime generation. Đội platform vẫn cần xác định rõ ai được tạo sandbox, thay policy và đọc log.

Secrets và policy endpoint

Workload không nhận gateway credential, còn agent chỉ thấy placeholder của khóa. Tuy nhiên, danh sách provider và endpoint được phép thay khóa vẫn là policy nhạy cảm: phạm vi càng rộng, quyền thực tế của agent càng lớn.

Audit và điều tra sự cố

Outbound request, exec, SSH, logs và file sync đều đi qua supervisor để kiểm tra policy. Đây có thể là một điểm quan sát hữu ích khi điều tra hoạt động của agent.

Capacity và khả năng mở rộng

Mỗi agent hiện có một workload Pod và một supervisor Pod. Tài liệu dự án cũng lưu ý mô hình một supervisor Pod cho mỗi agent có thể không mở rộng tốt trong môi trường lớn.

Khi lập kế hoạch capacity, cần tính cả Pod, Service, PVC, Secret và overhead điều phối cho từng agent, không chỉ tài nguyên của model server.

Khi nào nên cân nhắc OpenShell?

OpenShell phù hợp với tình huống agent nội bộ cần thực thi tool hoặc gọi API, nhưng đội platform muốn giới hạn rõ agent có thể làm gì với filesystem, process, network và credentials.

Các điểm cần cân nhắc trước khi thử nghiệm:

[ ] CNI thực thi được ingress và egress NetworkPolicy. [ ] Admission policy không làm Pod sandbox lệch các yêu cầu non-root, seccomp và capabilities. [ ] RBAC rõ ràng cho việc tạo sandbox, đổi policy và đọc log. [ ] Allowlist endpoint, HTTP method và credential theo nguyên tắc đặc quyền tối thiểu. [ ] Capacity plan bao gồm cả workload Pod lẫn supervisor Pod. [ ] Thử policy theo hướng deny mặc định, sau đó mở dần từng quyền cần thiết.

Giá trị của OpenShell không nằm ở việc làm agent thông minh hơn. Nó tạo thêm điểm kiểm soát để agent có thể hữu ích mà không mặc nhiên thừa hưởng quyền của cả cluster.