Tích hợp OPA (Open Policy Agent) để kiểm tra tuân thủ chính sách an toàn
Chúng ta cần triển khai OPA Gatekeeper để đóng vai trò là Policy Engine trong cụm KubeEdge, đảm bảo mọi workload AI tuân thủ các quy định bảo mật trước khi được tạo.
Việc này ngăn chặn các container chạy với quyền root, ngăn chặn các container sử dụng image từ registry không tin cậy, và đảm bảo resource limit được đặt cho các workload AI.
Đầu tiên, triển khai OPA Gatekeeper bằng Helm vào cluster KubeEdge của bạn.
helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm repo update
helm install gatekeeper gatekeeper/gatekeeper-crds --namespace gatekeeper-system --create-namespace
helm install gatekeeper gatekeeper/gatekeeper --namespace gatekeeper-system --version 3.18.0
Kết quả mong đợi: Các resource Custom Resource Definition (CRD) của Gatekeeper được tạo và pod của OPA Gatekeeper trong namespace `gatekeeper-system` chuyển sang trạng thái `Running`.
Thiết lập chính sách cấm container chạy với quyền Root
Chúng ta sẽ định nghĩa một Constraint để chặn bất kỳ Pod nào yêu cầu quyền `runAsRoot` hoặc có `privileged` mode, đặc biệt quan trọng cho các workload AI xử lý dữ liệu nhạy cảm.
Tạo file cấu hình chính sách tại đường dẫn `/etc/kubeedge/policies/ai-no-root-constraint.yaml` với nội dung sau:
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPodSecurity
metadata:
name: ai-workload-no-root
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod", "Deployment", "DaemonSet", "StatefulSet"]
namespaces:
- ai-inference
- edge-ai-workloads
parameters:
exclude:
- "kube-system"
- "gatekeeper-system"
enforce: true
allowed:
- "baseline"
enforceLevel: "baseline"
auditLevel: "restricted"
Áp dụng chính sách này vào cluster để kích hoạt kiểm soát.
kubectl apply -f /etc/kubeedge/policies/ai-no-root-constraint.yaml
Kết quả mong đợi: Cluster chấp nhận file cấu hình. Nếu bạn cố tạo một Pod chạy với quyền root trong namespace `ai-inference`, Pod đó sẽ bị từ chối với thông báo "policy violation" từ OPA.
Verify kết quả tích hợp OPA
Để xác minh chính sách hoạt động, hãy cố gắng deploy một Deployment vi phạm chính sách (chạy với quyền root) vào namespace `ai-inference`.
kubectl run test-violation --image=nginx:latest -n ai-inference --restart=Never --securityContext="runAsUser=0"
Quan sát sự kiện (events) của Pod bị từ chối để thấy thông báo lỗi từ Gatekeeper.
kubectl describe pod test-violation -n ai-inference
Kết quả mong đợi: Trạng thái Pod là `ContainerCreating` nhưng bị treo hoặc bị xóa, trong phần `Events` xuất hiện dòng `Forbidden` với lý do `policy ai-workload-no-root` bị vi phạm. Tiếp theo, thử deploy một Pod tuân thủ (không chạy root) để xác nhận luồng hợp lệ vẫn hoạt động.
Cấu hình Auto-scaling cho workload AI dựa trên lượng request thực tế
Trong môi trường Edge AI, tài nguyên hạn chế nên việc tự động mở rộng (scale-up) khi có nhiều request và thu nhỏ (scale-down) khi rảnh rỗi là bắt buộc để tối ưu chi phí và hiệu năng.
Chúng ta sẽ sử dụng KEDA (Kubernetes Event-driven Autoscaling) kết hợp với Prometheus Adapter để scale dựa trên số lượng request HTTP hoặc độ trễ (latency) của model AI.
Triển khai KEDA và Prometheus Adapter vào cluster KubeEdge.
helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda --namespace keda --create-namespace --version 2.14.0
Kết quả mong đợi: KEDA được cài đặt thành công, các pod trong namespace `keda` ở trạng thái `Running`.
Cấu hình ScaledObject cho workload AI
Giả sử bạn đã có một Deployment AI tên là `ai-inference-service` trong namespace `ai-inference`. Chúng ta cần tạo một ScaledObject để liên kết Deployment này với metric từ Prometheus (ví dụ: số lượng request trên 1 giây).
Tạo file cấu hình tại `/etc/kubeedge/scaling/ai-scaledobject.yaml` với nội dung hoàn chỉnh:
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: ai-inference-scaler
namespace: ai-inference
spec:
scaleTargetRef:
name: ai-inference-service
minReplicaCount: 1
maxReplicaCount: 10
triggers:
- type: prometheus
metadata:
serverAddress: http://prometheus-server.monitoring.svc.cluster.local:9090
metricName: http_requests_total
threshold: "50"
query: |
sum(rate(http_requests_total{app="ai-inference"}[1m]))
offset: "5"
Áp dụng cấu hình ScaledObject để kích hoạt cơ chế tự động mở rộng.
kubectl apply -f /etc/kubeedge/scaling/ai-scaledobject.yaml
Kết quả mong đợi: KEDA bắt đầu theo dõi metric. Nếu lượng request vượt quá 50 req/s (cộng với offset 5), KEDA sẽ tăng số lượng replica của `ai-inference-service`. Ngược lại, nếu request giảm xuống dưới ngưỡng, nó sẽ giảm replica về mức tối thiểu là 1.
Verify kết quả Auto-scaling
Kiểm tra trạng thái của ScaledObject để xem KEDA đang tính toán metric như thế nào.
kubectl get scaledobject ai-inference-scaler -n ai-inference -o yaml
Để mô phỏng traffic, tạo một script đơn giản gửi request liên tục vào service AI của bạn và quan sát số lượng pod.
watch -n 2 'kubectl get pods -n ai-inference -l app=ai-inference-service'
Kết quả mong đợi: Khi bạn tạo traffic, số lượng pod sẽ tăng lên (scale-up) trong vòng 30-60 giây. Khi dừng traffic, sau một khoảng thời gian cooldown, số lượng pod sẽ giảm xuống (scale-down) về 1 pod.
Triển khai cập nhật phần mềm không gián đoạn (Rolling Update) cho Service Mesh
Trong môi trường Edge, việc mất kết nối hoặc downtime của Service Mesh (Istio) sẽ làm tê liệt toàn bộ giao tiếp giữa Cloud và Edge. Chúng ta cần chiến lược Rolling Update an toàn.
Mục tiêu là cập nhật phiên bản Istio hoặc các component liên quan mà không làm gián đoạn traffic đang chạy giữa các Pod AI.
Sử dụng Helm để thực hiện update với chiến lược `RollingUpdate` và cấu hình `maxUnavailable: 0` để đảm bảo luôn có instance sẵn sàng.
helm upgrade istio-base istio/istio-base -n istio-system --set "defaultRevision=default" --wait
helm upgrade istiod istio/istiod -n istio-system --set "revision=default" --wait --set "autoscaler.minReplicas=2"
Kết quả mong đợi: Các Pod của `istiod` được cập nhật theo lượt, đảm bảo ít nhất 2 instance luôn hoạt động trong quá trình cập nhật. Traffic không bị ngắt quãng.
Cấu hình Strategy cho Data Plane (Sidecar Injector)
Các Pod workload AI cần được cập nhật Sidecar Proxy (istio-proxy) một cách mượt mà. Chúng ta cấu hình Deployment của AI với `RollingUpdate` strategy cụ thể.
Cập nhật file Deployment của workload AI tại `/etc/kubeedge/deployments/ai-inference-service.yaml` (hoặc tạo mới nếu chưa có) với cấu hình strategy an toàn:
apiVersion: apps/v1
kind: Deployment
metadata:
name: ai-inference-service
namespace: ai-inference
labels:
app: ai-inference-service
spec:
replicas: 3
selector:
matchLabels:
app: ai-inference-service
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
template:
metadata:
labels:
app: ai-inference-service
istio-injection: enabled
spec:
containers:
- name: ai-model
image: your-registry/ai-model:v2.0.0
ports:
- containerPort: 8080
resources:
limits:
cpu: "2"
memory: "4Gi"
requests:
cpu: "500m"
memory: "2Gi"
Áp dụng file cấu hình mới để kích hoạt chiến lược rolling update cho workload.
kubectl apply -f /etc/kubeedge/deployments/ai-inference-service.yaml
Kết quả mong đợi: Kubernetes sẽ tạo thêm 1 pod mới (maxSurge=1) trước khi xóa các pod cũ, đảm bảo số lượng pod hoạt động luôn duy trì ở mức 3, không bao giờ giảm xuống dưới mức này trong quá trình update.
Verify kết quả Rolling Update
Quan sát quá trình cập nhật của Deployment để xác nhận không có downtime.
kubectl rollout status deployment/ai-inference-service -n ai-inference
Kiểm tra số lượng pod trong quá trình update để đảm bảo `maxUnavailable: 0` được tuân thủ.
kubectl get pods -n ai-inference -l app=ai-inference-service -w
Kết quả mong đợi: Dòng lệnh `rollout status` báo `deployment "ai-inference-service" successfully rolled out`. Trong quá trình đó, bạn sẽ thấy số lượng pod tăng lên 4 (3 cũ + 1 mới) trước khi giảm về 3, không bao giờ thấy số lượng pod hoạt động giảm xuống dưới 3.
Xây dựng pipeline CI/CD tự động kiểm tra bảo mật trước khi deploy lên Edge
Để đảm bảo an toàn từ giai đoạn phát triển, chúng ta cần tích hợp các bước kiểm tra bảo mật (Security Scanning) vào pipeline CI/CD trước khi artifact được đẩy lên Edge.
Pipeline sẽ thực hiện: Scan mã nguồn (Static Analysis), Scan Docker Image (Vulnerability Scan), và kiểm tra chính sách OPA (Policy Check) trước khi thực hiện deploy.
Sử dụng GitLab CI hoặc GitHub Actions. Dưới đây là cấu hình cho GitHub Actions file `.github/workflows/edge-ai-secure-deploy.yml`.
name: Edge AI Secure Deploy
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
- name: Build Docker Image
uses: docker/build-push-action@v5
with:
context: .
push: false
tags: ai-model:latest
load: true
- name: Run Trivy Vulnerability Scan
uses: aquasecurity/trivy-action@master
with:
image-ref: 'ai-model:latest'
format: 'sarif'
output: 'trivy-results.sarif'
severity: 'CRITICAL,HIGH'
- name: Upload Trivy Scan Results
uses: github/codeql-action/upload-sarif@v2
with:
sarif_file: 'trivy-results.sarif'
- name: Run OPA Gatekeeper Policy Check
run: |
pip install opa
opa eval --data /app/policies/ai-security.rego --input /app/deployment.yaml 'data.k8s.security.allowed'
deploy-to-edge:
needs: security-scan
runs-on: ubuntu-latest
if: github.event_name == 'push' && github.ref == 'refs/heads/main'
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Configure kubectl
uses: azure/k8s-set-context@v3
with:
method: kubeconfig
kubeconfig: ${{ secrets.KUBECONFIG_EDGE }}
- name: Deploy to KubeEdge
run: |
kubectl set image deployment/ai-inference-service ai-model=your-registry/ai-model:${{ github.sha }} -n ai-inference
kubectl rollout status deployment/ai-inference-service -n ai-inference --timeout=300s
Commit file workflow này vào repository của dự án để kích hoạt pipeline tự động.
git add .github/workflows/edge-ai-secure-deploy.yml
git commit -m "Add secure CI/CD pipeline for Edge AI"
git push origin main
Kết quả mong đợi: Khi bạn push code lên branch `main`, GitHub Actions sẽ tự động chạy. Nếu Trivy phát hiện lỗ hổng Critical/High hoặc OPA check fail, pipeline sẽ dừng lại và không thực hiện bước deploy. Chỉ khi scan sạch, pipeline mới tiến hành cập nhật image lên KubeEdge.
Verify kết quả pipeline CI/CD
Đẩy một commit chứa lỗi bảo mật giả lập (ví dụ: thêm một package có lỗ hổng vào Dockerfile) để kiểm tra xem pipeline có chặn không.
git commit --allow-empty -m "Simulate vulnerable code"
git push origin main
Vào tab "Actions" trên GitHub để xem trạng thái của workflow.
Kết quả mong đợi: Workflow hiển thị màu đỏ (Failed) ở bước `Run Trivy Vulnerability Scan` hoặc `Run OPA Gatekeeper Policy Check`. Không có lệnh deploy nào được gửi đến cluster KubeEdge. Sau đó, sửa lỗi, commit lại và push, workflow sẽ chuyển sang màu xanh (Success) và thực hiện deploy thành công.
Điều hướng series:
Mục lục: Series: Xây dựng hệ thống Service Mesh an toàn cho Edge AI với KubeEdge và eBPF
« Phần 6: Giám sát, phân tích và Troubleshooting hệ thống Edge AI