Nghịch lý môi trường Production: Vì sao các bản triển khai ‘sạch’ lại xuống cấp theo thời gian
Pipeline hoàn tất, dấu tích xanh sáng bừng trên GitHub Actions, và container image được chuyển thẳng lên production. Vào sáng thứ Hai, cụm cluster của bạn trông hoàn toàn an toàn. Nhưng đến thứ Năm, mọi thứ đã thay đổi.
Việc công bố các lỗ hổng bảo mật không chờ đợi chu kỳ sprint của bạn. Hãy xem xét một tình huống thực tế: một lỗ hổng thực thi mã từ xa (RCE) trên OpenSSL hoặc glibc bất ngờ xuất hiện trên cơ sở dữ liệu NVD vào giữa tháng. Image vận hành dịch vụ thanh toán của bạn đã được quét từ ba tuần trước trong quá trình build. Do không có lập trình viên nào chỉnh sửa repository đó kể từ lúc đó, pod vẫn tiếp tục chạy các file nhị phân chứa lỗ hổng trên production mà không kích hoạt bất kỳ cảnh báo CI nào.
Sự sai lệch cấu hình runtime (runtime drift) càng khiến vấn đề thêm trầm trọng. Các kỹ sư thường hotfix manifest trong lúc xử lý sự cố production, chạy container với quyền root hoặc bỏ qua hoàn toàn giới hạn bộ nhớ. Các bước kiểm tra tĩnh trong pipeline không bao giờ thấy được những điều chỉnh trong runtime này.
Phân tích nguyên nhân gốc rễ: Bốn điểm mù bảo mật trong CI/CD
Việc chỉ dựa vào quét bảo mật ở giai đoạn build sẽ để lại bốn lỗ hổng vận hành lớn:
- Độ trễ lỗ hổng (Vulnerability Latency): Các cơ sở dữ liệu CVE công bố hàng chục bản cập nhật mỗi ngày. Một container image được chứng nhận là sạch vào lúc 9:00 sáng có thể chứa lỗ hổng nghiêm trọng vào lúc 5:00 chiều trong khi vẫn đang chạy bình thường trong cụm cluster của bạn.
- Sai lệch cấu hình cụm (Cluster Configuration Drift): Các kỹ sư thường xuyên vá lỗi môi trường staging hoặc production bằng lệnh trực tiếp
kubectl edit. Những thay đổi thủ công này bỏ qua các bước kiểm tra pull request và tạo ra các security context không an toàn. - Helm Chart của bên thứ ba: Các cluster production phụ thuộc vào các add-on mã nguồn mở như cert-manager, NGINX Ingress và Prometheus exporter. Những image của bên thứ ba này hoàn toàn không đi qua các pipeline build nội bộ của bạn.
- Kiểm định CIS tĩnh: Việc kiểm tra worker node, cờ cấu hình API server và thiết lập kubelet theo CIS Kubernetes Benchmarks đòi hỏi phải kiểm tra runtime liên tục. Việc đánh giá định kỳ hàng quý bằng bảng tính không thể bắt kịp những sai lệch giữa các bản phát hành.
Đánh giá các phương pháp quét bảo mật Kubernetes
Các platform team thường lựa chọn giữa ba kiến trúc quét runtime sau:
| Phương pháp | Ưu điểm | Nhược điểm | Mức tiêu hao tài nguyên |
|---|---|---|---|
| 1. CLI CronJob theo lịch (Script Trivy hoặc kube-bench) | Không tốn chi phí bản quyền phần mềm, viết shell script đơn giản | Khó bảo trì và dễ lỗi, đầu ra chỉ là log thô, không tích hợp sẵn với CRD của Kubernetes | Ma sát vận hành cao |
| 2. SaaS Agent cho doanh nghiệp (Ví dụ: Prisma Cloud, Sysdig Secure) | Dashboard web toàn diện, thu thập telemetry kernel runtime qua eBPF | Chi phí bản quyền theo người dùng đắt đỏ, cấu hình multi-tenant phức tạp, bị phụ thuộc vào nhà cung cấp (vendor lock-in) | 100–300MB RAM mỗi node |
| 3. Kubernetes-Native Operator (Aqua Trivy Operator) | Mã nguồn mở, lưu trữ dữ liệu audit trực tiếp trong Custom Resources (CRD), tích hợp GitOps gốc | Yêu cầu dự trù CPU/bộ nhớ nội bộ trong cluster cho các scan job | <50MB RAM khi controller ở trạng thái rảnh |
Hướng dẫn triển khai từng bước: Cài đặt Trivy Operator
Trivy Operator biến việc kiểm định bảo mật thành các Custom Resource gốc của Kubernetes. Khi một pod, job hoặc daemonset mới khởi động, operator controller sẽ tạo một scan job ngắn hạn. Nó kiểm tra workload mục tiêu, ghi các phát hiện có cấu trúc vào các custom resource như VulnerabilityReport, và tự động dọn dẹp scanner pod sau khi hoàn tất.
Bước 1: Cài đặt Trivy Operator bằng Helm
Thêm repository chart chính thức của Aqua Security và tạo một namespace riêng biệt:
# Thêm Helm repository của Aqua Security
helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update
# Tạo namespace chuyên dụng
kubectl create namespace trivy-systemTriển khai chart với giới hạn số lượng quét đồng thời tối ưu cho production và lên lịch audit CIS:
helm install trivy-operator aqua/trivy-operator \
--namespace trivy-system \
--set trivy.ignoreUnfixed=true \
--set operator.scanJobsConcurrentLimit=3 \
--set compliance.cron="0 2 * * *"Xác nhận pod của operator đang chạy:
kubectl get pods -n trivy-systemBước 2: Kiểm tra các CRD bảo mật được tạo ra
Trivy Operator đăng ký các Custom Resource Definition tương tự như các đối tượng Kubernetes tiêu chuẩn. Kiểm tra các định nghĩa đã được đăng ký:
kubectl get crds | grep aquasecurityCác custom resource quan trọng bao gồm:
vulnerabilityreports.aquasecurity.github.io: Theo dõi CVE của các package trên các container image đang chạy.configauditreports.aquasecurity.github.io: Đánh dấu các lỗi cấu hình pod, chẳng hạn như chạy với quyền root hoặc thiếu hệ thống tệp root ở chế độ chỉ đọc (read-only).clustercompliancereports.aquasecurity.github.io: Ánh xạ cấu hình tổng thể của cluster với CIS Benchmarks và các hướng dẫn của NSA/CISA.exposedsecretreports.aquasecurity.github.io: Quét các layer trong filesystem của container để phát hiện API key, token và chứng chỉ bị lộ.
Bước 3: Triển khai một Workload thử nghiệm
Triển khai một phiên bản NGINX phiên bản cũ để kích hoạt tính năng tự động phát hiện và quét:
kubectl create namespace demo-apps
kubectl create deployment vulnerable-web --image=nginx:1.18 --namespace demo-appsOperator controller sẽ phát hiện replica set mới ngay lập tức. Nó khởi chạy một scanning pod tạm thời trong trivy-system, truy vấn cơ sở dữ liệu lỗ hổng và tổng hợp báo cáo trong vòng 30 đến 60 giây.
Bước 4: Truy vấn báo cáo thông qua kubectl
Bạn không cần dashboard bên ngoài để kiểm tra các lỗ hổng. Hãy truy vấn trực tiếp cụm cluster của bạn:
kubectl get vulnerabilityreports -n demo-appsGiao diện dòng lệnh hiển thị bảng tóm tắt rõ ràng theo các mức độ nghiêm trọng:
NAME REPOSITORY TAG CRITICAL HIGH MEDIUM LOW AGE
deployment-vulnerable-web-vulnerable-web-nginx library/nginx 1.18 12 48 65 82 2mĐể trích xuất các mã định danh CVE cụ thể, các package bị ảnh hưởng và phiên bản đã được vá lỗi, hãy sử dụng jsonpath:
kubectl get vulnerabilityreport deployment-vulnerable-web-vulnerable-web-nginx -n demo-apps -o jsonpath='{range .report.vulnerabilities[*]}{.vulnerabilityID}{"\t"}{.severity}{"\t"}{.resource}{"\t"}{.fixedVersion}{"\n"}{end}'Bây giờ, hãy kiểm tra báo cáo kiểm định cấu hình pod để xác định các anti-pattern trong triển khai:
kubectl get configauditreports -n demo-apps -o wideKết quả đầu ra sẽ làm nổi bật các lỗi cấu hình manifest, chẳng hạn như thiếu memory request, thiếu CPU limit và các Linux capability không an toàn.
Bước 5: Chạy kiểm định tự động theo chuẩn CIS Kubernetes Benchmark
Trivy Operator tự động kiểm định các tham số bảo mật của master node và worker node dựa trên lịch trình đã cấu hình ở Bước 1.
Liệt kê tất cả các báo cáo tuân thủ đang hoạt động trên toàn cụm:
kubectl get clustercompliancereportsKiểm tra chi tiết các điểm không đạt chuẩn tuân thủ và các biện pháp khắc phục cần thiết:
kubectl get clustercompliancereport cis-k8s -o yamlBáo cáo cung cấp ma trận đạt/không đạt (pass/fail) bao gồm cấu hình API server, mã hóa etcd và xác thực kubelet, cùng với hướng dẫn khắc phục chi tiết cho từng mục kiểm tra không đạt.
Bước 6: Tối ưu hóa cho Production và các Best Practice vận hành
- Giới hạn số lượng quét đồng thời: Trên các cụm lớn có hàng trăm microservice, việc chạy nhiều scan job cùng lúc có thể làm quá tải worker node. Hãy duy trì
operator.scanJobsConcurrentLimittrong khoảng từ 2 đến 5 để tránh hiện tượng nghẽn CPU (CPU throttling). - Lọc các cảnh báo chưa có bản vá: Bật
trivy.ignoreUnfixed=true. Thiết lập này sẽ lọc bỏ các lỗ hổng chưa có bản vá từ nhà cung cấp, giúp các kỹ sư tập trung vào những vấn đề có thể xử lý ngay. - Gửi metrics sang Prometheus: Trivy Operator cung cấp metrics tại
:8080/metrics, bao gồmtrivy_image_vulnerabilitiesvàtrivy_configaudit_checks. Hãy thu thập (scrape) các metrics này để kích hoạt cảnh báo PagerDuty bất cứ khi nào số lượng CVE Critical vượt quá SLA nội bộ của bạn.
