Kiểm tra bảo mật Kubernetes: Tăng cường bảo mật Cluster với kube-bench và kube-hunter

Table of Contents

Bảo mật Kubernetes vượt xa các thiết lập mặc định

Triển khai một cluster Kubernetes là phần dễ dàng. Thách thức thực sự bắt đầu khi bạn nhận ra rằng các cấu hình mặc định thường ưu tiên tính năng “chỉ cần chạy được” hơn là “được khóa chặt chẽ”. Tôi đã thấy nhiều đội ngũ để lộ API server hoặc sử dụng token tài khoản dịch vụ (service account tokens) mặc định chỉ vì họ không biết phải bật tắt nút bảo mật nào trong số hơn 100 tùy chọn hiện có.

Để tự động hóa quy trình kiểm tra (audit), chúng tôi sử dụng hai công cụ tiêu chuẩn trong ngành: kube-bench và kube-hunter. Mặc dù cả hai đều tập trung vào bảo mật, chúng giải quyết vấn đề từ các góc độ khác nhau. Một bên kiểm tra bản thiết kế, trong khi bên còn lại cố gắng bẻ khóa. Hiểu cách kết hợp chúng là bí quyết để có một môi trường thực sự kiên cố.

Người kiểm tra vs. Kẻ tấn công

Khi tôi kiểm tra một cluster, tôi nhìn nhận nó qua hai lăng kính: vệ sinh cấu hình tĩnh và khả năng khai thác thực tế.

Kiểm tra cấu hình tĩnh (kube-bench)

Hãy coi kube-bench như một thanh tra xây dựng. Nó so sánh các thiết lập cluster của bạn với tiêu chuẩn Kubernetes của Center for Internet Security (CIS). Nó kiểm tra các lỗi cụ thể, chẳng hạn như cơ sở dữ liệu etcd của bạn có được mã hóa khi lưu trữ hay không hoặc API server có cho phép --anonymous-auth (xác thực ẩn danh) không. Đây là một công cụ dựa trên danh sách kiểm tra (checklist) để đảm bảo bạn đã tuân thủ đúng hướng dẫn trong quá trình cài đặt.

Quét lỗ hổng chủ động (kube-hunter)

Kube-hunter hoạt động giống như một chuyên gia kiểm thử xâm nhập (penetration tester). Nó không quan tâm các tệp cấu hình nói gì; nó quan tâm đến việc liệu nó có thực sự đột nhập được hay không. Nó dò tìm các cổng mở như 10250 (Kubelet API) hoặc 2379 (etcd) và tìm kiếm các bảng điều khiển (dashboard) bị cấu hình sai. Bạn có thể chạy nó từ bên ngoài để xem những gì một hacker thấy, hoặc từ bên trong một pod để mô phỏng một container độc hại đang cố gắng di chuyển ngang (lateral movement) qua mạng của bạn.

Ưu điểm & Nhược điểm

kube-bench

Ưu điểm: Đây là tiêu chuẩn vàng cho tính tuân thủ. Nếu khách hàng yêu cầu báo cáo CIS, công cụ này cung cấp chính xác dữ liệu “ĐẠT/KHÔNG ĐẠT” mà họ cần. Nó thậm chí còn cung cấp cho bạn các lệnh shell cụ thể để khắc phục từng lỗi.
Nhược điểm: Nó chỉ nhìn thấy những gì trên đĩa cứng. Nó sẽ không phát hiện ra lỗ hổng zero-day trong mã ứng dụng hoặc các mối đe dọa lén lút trong lúc thực thi (runtime).

kube-hunter

Ưu điểm: Nó khám phá các con đường tấn công thực tế. Nó xác định các rủi ro nghiêm trọng như các cổng Kubelet không được xác thực mà các kiểm tra tĩnh có thể bỏ qua nếu chính tiến trình đó đang chạy với các thiết lập mặc định không an toàn.
Nhược điểm: Kết quả đầu ra có thể khá nhiễu. Một số phát hiện có thể chỉ là tiết lộ thông tin “nguy cơ thấp” (như số phiên bản) không phải là mối đe dọa tức thời, đòi hỏi con người phải lọc kết quả.

Quy trình làm việc chuyên nghiệp

Tôi khuyên bạn nên sử dụng phương pháp kết hợp. Chạy kube-bench trong lần thiết lập ban đầu và sau mỗi lần nâng cấp phiên bản chính. Điều này giúp cơ sở hạ tầng cốt lõi của bạn luôn tuân thủ tiêu chuẩn. Sau đó, hãy tích hợp kube-hunter vào pipeline CI/CD của bạn hoặc chạy nó như một tác vụ định kỳ (cron job) hàng tuần. Điều này giúp phát hiện các lỗ hổng bảo mật mới phát sinh do việc triển khai mới hoặc sự sai lệch cấu hình (configuration drift).

Khi tôi khắc phục các vấn đề này, tôi thường cần tạo mật khẩu mạnh và duy nhất cho các tài khoản dịch vụ. Tôi sử dụng trình tạo mật khẩu trên trình duyệt tại toolcraft.app cho việc này. Vì nó chạy hoàn toàn trong trình duyệt cục bộ của bạn, không có khóa nhạy cảm nào được gửi qua mạng. Đó là một thói quen nhỏ giúp ngăn chặn rò rỉ thông tin xác thực trong giai đoạn khắc phục sự cố.

Hướng dẫn triển khai

Bước 1: Chạy kube-bench dưới dạng một Job

Cách đáng tin c nhất để kiểm tra một cluster là chạy kube-bench dưới dạng một Kubernetes Job. Điều này cung cấp cho công cụ các quyền cần thiết để kiểm tra hệ thống tệp của máy chủ và các tiến trình của control plane.

# Tạo job kiểm tra
cat <<EOF > kube-bench-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench
spec:
  template:
    spec:
      hostPID: true
      containers:
        - name: kube-bench
          image: aquasec/kube-bench:latest
          command: ["kube-bench"]
          volumeMounts:
            - name: var-lib-etcd
              mountPath: /var/lib/etcd
              readOnly: true
            - name: var-lib-kubelet
              mountPath: /var/lib/kubelet
              readOnly: true
            - name: etc-systemd
              mountPath: /etc/systemd
              readOnly: true
            - name: etc-kubernetes
              mountPath: /etc/kubernetes
              readOnly: true
      restartPolicy: Never
      volumes:
        - name: var-lib-etcd
          hostPath:
            path: /var/lib/etcd
        - name: var-lib-kubelet
          hostPath:
            path: /var/lib/kubelet
        - name: etc-systemd
          hostPath:
            path: /etc/systemd
        - name: etc-kubernetes
          hostPath:
            path: /etc/kubernetes
EOF

# Chạy kiểm tra
kubectl apply -f kube-bench-job.yaml

Kiểm tra nhật ký (logs) sau khi pod hoàn tất. Bạn sẽ thấy bảng phân tích chi tiết cho Master Node và các Worker Node. Hãy tìm kiếm cụ thể những mục được đánh dấu [FAIL].

Bước 2: Khắc phục nhanh chóng

Phần hay nhất của báo cáo kube-bench là mục “Remediations” (Khắc phục). Nó không chỉ đưa ra cảnh báo; nó cung cấp giải pháp. Ví dụ: nếu nó đánh dấu lỗi 1.2.19 Đảm bảo rằng đối số --insecure-port được đặt thành 0, nó sẽ cho bạn biết chính xác tệp manifest nào cần chỉnh sửa để lấp lỗ hổng đó.

Bước 3: Tìm kiếm lỗ hổng

Với các tệp cấu hình đã được bảo mật, đã đến lúc kiểm tra vòng ngoài. Tôi thường bắt đầu bằng cách chạy một bản quét từ xa từ máy trạm của mình để xem những gì có thể nhìn thấy từ internet công cộng.

# Quét từ xa qua Docker
docker run -it --rm aquasec/kube-hunter --remote 1.2.3.4 # Thay thế bằng IP của Cluster bạn

Để mô phỏng một “mối đe dọa nội bộ”, hãy chạy một bản quét ở cấp độ pod. Điều này cho thấy điều gì sẽ xảy ra nếu một trong các ứng dụng của bạn bị xâm nhập:

kubectl run kube-hunter --image=aquasec/kube-hunter --restart=Never -- --pod-scan

Bước 4: Thắt chặt vòng ngoài

Sau khi xem xét các báo cáo, hãy ưu tiên các bản sửa lỗi của bạn. Bắt đầu với các mục có mức độ nghiêm trọng “High” (Cao) từ kube-hunter. Thông thường, việc này bao gồm cập nhật các manifest của API Server, hạn chế quyền truy cập vào /metrics và triển khai Network Policies để chặn các pod nói chuyện với Kubelet API. Tăng cường bảo mật là một cuộc chạy marathon, không phải một cuộc chạy nước rút. Việc chạy các công cụ này hàng tháng đảm bảo rằng những sai lệch nhỏ không biến thành những vụ xâm nhập lớn.