Năm lớp kiến trúc để sandbox hóa các tác nhân AI trên Kubernetes

Các tác nhân AI tự hành tạo ra và thực thi mã nguồn đang đặt ra những rủi ro bảo mật mới cho cơ sở hạ tầng Kubernetes dùng chung. Để giải quyết vấn đề này, các kỹ sư từ Oracle Cloud Infrastructure đã xác định một chiến lược sandbox hóa gồm năm lớp, giúp cô lập khối lượng công việc của tác nhân mà không làm giảm hiệu quả của cụm máy chủ. Cách tiếp cận này tận dụng các công cụ cloud-native hiện có để tạo ra các ranh giới an toàn xung quanh việc thực thi mã nguồn không đáng tin cậy.

Chuyện gì đã xảy ra

Khi các tác nhân AI trở nên phổ biến hơn trong quy trình phát triển phần mềm, chúng ngày càng hoạt động với tính tự chủ cao hơn: cài đặt gói, chạy script và lặp lại quá trình viết mã. Mặc dù hành vi này có thể kiểm soát được trên laptop cá nhân, nhưng nó gây ra rủi ro đáng kể trong môi trường doanh nghiệp, nơi các tác nhân chia sẻ cụm Kubernetes với nhiều khối lượng công việc quan trọng khác. Sự cô lập container tiêu chuẩn phụ thuộc vào kernel của host, điều đó có nghĩa là nếu một lỗ hổng kernel bị khai thác bởi tác nhân, toàn bộ node có thể bị xâm phạm.

Mickey Boxell và Kay, những người dẫn dắt sản phẩm tại Oracle Cloud Infrastructure (OCI), đã chi tiết hóa một phương pháp tiếp cận có cấu trúc để giảm thiểu những rủi ro này trong một bài phân tích kỹ thuật chuyên sâu. Họ lập luận rằng sự cô lập khối lượng công việc đã chuyển từ một yêu cầu tăng cường bảo mật ngách thành một nhu cầu cơ bản đối với các nền tảng chạy tác nhân AI. Giải pháp được đề xuất không đòi hỏi phải phát minh lại bánh xe, mà thay vào đó là lắp ráp các thành phần mã nguồn mở hiện có thành một stack nhất quán.

Khung làm việc bao gồm năm lớp riêng biệt: runtime cô lập, cấu hình node, chính sách truy cập, cơ chế yêu cầu Kubernetes và lớp quản lý phiên. Bằng cách xử lý từng lớp, các đội ngũ nền tảng có thể hạn chế phạm vi ảnh hưởng của việc thực thi mã tự hành, đồng thời duy trì hiệu năng và tính linh hoạt mà các nhà phát triển mong đợi.

Cách thức hoạt động

Trọng tâm của chiến lược này nằm ở việc chọn đúng ranh giới cô lập. Các container runc tiêu chuẩn chia sẻ kernel của host, mang lại hiệu năng cao nhưng mức độ bảo mật thấp hơn. Để có sự cô lập mạnh mẽ hơn, các đội ngũ có thể sử dụng gVisor, một giải pháp triển khai kernel ứng dụng ở user-space để xử lý các lời gọi hệ thống, qua đó giảm bề mặt tấn công tiếp xúc với host. Đối với mức độ bảo mật cao nhất, Kata Containers chạy mỗi pod trong một máy ảo nhẹ với kernel khách riêng biệt, được tách khỏi host bằng công nghệ ảo hóa phần cứng. Điều này ngăn chặn các cuộc tấn công cấp kernel thoát ra khỏi container, mặc dù nó đi kèm với chi phí tài nguyên cao hơn.

Sau khi chọn runtime, node cần được cấu hình để hỗ trợ nó. Việc này bao gồm cài đặt các shim cụ thể và đảm bảo hỗ trợ ảo hóa phần cứng cho các runtime dựa trên VM. Lớp truy cập sau đó sẽ hạn chế những gì tác nhân có thể làm bên trong sandbox. Bao gồm việc áp dụng các chính sách mạng mặc định từ chối (default-deny), cấp phát thông tin đăng nhập có thời hạn ngắn và mount các volume dữ liệu dưới dạng chỉ đọc trừ khi quyền ghi được yêu cầu rõ ràng. Các chính sách này đảm bảo rằng ngay cả khi tác nhân bị xâm phạm, khả năng đánh cắp dữ liệu hoặc phá hủy các hệ thống bên ngoài vẫn được giảm thiểu tối đa.

Các đối tượng RuntimeClass của Kubernetes cho phép các pod lựa chọn động các runtime cô lập này. Điều này có nghĩa là các khối lượng công việc không phải tác nhân có thể tiếp tục sử dụng runtime hiệu năng cao mặc định, trong khi các tác vụ của tác nhân tự động chọn môi trường an toàn hơn, dù nặng nề hơn. Cuối cùng, dự án Agent Sandbox chuẩn hóa việc quản lý phiên, cho phép tạo ra các môi trường có trạng thái (stateful) có thể tạm dừng và tiếp tục, cân bằng giữa việc sử dụng tài nguyên và độ phản hồi.

Chi tiết quan trọng

• Lựa chọn cô lập: runc chia sẻ kernel của host; gVisor sử dụng kernel ở user-space; Kata Containers sử dụng các VM nhẹ với kernel khách riêng biệt.
• Yêu cầu về node: Kata Containers yêu cầu các node hỗ trợ ảo hóa phần cứng (KVM) và khả năng ảo hóa lồng ghép nếu chạy trên VM.
• Kiểm soát truy cập: Chính sách mạng nên mặc định từ chối tất cả lưu lượng egress, chỉ cho phép các đích cụ thể như mirror gói hoặc endpoint mô hình.
• Quản lý thông tin đăng nhập: Sử dụng token có thời hạn ngắn và phạm vi hẹp cho từng tác vụ cụ thể thay vì các secret dài hạn được mount vào pod.
• Chi phí tài nguyên: Các runtime sandbox hóa bổ sung chi phí CPU và bộ nhớ; định nghĩa RuntimeClass phải bao gồm các giá trị chi phí đo lường được để lập lịch chính xác.
• Quản lý phiên: API của Agent Sandbox hỗ trợ warm pools và lưu trữ bền vững để xử lý tính chất đột biến của các tương tác với tác nhân.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm và trưởng nhóm nền tảng, sự gia tăng nhanh chóng của các tác nhân AI có nghĩa là các mô hình bảo mật container truyền thống không còn đủ đáp ứng. Một tác nhân có khả năng thực thi mã tùy ý đại diện cho một vector đe dọa động mà việc quét tĩnh không thể giải quyết triệt để. Việc triển khai năm lớp này cung cấp một chiến lược phòng thủ theo chiều sâu (defense-in-depth), bảo vệ cơ sở hạ tầng nền tảng khỏi hành vi khó đoán của tác nhân.

Sự đánh đổi giữa bảo mật và hiệu năng là trung tâm của cuộc thảo luận này. Mặc dù Kata Containers cung cấp sự cô lập mạnh mẽ nhất, chi phí khởi động kernel khách và quản lý thêm tài nguyên có thể quá cao đối với các tác vụ có thông lượng lớn và độ trễ thấp. gVisor cung cấp một giải pháp trung gian, nhưng việc giả lập các lời gọi hệ thống Linux của nó có thể không hỗ trợ tất cả các hành vi của tác nhân, chẳng hạn như các build lồng phức tạp hoặc các thao tác biên dịch cụ thể. Hiểu rõ những sự đánh đổi này cho phép các đội ngũ đưa ra quyết định sáng suốt dựa trên mức độ chấp nhận rủi ro và yêu cầu khối lượng công việc cụ thể của họ.

Hơn nữa, cách tiếp cận này tận dụng các API Kubernetes tiêu chuẩn, đảm bảo tính di động giữa các nhà cung cấp đám mây khác nhau và các thiết lập on-premises. Bằng cách dựa vào các dự án do cộng đồng phát triển như gVisor, Kata Containers và Agent Sandbox, các tổ chức tránh được tình trạng khóa chặt vào nhà cung cấp (vendor lock-in) và hưởng lợi từ các bản cập nhật bảo mật liên tục cũng như các đánh giá thiết kế từ một hệ sinh thái rộng lớn các đóng góp viên.

Bạn có thể làm gì

• Đánh giá các khối lượng công việc tác nhân hiện tại để xác định mức độ cô lập phù hợp, lựa chọn giữa gVisor cho sự cân bằng giữa bảo mật và hiệu năng, hoặc Kata Containers cho sự cô lập tối đa.
• Cấu hình các node Kubernetes của bạn với các runtime cần thiết và đảm bảo rằng ảo hóa phần cứng được kích hoạt nếu sử dụng sandbox dựa trên VM.
• Định nghĩa các đối tượng RuntimeClass cho mỗi runtime sandbox hóa, bao gồm các phép đo chi phí tài nguyên chính xác để ngăn ngừa lỗi lập lịch.
• Triển khai các chính sách mạng nghiêm ngặt mặc định từ chối tất cả lưu lượng egress, chỉ cho phép rõ ràng các endpoint cần thiết cho các tác vụ của tác nhân.
• Tái cấu trúc việc quản lý thông tin đăng nhập để cấp phát token có thời hạn ngắn và phạm vi hẹp cho các phiên tác nhân thay vì sử dụng static secrets.
• Khám phá dự án Agent Sandbox để quản lý các phiên tác nhân có trạng thái và tối ưu hóa việc sử dụng tài nguyên thông qua warm pools.