Nirmata đưa mô hình policy Kyverno xuống runtime bằng eBPF
Nirmata Runtime for Kyverno là dự án mã nguồn mở tái sử dụng khái niệm policy và CEL của Kyverno để giám sát hoặc chặn một số hành vi runtime của pod bằng eBPF và LSM. DNS chỉ được quan sát, không bị chặn.
Một AI agent có thể chạy từ image đã được duyệt và manifest hợp lệ, nhưng vẫn phát sinh hành vi ngoài dự kiến sau khi pod khởi động: gọi một endpoint chưa được phê duyệt, chạy một tiến trình lạ hoặc cố đọc credential trong filesystem.
Đó là khoảng trống mà admission control không trực tiếp xử lý. Admission control đánh giá khai báo trước khi workload chạy; còn khi pod đã hoạt động, đội SOC và platform cần biết: workload thực sự làm gì và hành vi nào cần bị chặn ngay lúc xảy ra?
Nirmata giới thiệu Nirmata Runtime for Kyverno, một dự án mã nguồn mở sử dụng eBPF và Linux Security Modules (LSM) để đưa enforcement xuống tầng kernel. Dự án tái sử dụng các khái niệm policy, selector Kubernetes và ngôn ngữ CEL quen thuộc từ Kyverno, thay vì là một tính năng runtime đã có sẵn trong Kyverno.
Theo bài đăng của Nirmata, hệ thống có thể giám sát hoặc chặn hành vi runtime của pod như thực thi tiến trình, mở file, egress và giao thức ứng dụng. Hoạt động DNS chỉ được quan sát, báo cáo chứ không bị chặn.
> Các mô tả về kiến trúc, cơ chế enforcement và hiệu quả trong bài viết này hiện dựa trên bài đăng của Nirmata. Tư liệu được cung cấp không có đánh giá độc lập về dự án.
Khoảng trống giữa manifest và hành vi thực tế
Admission control có thể đánh giá liệu một spec có đáp ứng policy trước khi triển khai hay không. Tuy nhiên, nó không quan sát trực tiếp các hành vi phát sinh sau thời điểm khởi động, chẳng hạn:
Container tải thêm thành phần sau khi chạy.
Sidecar kết nối tới một đích mạng chưa được phê duyệt.
Một tiến trình ngoài dự kiến bắt đầu thực thi.
AI agent gọi tool, model provider hoặc MCP server theo quyết định được tạo ra khi runtime.
Với AI workload, đây là điểm đáng chú ý: đội vận hành có thể review image và manifest, nhưng không thể review trước mọi quyết định mà model hoặc agent sẽ đưa ra trong lúc hoạt động.
Nirmata định vị runtime enforcement là lớp kiểm soát bổ sung, không thay thế admission control, network policy hay guardrail ở tầng ứng dụng.
Enforcement ở kernel, đồng bộ với thao tác
Theo mô tả của Nirmata, Nirmata Runtime gắn chương trình BPF-LSM vào các điểm kiểm soát kernel như bprmchecksecurity và fileopen. Với lưu lượng egress, dự án sử dụng chương trình eBPF theo phạm vi cgroup cho từng pod.
Các nhóm hành vi gồm:
exec: có thể từ chối thực thi tiến trình theo kernel path đã được phân giải.
open: có thể từ chối truy cập file theo kernel path đã được phân giải.
network: có thể từ chối egress theo đích kết nối.
protocol: có thể từ chối theo giao thức ứng dụng thực sự xuất hiện trên đường truyền, thay vì chỉ dựa vào port.
dns: chỉ quan sát và báo cáo hoạt động phân giải DNS, không chặn.
Bài đăng nêu rằng một lệnh exec bị chặn sẽ nhận -EPERM trước khi tiến trình chạy, còn kết nối bị chặn sẽ không hoàn tất. Quyết định và enforcement được thực hiện đồng bộ với thao tác mà policy kiểm soát.
Điều này đặc biệt đáng chú ý khi đánh giá egress: một kết nối qua port thường dùng cho HTTPS không mặc nhiên được phép nếu giao thức thực tế không phù hợp với policy.
RuntimePolicy, CEL và bước monitor trước enforcement
RuntimePolicy chọn workload bằng podSelector và namespaceSelector, đồng thời dùng CEL để biểu đạt logic allow/deny. Theo Nirmata, policy cũng có thể lấy giá trị động từ ConfigMap hoặc nguồn HTTP theo chu kỳ làm mới.
Mọi policy được đưa vào chế độ monitor mặc định. Trước khi bật enforce, đội vận hành có thể xem các hành vi mà policy sẽ chặn, bao gồm tín hiệu WouldDeny.
Với SOC và đội Kubernetes security, quy trình thận trọng là:
Xác định các workload AI cần theo dõi, như agent có quyền gọi tool hoặc MCP server.
Chạy policy ở chế độ monitor để quan sát hành vi thực tế.
Dùng monitorFilter với CEL để giảm nhiễu trong báo cáo.
Xác nhận binary, endpoint và file truy cập hợp lệ với chủ sở hữu workload.
Thử nghiệm policy trên staging trước khi áp dụng cho workload sản xuất.
Chỉ chuyển sang enforce khi đã hiểu rõ tác động vận hành.
Ví dụ trong bài viết dùng API runtime.nirmata.io/v1alpha1. Hậu tố v1alpha1 cho thấy API đang ở giai đoạn alpha, vì vậy đội vận hành nên đặc biệt thận trọng với khả năng thay đổi API và hành vi triển khai.
Điều kiện hạ tầng được nêu trong bài viết gồm:
Hành vi open cần node có BPF-LSM đang hoạt động.
network và protocol cần cgroup v2 cùng BPF.
Ví dụ: giới hạn agent gọi LLM gateway nội bộ
Bài viết đưa ra policy nhắm vào pod có nhãn nirmata.io/agent: "true". Policy cho phép kết nối tới LLM gateway nội bộ và kube-dns, chỉ cho phép TLS hoặc DNS, đồng thời chặn một số đường dẫn credential phổ biến.
yaml
apiVersion: runtime.nirmata.io/v1alpha1
kind: RuntimePolicy
metadata:
name: agent-gateway-only
spec:
mode: enforce
podSelector:
matchLabels:
nirmata.io/agent: "true"
behaviors:
network:
allow:
values:
llm-gateway.ai-platform.svc.cluster.local
kube-dns.kube-system.svc.cluster.local
deny:
values:
""
protocol:
allow:
values:
tls
dns
deny:
values:
""
open:
deny:
values:
"/root/.aws/credentials"
"/root/.kube/config"
"/root/.ssh/idrsa"
"/var/run/secrets/kubernetes.io/serviceaccount/token"
Trong mẫu này, cả network và protocol đều dùng ký hiệu "". Theo giải thích của Nirmata, kết nối cần đáp ứng cả hai điều kiện: TLS tới một đích ngoài allow-list bị từ chối, trong khi giao thức không được phép tới đúng gateway cũng bị từ chối.
Kiểm soát open nhằm hạn chế workload đọc các file nhạy cảm nêu trong policy. Tuy nhiên, allow-list và deny-list cần được kiểm thử kỹ trên staging: cấu hình quá chặt có thể làm gián đoạn DNS, service discovery hoặc dependency hợp lệ của ứng dụng.
Quan sát: cần biết policy nào tạo ra quyết định
Runtime security có thể tạo lượng sự kiện lớn. Nirmata mô tả cơ chế gán sự kiện về policy liên quan bằng cách mã hóa quyết định trong kernel map, sau đó để userspace đánh giá lại policy đã biên dịch với đối tượng quan sát được.
Kết quả được đưa vào các đối tượng Kubernetes OpenReports, thay vì yêu cầu dashboard độc quyền. Nếu một sự kiện không thể gán về policy cụ thể, hệ thống sẽ đếm và ghi log khoảng trống đó bằng chỉ dấu:
text
eventsdroppedtotal{reason="unattributedkerneldeny"}
Đây là tín hiệu cần theo dõi: một điểm mù trong dữ liệu quan sát nên hiện ra như lỗi có thể điều tra, thay vì bị hiểu nhầm là không có sự kiện nào xảy ra.
monitorFilter cũng có thể giảm nhiễu. Chẳng hạn, khi quan sát exec, policy có thể chỉ ghi nhận CLI agent hoặc inference server cần quan tâm, thay vì tạo báo cáo cho toàn bộ lệnh thông thường trong container.
Những điểm đội security nên theo dõi
Xác định pod nào vận hành AI agent, MCP server hoặc workload có hành vi động.
Theo dõi exec, open, egress, protocol và DNS ở chế độ monitor trước.
Rà soát endpoint được phép gọi, binary được phép thực thi và file không nên được đọc.
Kiểm tra điều kiện kernel trước khi áp enforcement, đặc biệt với kiểm soát open.
Kiểm thử kỹ allow-list để tránh chặn nhầm DNS, service discovery và các dependency hợp lệ.
Theo dõi các sự kiện không thể gán về policy để phát hiện điểm mù quan sát.
Với AI agent, rủi ro không chỉ nằm ở manifest được triển khai mà còn ở quyết định phát sinh khi workload đã chạy. Việc mở rộng câu hỏi từ “spec này có đúng không?” sang “pod này đang được phép làm gì?” là hướng tiếp cận đáng theo dõi đối với các đội SOC và Kubernetes security.