Bảo mật các tác nhân AI tự trị trên Kubernetes: Mô hình tin cậy, quản lý bí mật và khả năng quan sát cho khối lượng công việc đám mây mới

Hãy tưởng tượng lúc 2 giờ sáng, bảng điều khiển của bạn nhấp đỏ với hàng trăm cảnh báo từ mạng, cơ sở dữ liệu, ứng dụng và bảo mật. Kỹ sư trực (on-call) phải mở sáu bảng điều khiển, đối chiếu thời gian, đưa ra giả thuyết và kiểm tra log. Quá trình này lặp lại cho đến khi tìm ra nguyên nhân gốc rễ ba giờ sau đó.

Giờ hãy tưởng tượng một tác nhân AI tự trị tự động hóa toàn bộ quy trình phân loại sự cố đó. Tác nhân này sẽ cần kéo dữ liệu遥测 mạng, truy vấn log ứng dụng, kiểm tra chỉ số cơ sở dữ liệu và tham chiếu chéo các sự kiện bảo mật. Nó phải thực hiện tất cả các hành động này ngay trong cụm Kubernetes sản xuất của bạn.

Tác nhân đó không phải là một vi dịch vụ (microservice) cũng không phải là một công việc hàng loạt (batch job). Đồ thị phụ thuộc, dấu chân thông tin xác thực và đường dẫn thực thi của nó đều động. Bài viết này sẽ mô tả các mẫu hạ tầng đã được phát triển để vận hành hệ thống chẩn đoán tự trị trên Kubernetes: cách ly, chứa bí mật, tin cậy từng cấp và khả năng quan sát cho một loại khối lượng công việc phá vỡ các giả định bảo mật Kubernetes hiện tại.

Các vùng bảo mật của tác nhân trên Kubernetes

Tại sao tác nhân AI phá vỡ mô hình bảo mật Kubernetes hiện có

Hầu hết các mô hình bảo mật Kubernetes đều giả định rằng khối lượng công việc có một tập hợp phụ thuộc rõ ràng, gọi một danh sách các dịch vụ bên ngoài được xác định và tiêu thụ tài nguyên một cách có thể dự đoán. Tuy nhiên, các tác nhân AI tự trị vi phạm mọi giả định này.

• Tạo ra các phụ thuộc bên ngoài động: Tại thời điểm chạy, tác nhân quyết định nguồn dữ liệu nào cần truy vấn dựa trên các giả thuyết được tạo ra. Không thể tạo ra một chính sách mạng (network policy) xác định trước mọi thứ tác nhân có thể cần.
• Yêu cầu thông tin xác thực đa miền: Một tác nhân chẩn đoán đa miền cần thông tin đăng nhập cho giám sát mạng, công cụ hiệu suất ứng dụng, tổng hợp log, luồng sự kiện bảo mật và API suy luận LLM. Điều này lưu trữ nhiều bí mật trong một container duy nhất.
• Sử dụng tài nguyên khó lường: Một cuộc điều tra đơn giản có thể tốn 200MB RAM trong 90 giây, nhưng một sự cố lan truyền qua bốn miền có thể tiêu tốn 4GB RAM trong 15 phút.
• Luồng thực thi không xác định: Đường dẫn thực thi phụ thuộc vào lý luận trung gian. Hai cuộc điều tra có cùng phát biểu ban đầu nhưng có thể đi theo các đường dẫn hoàn toàn khác nhau.

Mẫu Kubernetes Job: Cách ly theo mặc định

Việc xử lý mỗi cuộc điều tra của tác nhân như một Kubernetes Job riêng biệt thay vì một Deployment dài hạn mang lại tác động lớn nhất.

Vòng đời điều tra: một Kubernetes Job cho mỗi cuộc điều tra

Ban đầu, chúng tôi sử dụng Deployment, nhưng cách tiếp cận này không bền vững. Một cuộc điều tra tiêu thụ quá nhiều bộ nhớ sẽ ảnh hưởng đến các cuộc điều tra khác chạy trong cùng pod. Chạy mỗi cuộc điều tra như một Kubernetes Job riêng lẻ mang lại cho chúng tôi bốn thuộc tính mặc định:

• Cách ly tài nguyên: Mỗi cuộc điều tra có container riêng với cấp phát CPU và bộ nhớ riêng. Một cuộc điều tra phức tạp không làm đói một cuộc điều tra đơn giản.
• Cách ly lỗi: Nếu một Job thất bại do lỗi hết bộ nhớ hoặc hết thời gian chờ API, chỉ Job đó bị ảnh hưởng. Các cuộc điều tra khác không cần phục hồi.
• Trạng thái sạch: Mỗi Job bắt đầu từ một hình ảnh container mới, loại bỏ rủi ro rò rỉ trạng thái giữa các cuộc điều tra.
• Vết kiểm tra theo mặc định: Mỗi Job có luồng log riêng với thời gian bắt đầu và kết thúc, giúp dễ dàng gỡ lỗi một cuộc điều tra cụ thể mà không cần lọc qua đầu ra của một quy trình chia sẻ.

Trong thực tế, quy trình điều phối hoạt động như sau: Người dùng khởi tạo cuộc điều tra qua API. Backend xác thực yêu cầu, gán ID duy nhất và tạo một Kubernetes Job. Job bao gồm siêu dữ liệu cụ thể, thông tin xác thực được HashiCorp Vault chèn và giới hạn tài nguyên cụ thể. Sau khi hoàn thành, Job kết thúc và Kubernetes duy trì trạng thái Job để kiểm toán.

Quản lý bí mật: Chứa phạm vi ảnh hưởng trong thế giới đa miền

Thách thức quản lý bí mật cho các tác nhân AI tự trị khác biệt về mặt chất lượng so với các vi dịch vụ truyền thống. Nếu một container chứa thông tin xác thực cho bốn hoặc năm miền hạ tầng khác nhau bị xâm phạm, kẻ tấn công sẽ có quyền truy cập vào toàn bộ ngăn xếp vận hành của bạn.

Chúng tôi giải quyết rủi ro này bằng cách sử dụng HashiCorp Vault:

• Thông tin xác thực động, ngắn hạn: Các tác nhân Job xác thực với Vault khi khởi động bằng token service account của Kubernetes, nhận thông tin đăng nhập được giới hạn trong thời gian của cuộc điều tra. Khi Job hoàn thành, thông tin đăng nhập trở nên vô hiệu.
• Đường dẫn bí mật riêng biệt cho từng miền: Các đường dẫn truy cập riêng biệt cho mỗi miền (ví dụ: thông tin xác thực giám sát mạng, token tổng hợp log) có vết kiểm toán riêng, cho phép theo dõi rõ ràng khi và bởi cuộc điều tra nào thông tin đăng nhập miền được truy cập.
• Không có bí mật trong Git hoặc biến môi trường: Trình chèn tác nhân Vault xử lý xác thực, truy xuất, chèn và thu hồi. Kể cả khi ai đó kéo hình ảnh ECR hoặc tìm kiếm lịch sử Git, họ sẽ không tìm thấy thông tin giá trị nào.
• Xoay vòng thông tin đăng nhập mà không cần triển khai lại: Nếu bạn quyết định xoay vòng khóa API LLM, bạn chỉ cần cập nhật Vault. Job tiếp theo được khởi động sẽ nhận thông tin đăng nhập mới mà không cần nâng cấp Helm hay khởi động lại Deployment.

Mô hình tin cậy 4 giai đoạn: Khung truy cập từng cấp

Cấp cho một tác nhân tự trị thông tin xác thực sản xuất vào ngày đầu tiên là "tự sát doanh nghiệp". Chúng tôi đã tạo ra một mô hình tin cậy 4 giai đoạn cung cấp cho các nhóm nền tảng một con đường rõ ràng, có thể quan sát được để xây dựng sự tin tưởng từ không tin cậy đến hoạt động hoàn toàn tự trị.

Mô hình tin cậy từng cấp: quyền hạn hạ tầng theo từng giai đoạn

• Giai đoạn 1: Chế độ Shadow (Shadow Mode): Tác nhân chạy trên dữ liệu sản xuất, nhưng đầu ra không đi đâu cả. Kết quả chẩn đoán được xem xét bởi con người sau sự kiện. Tác nhân chỉ có quyền truy cập đọc.
• Giai đoạn 2: Trợ lý Chỉ đọc (Read-Only Assist): Tác nhân đóng vai trò là động cơ đề xuất. Khi sự cố xảy ra, tác nhân chạy tự động và trình bày cây giả thuyết và chuỗi bằng chứng cho kỹ sư trực. Kỹ sư có thể chấp nhận, từ chối hoặc sửa đổi chẩn đoán.
• Giai đoạn 3: Khắc phục giới hạn (Limited Remediation): Giai đoạn này cho phép tác nhân thực hiện các hành động khắc phục rủi ro thấp (như khởi động lại pod) khi được người vận hành phê duyệt rõ ràng. Các đặc quyền ghi được giới hạn bởi các vai trò RBAC cụ thể.
• Giai đoạn 4: Tự trị L1 (Autonomous L1): Tác nhân tự động giải quyết tất cả các sự kiện thường xuyên mà không cần sự can thiệp của con người. Khi mức độ tự tin của tác nhân giảm xuống dưới ngưỡng xác định, việc leo thang tự động sẽ xảy ra.

Các chuyển đổi giữa các giai đoạn được kiểm soát bởi bằng chứng vận hành, không phải bởi áp lực lộ trình. Ví dụ, để chuyển từ Giai đoạn 2 sang 3, hệ thống yêu cầu 150 sự kiện được hỗ trợ với tỷ lệ đồng ý của nhà vận hành trên 90% và không có đề xuất ngoài phạm vi.

Khả năng quan sát cho khối lượng công việc không xác định

Các phương pháp quan sát tiêu chuẩn bị phá vỡ đối với khối lượng công việc của tác nhân tự trị vì đơn vị công việc cơ bản là chu trình giả thuyết-đánh giá-tinh chỉnh lặp lại.

• Chỉ số cấp độ điều tra, không phải cấp độ yêu cầu: Chúng tôi theo dõi số lượng cuộc điều tra được khởi tạo, hoàn thành và thất bại. Chúng tôi thu thập số lượng chu kỳ đánh giá giả thuyết thực hiện trên mỗi cuộc điều tra.
• Tiêu thụ API LLM là chỉ số vận hành hạng nhất: Chúng tôi theo dõi tổng số cuộc gọi API LLM, thời gian hoàn thành trung bình, số lượng token tiêu thụ và chi phí mỗi cuộc gọi. Một sự tăng vọt trong bất kỳ chỉ số nào trong số này là dấu hiệu của một cuộc điều tra bất thường trước khi nó thất bại.
• Độ sâu lý luận là tín hiệu sức khỏe: Chúng tôi theo dõi bao nhiêu lần lặp lại đánh giá giả thuyết mà mỗi cuộc điều tra thực hiện. Nếu một cuộc điều tra yêu cầu nhiều hơn một số lần lặp nhất định mà không hội tụ, tác nhân có thể bị kẹt trong vòng lặp lý luận. Điều này cung cấp một cách để "cắt mạch" (circuit break) tác nhân.
• Cách ly log theo Job: Chúng tôi cách ly log được tạo bởi mỗi Job để khi một cuộc điều tra tạo ra kết quả không chính xác, bạn có thể kéo log của Job đó và xem chính xác chuỗi lý luận mà tác nhân đã sử dụng.

Kết luận

Các tác nhân AI tự trị đang đến với các cụm Kubernetes của bạn, cho dù mô hình bảo mật của bạn đã sẵn sàng hay chưa. Sự khác biệt giữa đường cơ sở này và tư thế bảo mật chất lượng sản xuất được xây dựng dựa trên cùng các khối xây dựng đám mây gốc: Jobs để cách ly, Vault cho bí mật, RBAC để kiểm soát truy cập, GitOps để khả năng kiểm toán và các công cụ quan sát tiêu chuẩn tập trung vào các chỉ số không tiêu chuẩn.

Vấn đề khó hơn mang tính tổ chức chứ không phải kỹ thuật. Để cấp cho một tác nhân tự trị quyền truy cập vào tài nguyên sản xuất, bạn cần một khung tin cậy cho phép các nhóm vận hành xây dựng sự tin tưởng từng bước. Hãy bắt đầu bằng việc kiểm tra các giả định bảo mật Kubernetes hiện tại của bạn và sửa chữa các ranh giới trước, sau đó triển khai tác nhân ở chế độ Shadow và để dữ liệu quyết định khi nào nâng cấp tác nhân.