Cấu hình Hardening theo chuẩn CIS Benchmark cho Host và Runtime
Áp dụng các quy tắc bảo mật khắt khe từ CIS Benchmark để giảm bề mặt tấn công (attack surface) của host Linux trước khi triển khai các workload AI nhạy cảm.
Việc này đảm bảo kernel và các dịch vụ nền tảng đã được "chốt" lại, ngăn chặn các kỹ thuật nâng cao quyền (privilege escalation) từ bên trong container.
Kết quả mong đợi: Host chỉ cho phép các syscall cần thiết, tắt các module kernel không dùng, và khóa các cấu hình file hệ thống quan trọng.
1.1 Khóa cấu hình Kernel với Sysctl
Thiết lập các tham số kernel để ngăn chặn các tấn công mạng phổ biến như IP spoofing, SYN flood và tắt khả năng forward gói tin không cần thiết.
Thay đổi trực tiếp trong file cấu hình để thay đổi có hiệu lực ngay sau khi khởi động lại.
cat > /etc/sysctl.d/99-cis-hardening.conf
Áp dụng cấu hình ngay lập tức và khóa file để không ai sửa đổi.
sysctl --system
chmod 600 /etc/sysctl.d/99-cis-hardening.conf
Kiểm tra xem các tham số đã được áp dụng chưa.
sysctl net.ipv4.tcp_syncookies
Kết quả mong đợi: Output trả về `net.ipv4.tcp_syncookies = 1`.
1.2 Giới hạn Syscall cho Kata Containers và gVisor
Giới hạn danh sách các hệ thống gọi (syscalls) mà container được phép thực thi. Đây là lớp bảo vệ quan trọng nhất để ngăn malware trong sandbox truy cập vào host kernel.
Sử dụng seccomp profile để whitelist các syscall cần thiết cho AI workloads (thường là `read`, `write`, `mmap`, `open`, `close`, `clock_gettime`, `stat`...).
cat > /etc/kata-containers/seccomp-profile.json
Kiểm tra file seccomp đã được tạo và có quyền đọc đúng.
ls -l /etc/kata-containers/seccomp-profile.json
Kết quả mong đợi: File tồn tại với quyền `644` (đọc được bởi runtime) và chứa danh sách syscall đã whitelist.
Cấu hình Audit Log để phát hiện hành vi bất thường
Triển khai `auditd` để ghi lại mọi hoạt động truy cập file, thay đổi quyền, và các syscall nhạy cảm trong sandbox. Đây là nguồn dữ liệu chính để phân tích sự cố (forensics).
Chúng ta cần cấu hình audit để theo dõi các thư mục mount của AI models và các hành động `execve` của các binary không tin cậy.
Kết quả mong đợi: Các file log tại `/var/log/audit/audit.log` ghi lại chi tiết ai, khi nào, và làm gì với các tài nguyên nhạy cảm.
2.1 Khởi tạo và cấu hình Audit Rules
Thiết lập các quy tắc để audit theo dõi thư mục chứa mô hình AI và thư viện gVisor/Kata.
Các quy tắc này sẽ bắt mọi thao tác đọc/ghi/chạy trên các đường dẫn nhạy cảm.
cat > /etc/audit/rules.d/99-ai-sandbox.rules -1 -k privileged_syscalls
# Theo dõi các lệnh exec trong sandbox (phát hiện malware chạy code lạ)
-a always,exit -F arch=b64 -S execve -F a0=/var/ai/models/* -k ai_exec_attempt
-a always,exit -F arch=b64 -S execve -F a0=/tmp/* -k tmp_exec_attempt
# Theo dõi việc thay đổi file hệ thống quan trọng
-w /etc/passwd -p wa -k identity_files
-w /etc/shadow -p wa -k identity_files
-w /etc/group -p wa -k identity_files
EOF
Khởi động lại dịch vụ auditd để áp dụng các rules mới.
systemctl restart auditd
Kiểm tra xem các rules đã được nạp thành công chưa.
auditctl -l
Kết quả mong đợi: Danh sách rules hiển thị các đường dẫn đã cấu hình và key tương ứng.
2.2 Cấu hình Log Rotation và Size
Ngăn chặn disk full do log audit quá lớn, đồng thời đảm bảo log quan trọng không bị xóa quá sớm.
Cấu hình `auditd.conf` để giới hạn kích thước file log và số lượng file lưu trữ.
cat > /etc/audit/auditd.conf
Khởi động lại dịch vụ auditd.
systemctl restart auditd
Kiểm tra file cấu hình đã được áp dụng.
auditctl -s
Kết quả mong đợi: Output hiển thị trạng thái `max_log_file` và các thông số đã được cập nhật.
Chiến lược Troubleshooting cho Policy Engine và Runtime
Xử lý các tình huống khi OPA/Gatekeeper chặn sai (False Positive) làm gián đoạn training AI, hoặc khi runtime (Kata/gVisor) crash do lỗi memory hoặc syscall bị chặn.
Sử dụng các công cụ debugging chuyên sâu như `kubectl describe`, `audit.log`, và `journalctl` để truy vết nguyên nhân.
Kết quả mong đợi: Xác định được nguyên nhân chính xác của sự cố và có cách khắc phục không ảnh hưởng đến bảo mật tổng thể.
3.1 Xử lý False Positive từ Policy Engine (OPA/Gatekeeper)
Khi Pod bị treo ở trạng thái `ContainerCreating` hoặc bị xóa ngay lập tức, nguyên nhân thường là Policy Engine chặn deployment.
Chúng ta cần xem logs của controller và request bị chặn để điều chỉnh policy.
kubectl describe pod -n
Truy cập logs của Gatekeeper Controller (thường nằm trong namespace `gatekeeper-system`) để xem chi tiết audit log của request bị chặn.
kubectl logs -n gatekeeper-system -l app=gatekeeper-audit --tail=100
Kiểm tra logs của OPA Eval (nếu dùng OPA standalone) để xem chính sách nào bị vi phạm.
kubectl logs -n gatekeeper-system -l app=gatekeeper-controller --tail=50
Kiểm tra file policy bị lỗi (ví dụ: `deny.yaml` trong ConfigMap).
kubectl get configmap gatekeeper-policy-deny -n gatekeeper-system -o yaml
Khắc phục: Điều chỉnh `Constraint` trong Kubernetes hoặc thêm `ConstraintTemplate` mới để whitelist trường hợp đặc biệt.
cat > /tmp/fix-policy.yaml
Áp dụng policy mới để ghi đè hoặc bổ sung.
kubectl apply -f /tmp/fix-policy.yaml
Kết quả mong đợi: Pod chuyển sang trạng thái `Running` và logs audit không còn hiển thị `deny` cho image này.
3.2 Debugging Runtime Crash (Kata Containers / gVisor)
Khi container bị crash ngay khi khởi động (Exit Code 137, 139, hoặc 0 nhưng không up), cần kiểm tra logs của runtime và audit log.
Exit code 137 thường là OOM Killer (Out of Memory), 139 là Segmentation Fault (do syscall bị chặn hoặc lỗi code).
kubectl logs -n
Kiểm tra logs của Kata Runtime (thường là `containerd` hoặc `qemu` logs).
journalctl -u containerd -f --no-pager | grep -i "kata\|qemu\|error"
Kiểm tra logs của gVisor (`runsc`) nếu sử dụng gVisor.
journalctl -u runsc -f --no-pager | grep -i "error\|panic"
Truy xuất Audit Log để xem container đã cố thực thi syscall nào trước khi crash.
ausearch -k ai_exec_attempt -i -ts recent
Kiểm tra xem có syscall nào bị chặn (denied) trong audit log không.
ausearch -m syscall -i -ts recent | grep "arch=b64" | grep "a0=1" # Ví dụ tìm syscall với số 1 (write)
Khắc phục: Nếu do syscall bị chặn, thêm syscall đó vào seccomp profile (phần 1.2). Nếu do OOM, tăng `resources.limits.memory` trong Pod spec.
cat > /tmp/pod-fix.yaml
Áp dụng lại cấu hình đã sửa.
kubectl apply -f /tmp/pod-fix.yaml
Kết quả mong đợi: Pod khởi động thành công, không còn crash và logs audit không ghi nhận syscall bị chặn.
Đ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 7: Giám sát, logging và phân tích sự cố trong môi trường sandbox kép