OpenKruise Agents v0.6.0: Guardrail mạng và token cho sandbox AI
OpenKruise Agents v0.6.0 bổ sung kiểm soát egress L4/L7, ACL theo từng MCP tool và chèn token từ Kubernetes Secrets. Đây là các điểm đáng chú ý khi đội SOC và platform security quản trị sandbox AI trên Kubernetes.
Một sandbox AI có thể nhận prompt vô hại rồi phát sinh kết nối tới địa chỉ nội bộ, dịch vụ metadata hoặc API bên ngoài. Với SOC, đó không chỉ là vấn đề chất lượng prompt: đó là luồng egress cần được kiểm soát và quan sát.
OpenKruise Agents v0.6.0 đưa một số kiểm soát này vào lớp vận hành sandbox trên Kubernetes: lọc đích đến ở L4, kiểm tra yêu cầu ở L7, giới hạn từng công cụ MCP và chèn credential từ Kubernetes Secrets. Điểm cốt lõi là lưu lượng đi ra của sandbox có thể được điều phối bằng chính sách thay vì chỉ phụ thuộc vào mã của agent.
Những thay đổi đáng chú ý về kiến trúc
OpenKruise Agents là dự án con của OpenKruise, phục vụ quản lý vòng đời Agent Sandbox quy mô lớn trên Kubernetes. Dự án cung cấp môi trường chạy bao gồm mạng, lưu trữ và danh tính cho sandbox.
Ở v0.6.0, kiến trúc tăng từ bốn lên sáu thành phần, với hai thành phần mới:
traffic-control-plane: sử dụng istiod để phân phối cấu hình xDS; Egress Policy Enforcer áp chính sách L7, ACL cho MCP và chèn token trên lưu lượng đi ra.
traffic-proxy: sidecar trong Pod, làm điểm thực thi kiểm soát egress L4.
Các thành phần liên quan khác gồm:
sandbox-gateway: gateway ingress/egress xử lý định tuyến, token truy cập, wake-on-traffic và kiểm soát egress L7.
sandbox-manager: backend quản lý vòng đời sandbox, quota, route và traffic token.
sandbox-controller: điều phối các tài nguyên sandbox, warm pool và cơ chế tự động pause/resume.
agent-runtime: sidecar cung cấp các thao tác tương thích E2B cho lệnh, tệp và cổng.
Số lượng CRD cũng tăng từ 6 lên 12, trong đó có TrafficPolicy, GlobalTrafficPolicy, SecurityProfile và GlobalSecurityProfile.
Với đội bảo mật, các thay đổi này tạo thêm điểm kiểm tra trong Kubernetes: review đối tượng chính sách, đặt baseline cấp cụm, theo dõi gateway và rà soát các ngoại lệ egress.
Hai tầng kiểm soát: L4 cho đích đến, L7 cho yêu cầu
OpenKruise Agents xử lý lưu lượng đi ra theo hai giai đoạn:
text
Sandbox application container
-> traffic-proxy
-> egress gateway
-> Envoy external processing
-> Egress Policy Enforcer
-> external service, or a blocked response
Ở lớp L4, traffic-proxy bắt lưu lượng egress từ ứng dụng trong sandbox. Lưu lượng bị từ chối ở lớp này sẽ không đi tiếp tới gateway.
TrafficPolicy có thể chọn Pod theo label và khai báo đích được phép theo fqdn, cidr, service hoặc workload.
Ví dụ dưới đây cho phép DNS nội bộ và một API cụ thể, đồng thời từ chối một dải CIDR trên TCP 443:
yaml
apiVersion: agents.kruise.io/v1alpha1
kind: TrafficPolicy
metadata:
name: sandbox-egress
spec:
selector:
matchLabels:
app: traffic-sample
egress:
rules:
action: allow
to:
service: {name: kube-dns, namespace: kube-system}
action: allow
to:
fqdn: api.example.com
action: reject
ports: [{protocol: TCP, port: 443}]
to:
cidr: 10.0.0.0/8
Ba điểm vận hành cần lưu ý:
Khi một policy đã chọn Pod, lưu lượng egress không khớp rule allow sẽ bị từ chối.
Rule thiếu trường peer sẽ bị compiler bỏ qua, không tạo ra cơ chế từ chối mặc định.
Cần cho phép DNS Service của cluster nếu sử dụng rule theo FQDN; nếu không, sandbox có thể không phân giải được tên miền.
Ở lớp L7, SecurityProfile có thể đối chiếu yêu cầu HTTP với rule. Theo tài liệu công bố, block và bypass là hành động kết thúc; các hành động như ACL MCP, thao tác header, biến đổi token và audit có thể được áp dụng tiếp.
Ví dụ baseline cấp cụm sau chặn truy cập tới endpoint metadata và các miền nội bộ được chỉ định:
yaml
apiVersion: agents.kruise.io/v1alpha1
kind: GlobalSecurityProfile
metadata:
name: cluster-baseline
spec:
selector:
matchLabels: {app: traffic-sample}
priority: 50
rules:
name: deny-metadata-endpoint
match:
domains:
metadata.internal
".internal.company.com"
actions:
block:
statusCode: 403
body: '{"error":"access to internal services is forbidden"}'
Đây là một lớp guardrail hữu ích trước tình huống agent hoặc mã chạy trong sandbox cố gắng truy cập dịch vụ nội bộ hay endpoint metadata không thuộc phạm vi cho phép.
MCP ACL: kiểm soát theo từng công cụ
Kiểm soát theo domain có thể chưa đủ khi agent kết nối tới một MCP Server có nhiều công cụ với mức độ nhạy cảm khác nhau.
Trong v0.6.0, mcpToolPolicy áp dụng cho lời gọi JSON-RPC tools/call và khớp chính xác trường params.name. Tài liệu khuyến nghị đặt defaultAction: deny khi triển khai theo mô hình allowlist.
Điều này cho phép policy chuyển từ câu hỏi “agent có được kết nối tới máy chủ này không?” sang “agent có được gọi công cụ cụ thể này không?”.
Một checklist review phù hợp cho đội security và platform gồm:
Lập danh mục MCP Server và các tool mà từng loại agent cần dùng.
Xác định chủ sở hữu nghiệp vụ cho tool có thể tác động tới dữ liệu hoặc hệ thống.
Dùng allowlist theo params.name; từ chối mặc định với tool chưa được phê duyệt.
Kiểm thử các tình huống agent bị yêu cầu gọi tool vượt ngoài phạm vi dự kiến.
Rà soát sự kiện từ chối và log gateway để phát hiện hành vi bất thường.
Chèn credential từ Kubernetes Secrets
Một thay đổi đáng chú ý là credential upstream không cần xuất hiện trong Pod spec, biến môi trường hoặc metadata của Sandbox.
Theo cơ chế được công bố, credential được lưu trong Kubernetes Secrets. Egress proxy lấy credential theo từng request và viết lại request khi lưu lượng rời cluster; workload và mã agent chỉ sử dụng placeholder header.
Ví dụ cấu hình chèn API key vào header authorization:
yaml
apiVersion: agents.kruise.io/v1alpha1
kind: SecurityProfile
metadata:
name: example-api-credentials
namespace: agent-demo
spec:
selector:
matchLabels: {app: agent}
rules:
name: inject-example-api-key
match:
domains: [api.example.com]
schemes: [https]
paths: [{type: Prefix, value: /v1/}]
actions:
tokenTransformation:
type: ApiKey
failStrategy: Block
credentialRef:
secret:
name: example-api-credentials
apiKey:
targetHeaders:
names: [authorization]
value:
template: "Bearer {{ .Token }}"
failStrategy: Block thể hiện cơ chế fail closed: nếu không lấy được credential, request bị chặn. Tài liệu cũng nêu rằng việc xoay vòng Secret có thể có hiệu lực mà không cần khởi động lại sandbox.
Cách tiếp cận này giảm khả năng credential xuất hiện trong mã agent, biến môi trường hoặc metadata sandbox. Tuy vậy, đội vận hành vẫn cần kiểm soát quyền truy cập Kubernetes Secrets và có quy trình thu hồi credential khi xảy ra sự cố.
Checklist cho SOC và platform security
[ ] Xác định sandbox nào thực sự cần egress; bắt đầu với allowlist L4 theo FQDN, service hoặc CIDR.
[ ] Bảo đảm DNS Service được cho phép trước khi đánh giá rule FQDN.
[ ] Xây dựng GlobalSecurityProfile làm baseline để chặn các đích nội bộ hoặc metadata không cần thiết.
[ ] Rà soát rule có trường to hoặc peer thiếu để tránh policy không đạt hiệu lực mong muốn.
[ ] Với MCP, thiết lập allowlist theo từng tool và từ chối mặc định với tool chưa duyệt.
[ ] Lưu credential upstream trong Kubernetes Secrets; cân nhắc fail closed cho các luồng cần xác thực.
[ ] Thu thập và rà soát log gateway trong quy trình điều tra sự cố.
[ ] Theo dõi thời lượng request qua trường durationms, cùng lỗi 502 hoặc dấu hiệu packet loss như tài liệu khuyến nghị.
[ ] Nếu sử dụng endpoint Prometheus của gateway, lưu ý cổng metrics 9902 và điều chỉnh envoy.concurrency cùng giới hạn CPU.
[ ] Kiểm thử các tình huống prompt dẫn agent gọi endpoint không được phép hoặc MCP tool vượt quyền trước khi đưa agent vào môi trường nhạy cảm.
OpenKruise Agents v0.6.0 không khiến sandbox AI trở thành môi trường an toàn mặc định. Tuy nhiên, việc kết hợp lọc L4, kiểm tra L7, ACL theo MCP tool và chèn token trong cùng data plane đem lại các điểm kiểm soát rõ ràng hơn cho đội vận hành và bảo mật Kubernetes.