Cấu hình Prometheus và Grafana để thu thập metric từ Kata và gVisor
Môi trường sandbox kép sử dụng hai lớp ảo hóa khác nhau: Kata Containers dựa trên VMM (QEMU) và gVisor dựa trên Go runtime. Điều này đòi hỏi cấu hình scraping riêng biệt để thu thập metric hệ thống và runtime.
Bước 1: Cài đặt và cấu hình Node Exporter cho Kata Containers
Kata Containers chạy workload trong một máy ảo nhẹ (microVM). Để giám sát tài nguyên của microVM này, ta cần cấu hình Node Exporter chạy bên trong microVM hoặc scrape qua sidecar. Ở đây ta dùng phương pháp sidecar trong Kubernetes để giảm overhead.
Tạo file cấu hình Prometheus Adapter để expose metric của QEMU/Kata:
cat > /etc/prometheus/prometheus-kata-rules.yaml 0.9
for: 5m
labels:
severity: critical
annotations:
summary: "Kata MicroVM Memory limit reached"
EOF
Đặt file này vào thư mục rules của Prometheus để nó được load tự động.
Kết quả mong đợi: Prometheus sẽ bắt đầu cảnh báo khi microVM của Kata tiêu thụ quá 80% CPU hoặc 90% RAM.
Bước 2: Cấu hình scraping cho gVisor (runsc)
gVisor sử dụng runtime `runsc` để quản lý sandbox. Metric của gVisor được expose qua endpoint `/metrics` của `runsc` agent. Ta cần cấu hình Prometheus để scrape endpoint này từ container host.
Tạo file cấu hình target discovery cho gVisor:
cat > /etc/prometheus/prometheus-gvisor-targets.yaml
Tùy chỉnh file `prometheus.yml` để include file targets trên và thêm job scraping:
cat >> /etc/prometheus/prometheus.yml
Khởi động lại Prometheus để áp dụng cấu hình mới.
systemctl restart prometheus
Kết quả mong đợi: Trong Prometheus UI, tab "Targets" sẽ hiển thị trạng thái "UP" cho các target gVisor ở port 6060-6062.
Bước 3: Triển khai Dashboard Grafana tích hợp cả hai nền tảng
Sử dụng Grafana để tạo dashboard thống nhất, phân biệt metric của Kata và gVisor bằng label.
Tạo file JSON dashboard để import vào Grafana:
cat > /opt/grafana/dashboards/secure-ai-sandbox.json
Khởi động lại Grafana để load dashboard mới:
systemctl restart grafana-server
Kết quả mong đợi: Truy cập Grafana UI, thấy dashboard "Secure AI Sandbox" với 2 panel hiển thị realtime metric của Kata và gVisor.
Triển khai EFK stack để tập trung log từ các container ảo
Trong môi trường sandbox kép, log bị phân tán giữa host, microVM (Kata) và sandbox (gVisor). Cần một pipeline tập trung hóa (Centralized Logging) để truy vết sự cố bảo mật hoặc lỗi runtime.
Bước 4: Cấu hình Fluent Bit để thu thập log từ Kata Containers
Kata Containers lưu log ở `/var/log/kata-containers/` hoặc stdout của container bên trong microVM. Ta dùng Fluent Bit plugin để đọc log file này.
Tạo file cấu hình Fluent Bit:
cat > /etc/fluent-bit/fluent-bit-kata.conf
Khởi động lại Fluent Bit để áp dụng cấu hình:
systemctl restart fluent-bit
Kết quả mong đợi: Log từ microVM của Kata sẽ xuất hiện trong Elasticsearch với prefix `sandbox-logs` và tag `kata-container`.
Bước 5: Cấu hình Fluent Bit cho gVisor (runsc)
gVisor không tạo file log truyền thống mà log qua stdout/stderr của process `runsc`. Ta cần cấu hình Fluent Bit để đọc log từ container runtime (containerd) nơi gVisor được gọi.
Bổ sung cấu hình vào file Fluent Bit để capture log của runsc:
cat >> /etc/fluent-bit/fluent-bit-kata.conf
Khởi động lại Fluent Bit:
systemctl restart fluent-bit
Kết quả mong đợi: Log từ sandbox gVisor (bao gồm log của thư viện AI không tin cậy) được đẩy về Elasticsearch với tag `gvisor-runtime`.
Bước 6: Cấu hình Kibana để phân tích log kép
Sử dụng Kibana để tạo Discover view, phân biệt log dựa trên field `kubernetes.labels.sandbox_type`.
Tạo index pattern trong Kibana (thực hiện qua API hoặc UI):
curl -X POST "localhost:5601/api/index_patterns/_index_pattern?title=sandbox-logs-*" -H "kbn-xsrf: true" -H "Content-Type: application/json" -d '{"timeFieldName": "@timestamp"}'
Tạo dashboard filter trong Kibana:
kibana-dash-create --index-pattern "sandbox-logs-*" --filter "kubernetes.labels.sandbox_type:kata" --title "Kata Logs View"
kibana-dash-create --index-pattern "sandbox-logs-*" --filter "kubernetes.labels.sandbox_type:gvisor" --title "gVisor Logs View"
Kết quả mong đợi: Trong Kibana, có thể chuyển đổi giữa view log của Kata và gVisor bằng dropdown filter, giúp debug riêng biệt từng lớp sandbox.
Xử lý các trường hợp lỗi thường gặp khi container bị từ chối bởi Policy Engine
Khi Policy Engine (OPA Gatekeeper) chặn container do vi phạm policy, container sẽ ở trạng thái `ContainerCreating` hoặc `Error`. Việc debug đòi hỏi truy cập vào log audit của Gatekeeper và log runtime để xác định nguyên nhân chính xác.
Bước 7: Phân tích log Audit của OPA Gatekeeper
Gatekeeper ghi lại quyết định allow/deny vào log audit. Log này thường nằm trong container của Gatekeeper hoặc được gửi đi syslog.
Tra cứu log từ container Gatekeeper:
kubectl logs -n gatekeeper-system -l app=gatekeeper-audit --tail=100 | grep "denied"
Xuất file log audit chi tiết về local để phân tích:
cat > /var/log/gatekeeper-deny-analysis.sh
Chạy script với tên pod bị lỗi:
/var/log/gatekeeper-deny-analysis.sh my-ai-model-pod default
Kết quả mong đợi: File `/tmp/gatekeeper-deny.log` hiển thị message cụ thể về rule nào bị vi phạm (ví dụ: "container image must be signed" hoặc "seccomp profile not allowed").
Bước 8: Debug sự cố runtime khi Policy Engine cho phép nhưng Sandbox vẫn lỗi
Đôi khi Policy Engine cho phép, nhưng container vẫn lỗi do cấu hình sandbox (Kata/gVisor) không tương thích với workload.
Truy cập log của runtime containerd để xem lỗi khởi tạo sandbox:
journalctl -u containerd -f | grep "sandbox failed" | grep "my-ai-model-pod"
Đối với Kata Containers, kiểm tra log QEMU bên trong microVM (nếu có thể truy cập console):
kata-runtime log -f | grep "my-ai-model-pod"
Đối với gVisor, kiểm tra log của `runsc`:
cat /var/log/gvisor/runsc.log | grep "my-ai-model-pod" | tail -50
Kết quả mong đợi: Xác định được lỗi cụ thể như "seccomp: operation not permitted" (gVisor) hoặc "QEMU: out of memory" (Kata).
Bước 9: Tạo script tự động phân tích và đề xuất fix
Tự động hóa việc đọc log và đưa ra hướng dẫn sửa lỗi dựa trên keyword.
Tạo script troubleshooting helper:
cat > /usr/local/bin/sandbox-debug-helper.sh /dev/null | grep "$POD" | grep "denied" | head -1)
if [ -n "$DENY_LOG" ]; then
echo "[POLICY VIOLATION] Container was blocked by OPA Gatekeeper."
echo "Reason: $DENY_LOG"
echo "Solution: Update admission policy or container image signature."
exit 0
fi
# Check Kata Runtime Error
KATA_LOG=$(kata-runtime log 2>/dev/null | grep "$POD" | grep -i "error\|fail" | head -1)
if [ -n "$KATA_LOG" ]; then
echo "[KATA ERROR] MicroVM initialization failed."
echo "Detail: $KATA_LOG"
echo "Solution: Check QEMU version compatibility or resource limits."
exit 0
fi
# Check gVisor Runtime Error
GVISOR_LOG=$(cat /var/log/gvisor/runsc.log 2>/dev/null | grep "$POD" | grep -i "error\|fail" | head -1)
if [ -n "$GVISOR_LOG" ]; then
echo "[GVISOR ERROR] Sandbox runtime failed."
echo "Detail: $GVISOR_LOG"
echo "Solution: Check seccomp profile or syscalls allowed in gVisor."
exit 0
fi
echo "No specific sandbox error found. Check application logs inside container."
EOF
chmod +x /usr/local/bin/sandbox-debug-helper.sh
Chạy script để test:
sandbox-debug-helper.sh my-ai-model-pod
Kết quả mong đợi: Script in ra nguyên nhân chính xác (Policy, Kata, hoặc gVisor) và đề xuất hướng giải quyết ngay lập tức.
Điều hướng series:
Mục lục: Series: Xây dựng nền tảng Secure AI Sandbox với Kata Containers, gVisor và Policy Engine
« Phần 6: Tối ưu hóa hiệu năng và bảo mật cho các mô hình Machine Learning
Phần 8: Nâng cao bảo mật: Hardening, audit và các tips troubleshooting chuyên sâu »