Chạy kagent trên laptop: agent builder với RBAC hẹp và Ollama cục bộ

Lab của CNCF dùng kagent, kind và Ollama để tạo Kubernetes Agent từ mô tả ngôn ngữ tự nhiên. Điểm chính không phải no-code mà là giới hạn quyền bằng RBAC, allowlist tool và phê duyệt thao tác ghi.

Một agent có thể tạo agent khác bằng một câu mô tả ngôn ngữ tự nhiên. Nhưng với DevOps/SRE, câu hỏi quan trọng hơn là: agent đó được phép làm gì trong cluster, và ai duyệt thao tác ghi?

Bài hướng dẫn của Antonio Berben (Solo.io) và Felipe Vicens (Telefónica) trên CNCF Blog dựng một lab cục bộ với kagent. Điểm đáng chú ý không chỉ là trải nghiệm “no-code”, mà là cách đóng khung AI agent như một tài nguyên Kubernetes: có manifest, RBAC, danh sách tool được phép và bước xác nhận của người dùng.

kagent đưa agent vào mô hình Kubernetes

kagent là dự án CNCF Sandbox, chạy AI agent dưới dạng tài nguyên Kubernetes. Một Agent được khai báo với system prompt, model và danh sách tool; controller sẽ biến khai báo đó thành pod đang chạy và giao tiếp qua A2A.

Theo bài viết, khi agent đã là YAML, một agent có nhiệm vụ tạo agent khác cũng chỉ là một Agent có thể tạo đúng loại YAML đó.

Với platform engineer, cơ chế kiểm soát nằm ở hai lớp:

RBAC của ServiceAccount giới hạn quyền Kubernetes thực tế của tool server. toolNames giới hạn các tool mà model được nhìn thấy và gọi. requireApproval có thể dừng một tool call để chờ người dùng approve hoặc reject. Ollama cục bộ được dùng để phục vụ model trên laptop trong lab này.

Thành phần của lab cục bộ

Bài hướng dẫn dùng Docker, kind, kubectl, Helm, jq và Ollama. Model được chọn là:

bash ollama pull qwen3-coder:30b-a3b-q4KM

Model này cần khoảng 18 GB dung lượng đĩa.

Tác giả cho biết trong các lần thử của họ, qwen2.5:7b-instruct từng tự tạo định dạng tool call riêng; qwen2.5:14b-instruct đôi khi trả lời mà không gọi tool apply. qwen3-coder:30b-a3b-q4KM thực hiện đúng tác vụ trong mọi lần chạy mà họ ghi nhận. Đây là quan sát của bài lab, không phải một benchmark độc lập.

Cluster kind được tạo với tên kagent-builder:

bash kind create cluster --name kagent-builder

Trên Docker Desktop, kind có thể kết nối Ollama qua host.docker.internal:11434. Tác giả lưu ý Linux cần thay địa chỉ này bằng endpoint mà node kind truy cập được; họ chưa thử nghiệm cấu hình đó.

Bỏ cluster-admin, chỉ cho phép ghi Agent

Theo bài viết, chart kagent mặc định cấp cluster-admin cho ServiceAccount của tool server. Lab thay quyền này bằng quyền đọc, cộng thêm quyền thao tác duy nhất với agents.kagent.dev.

Ví dụ phần RBAC trong kagent-values.yaml:

yaml kagent-tools: tools: enabledTools: k8s rbac: readOnly: true additionalRules: apiGroups: ["kagent.dev"] resources: ["agents"] verbs: ["get", "list", "watch", "create", "update", "patch"]

Cấu hình đầy đủ trong bài cũng tắt các sample agent được chart cài mặc định, để UI chỉ hiển thị các agent của lab.

Sau đó, bài viết cài CRD và kagent phiên bản 0.10.2:

bash helm upgrade --install kagent-crds oci://ghcr.io/kagent-dev/kagent/helm/kagent-crds \ --kube-context kind-kagent-builder \ --version 0.10.2 --namespace kagent --create-namespace

helm upgrade --install kagent oci://ghcr.io/kagent-dev/kagent/helm/kagent \ --kube-context kind-kagent-builder \ --version 0.10.2 --namespace kagent --values kagent-values.yaml

Điểm chính ở đây là model không tự có quyền Kubernetes vô hạn. Tool server chỉ có các quyền RBAC được cấp, còn agent chỉ được gọi những tool xuất hiện trong allowlist.

Agent builder chỉ được tạo Agent

Builder trong lab cũng là một tài nguyên Agent. Nó được cấp ba tool:

k8sgetresources: liệt kê agent hiện có. k8sapplymanifest: áp dụng manifest. k8sgetresourceyaml: đọc lại resource sau khi tạo.

Builder được hướng dẫn liệt kê agent trước để chọn tên chưa tồn tại, sau đó tạo đúng một manifest Agent trong namespace kagent. Agent được tạo mới chỉ nhận các tool đọc như:

k8sgetresources k8sgetresourceyaml k8sdescriberesource k8sgetevents k8sgetpodlogs

Lệnh ghi k8sapplymanifest được đặt trong requireApproval. Khi builder gọi tool này, lần chạy sẽ dừng để người dùng xác nhận hoặc từ chối.

Sau khi được duyệt, builder đọc lại resource và kiểm tra các điều kiện Accepted và Ready. Đây là chi tiết quan trọng: trạng thái Kubernetes là căn cứ để xác nhận resource đã được controller tiếp nhận và sẵn sàng, thay vì chỉ dựa vào câu trả lời tự nhiên của model.

Điều cần giữ lại khi thử nghiệm

Lab này cho thấy một cách giới hạn phạm vi của agent ngay từ thiết kế:

Tool server không dùng quyền cluster-admin mặc định. Builder chỉ được ghi vào agents.kagent.dev. Agent builder chỉ nhìn thấy ba tool cần thiết cho luồng tạo và kiểm tra Agent. Thao tác apply phải có người dùng phê duyệt. Agent được tạo ra chỉ nhận tool đọc theo allowlist.

Với đội vận hành, đây là một hướng thực dụng để thử workflow agentic trong Kubernetes mà không bắt đầu bằng việc cấp quyền rộng cho mô hình.

Đây là lab laptop, không phải blueprint production

Tác giả nói rõ phần bảo mật không phải mục tiêu của lab. kagent chạy ở chế độ xác thực mặc định không an toàn, nên mọi request được xem là cùng một user. PostgreSQL đi kèm sử dụng mật khẩu tích hợp sẵn. UI và API chỉ được tiếp cận qua kubectl port-forward trên 127.0.0.1.

Những điều kiện này có thể phù hợp cho laptop cá nhân, nhưng không phù hợp với cluster dùng chung.

Nếu đưa mô hình này vào môi trường thực, khoảng trống cần xử lý nằm ở identity, authorization và các kiểm soát bảo mật phù hợp. Bài lab không giải quyết các vấn đề đó; nó minh họa phần dễ thấy hơn: tạo agent từ YAML, model và tool được giới hạn chặt.

Kết luận: kagent cho thấy agent builder không nhất thiết phải là một “hộp đen” có quyền lớn. Trong lab này, agent là Kubernetes resource; quyền ghi bị giới hạn vào Agent, tool được allowlist và thao tác apply cần phê duyệt. Đó là một điểm khởi đầu đáng chú ý cho các nhóm DevOps/SRE muốn thử AI agent trong phạm vi kiểm soát được.