Chuyện gì xảy ra nếu Cluster không có “luật chơi”?
Hồi mới vận hành Kubernetes, mình từng tin rằng RBAC là đủ để bảo vệ hệ thống. Nhưng đời không như là mơ. Developer thường vô tình chạy Container dưới quyền root hoặc quên giới hạn CPU/RAM vì muốn deploy nhanh. Một lần, một service không giới hạn Resource đã ngốn sạch tài nguyên node, khiến các service quan trọng khác bị treo hàng loạt.
Thay vì đi soi lỗi thủ công hay nhắc nhở từng người, mình chọn Kyverno để tự động hóa việc này. Kyverno là một Policy Engine thiết kế riêng cho Kubernetes. Nó đóng vai trò như một “cảnh sát” giám sát mọi Resource được đẩy vào Cluster. Cái nào không đúng chuẩn sẽ bị chặn lại hoặc tự động sửa cho đúng.
Điểm ăn tiền nhất của Kyverno là nó dùng YAML. Nếu bạn đã quen viết file manifest cho K8s, bạn sẽ làm chủ Kyverno trong 15 phút. Bạn không cần học ngôn ngữ Rego phức tạp như khi dùng OPA (Open Policy Agent).
Cài đặt Kyverno và chạy thử trong 5 phút
Cách nhanh nhất để triển khai Kyverno là sử dụng Helm. Bạn chỉ cần vài dòng lệnh đơn giản trên terminal:
# Thêm repo Helm của Kyverno
helm repo add kyverno https://kyverno.github.io/kyverno/
# Cập nhật repo và cài đặt
helm repo update
helm install kyverno kyverno/kyverno -n kyverno --create-namespace
Hãy thử tạo một Policy thực tế: Bắt buộc mọi Pod phải có nhãn (label) ‘owner’. Nhãn này giúp chúng ta biết ai là người chịu trách nhiệm cho Resource đó khi có sự cố.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-owner-label
spec:
validationFailureAction: Enforce
rules:
- name: check-for-owner-label
match:
any:
- resources:
kinds:
- Pod
validate:
message: "Lỗi: Bạn phải thêm nhãn 'owner' để định danh người quản lý Pod."
pattern:
metadata:
labels:
owner: "?*"
Sau khi apply bằng kubectl apply -f policy.yaml, bất kỳ ai cố tình tạo Pod thiếu nhãn owner sẽ nhận thông báo lỗi ngay lập tức. Hệ thống sẽ từ chối request đó ngay từ cửa ngõ API Server.
Bộ 3 quyền năng: Validate, Mutate và Generate
Kyverno không chỉ biết cấm đoán. Nó cung cấp 3 cơ chế xử lý linh hoạt cho từng bài toán cụ thể:
1. Validate – Gác cổng nghiêm ngặt
Đây là tính năng phổ biến nhất. Bạn đặt ra tiêu chuẩn và Kyverno sẽ kiểm tra xem Resource có đạt chuẩn hay không. Ví dụ: Ngăn chặn Container chạy ở chế độ privileged để tránh nguy cơ chiếm quyền điều khiển node vật lý.
Bạn có thể chọn chế độ Audit để ghi log cảnh báo hoặc Enforce để chặn đứng hành vi vi phạm.
2. Mutate – Tự động “vá lỗi” cấu hình
Tính năng này cực kỳ hữu ích để hỗ trợ Developer. Giả sử team của bạn hay quên set imagePullPolicy: Always. Thay vì bắt họ sửa lại, Kyverno sẽ tự động chèn thêm cấu hình này vào file YAML trước khi Pod được khởi tạo.
Nó giống như một người quản gia thầm lặng, tự tay hoàn thiện những chi tiết nhỏ còn thiếu trong bản vẽ của bạn.
3. Generate – Tự động hóa hạ tầng
Mỗi khi tạo một Namespace mới cho dự án, bạn thường phải tạo thêm NetworkPolicy, ResourceQuota hay Secret. Kyverno sẽ tự động “đẻ” ra các tài nguyên này ngay khi phát hiện Namespace mới xuất hiện.
Riêng với các Secret nhạy cảm, mình thường dùng password generator của Toolcraft để tạo chuỗi ký tự an toàn. Công cụ này xử lý hoàn toàn ở client-side nên mình rất yên tâm khi copy vào K8s Secret.
Triển khai Pod Security Standards (PSS) không “đau đớn”
Kubernetes định nghĩa sẵn bộ tiêu chuẩn bảo mật PSS gồm 3 mức: Privileged, Baseline, và Restricted. Áp dụng các chuẩn này giúp bạn vượt qua các đợt audit bảo mật như SOC2 hay PCI-DSS dễ dàng hơn.
Kyverno cung cấp sẵn thư viện Policy mẫu cho PSS. Bạn chỉ cần cài đặt và kích hoạt mức Restricted cho các môi trường Production. Nó sẽ tự động kiểm tra hàng loạt tiêu chí như cấm truy cập hostPath hay bắt buộc dùng read-only root filesystem.
Mẹo nhỏ: Khi mới áp dụng, hãy để chế độ Audit trong khoảng 1-2 tuần. Hãy theo dõi report để xem có bao nhiêu Pod cũ bị vi phạm trước khi chuyển sang Enforce. Làm vậy để tránh việc toàn bộ hệ thống bị chặn đứng do không kịp thích nghi.
Kinh nghiệm thực chiến để Kyverno chạy mượt mà
Sau một thời gian triển khai cho các hệ thống lớn, mình rút ra 4 lưu ý quan trọng:
- Né các Namespace hệ thống: Tuyệt đối loại trừ (exclude)
kube-systemvà chính namespace củakyverno. Nếu Policy của bạn quá chặt và vô tình chặn luôn cả CoreDNS, cluster của bạn sẽ “sập” trong vài phút. - Giám sát hiệu năng: Kyverno xử lý các Admission Request bằng Webhook. Mỗi request thường tốn thêm khoảng 10-30ms lateny. Nếu bạn có hàng trăm Policy, hãy tăng Resource (CPU/RAM) cho Kyverno Pod.
- Test kỹ ở Local: Hãy dùng Kyverno CLI với lệnh
kyverno testđể kiểm tra Policy trong CI/CD pipeline trước khi đẩy lên Cluster thật. - Đừng lạm dụng Mutate: Tự động sửa cấu hình quá nhiều sẽ khiến Developer bối rối vì thực tế chạy khác với file YAML họ viết. Hãy luôn có tài liệu hướng dẫn đi kèm.
Kyverno đã giúp mình giảm tới 80% các lỗi cấu hình ngớ ngẩn và nâng cao tính bảo mật cho hệ thống. Đây không chỉ là một công cụ, mà là cách chúng ta thực hành Policy as Code một cách chuyên nghiệp. Nếu bạn đang quản lý K8s, hãy thử cài Kyverno ngay hôm nay để có những đêm ngon giấc hơn.
