1. Đặt Vấn Đề: Mối Đe Dọa Từ Tấn Công Nội Bộ (Lateral Movement) Trên K3s

K3s hiện là một trong những bản phân phối Kubernetes tối giản (lightweight) được ưa chuộng nhất để triển khai ứng dụng trên các máy chủ ảo (VPS). Với ưu điểm gọn nhẹ, tiết kiệm tài nguyên và dễ cài đặt, K3s giúp doanh nghiệp tối ưu hóa chi phí vận hành một cách đáng kể. Tuy nhiên, sự tiện lợi này thường đi kèm với những lỗ hổng bảo mật nghiêm trọng nếu cấu hình mặc định không được thắt chặt.

Theo cơ chế mặc định của Kubernetes nói chung và K3s nói riêng, tất cả các Pod trong cluster đều có thể giao tiếp với nhau mà không gặp bất kỳ rào cản nào. Điều này mở ra một cơ hội lớn cho các hacker thực hiện kỹ thuật Lateral Movement (Dịch chuyển ngang).

Lateral Movement là kỹ thuật mà kẻ tấn công, sau khi chiếm quyền kiểm soát một Pod có bảo mật yếu (ví dụ: một ứng dụng web có lỗ hổng Log4j hoặc SQL Injection), sẽ tiếp tục quét dịch vụ và tấn công sang các Pod quan trọng khác trong hệ thống, chẳng hạn như Cơ sở dữ liệu (Database) hoặc các dịch vụ nội bộ chứa thông tin nhạy cảm.

Khi triển khai K3s trên môi trường VPS công cộng, nguy cơ này càng tăng cao do các node thường tiếp xúc trực tiếp với Internet. Do đó, việc thiết lập một giải pháp tường lửa tầng mạng (Network Security) mạnh mẽ là yêu cầu bắt buộc đối với mọi kiến trúc sư hệ thống.

2. Tại Sao Chọn Cilium Thay Vì CNI Mặc Định Của K3s?

Mặc định, K3s sử dụng Flannel làm Container Network Interface (CNI). Flannel hoàn thành tốt nhiệm vụ kết nối mạng cơ bản nhưng lại hoàn toàn không hỗ trợ Network Policy. Để bảo mật, lập trình viên thường phải cài đặt thêm Calico hoặc giải pháp tương đương. Tuy nhiên, Cilium nổi lên như một vị cứu tinh vượt trội nhờ ứng dụng công nghệ eBPF (Extended Berkeley Packet Filter).

Cilium mang lại những lợi ích đột phá so với các CNI truyền thống:

Hiệu năng tối ưu: Lọc gói tin trực tiếp từ tầng Kernel của Linux thông qua eBPF, bỏ qua việc xử lý phức tạp và chậm chạp của iptables.
Bảo mật ở tầng 7 (Application Layer): Không chỉ chặn IP/Port (Tầng 3/4), Cilium cho phép kiểm soát chi tiết các truy vấn HTTP (GET, POST), REST API, gRPC hoặc Kafka.
Giám sát trực quan (Observability): Tích hợp Hubble giúp quản trị viên quan sát luồng đi của dữ liệu (traffic) theo thời gian thực một cách tường minh.

3. Kiến Trúc Triển Khai Cilium Trên K3s (VPS)

Để cấu hình Cilium nâng cao, trước hết bạn cần khởi tạo cụm K3s mà không sử dụng Flannel mặc định. Câu lệnh khởi tạo thông thường trên VPS sẽ như sau:

curl -sfL [https://get.k3s.io](https://get.k3s.io) | sh -s - server --flannel-backend=none --disable-network-policy

Sau khi cài đặt K3s, Cilium sẽ được cài đặt thông qua Helm Chart với chế độ eBPF native để thay thế hoàn toàn kube-proxy, giúp tăng tốc độ xử lý gói tin và loại bỏ gánh nặng cấu hình iptables trên VPS.

4. Cấu Hình Cilium Network Policies Nâng Cao Để Chống Lateral Movement

Để ngăn chặn tấn công dịch chuyển ngang, chúng ta cần áp dụng nguyên tắc Zero Trust: Khóa toàn bộ kết nối mặc định và chỉ mở các luồng giao tiếp thực sự cần thiết.

Bước 4.1: Áp dụng Quy tắc Default Deny (Khóa Toàn Bộ)

Chiến lược bảo mật khôn ngoan nhất là cô lập hoàn toàn các Pod trong một Namespace. Dưới đây là cấu hình CiliumNetworkPolicy (CNP) để chặn toàn bộ lưu lượng Ingress (vào) và Egress (ra) ngoại trừ dịch vụ DNS nội bộ:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "default-deny-all"
  namespace: production
spec:
  endpointSelector:
    matchLabels: {}
  ingress:
  - {}
  egress:
  - toEndpoints:
    - matchLabels:
        "k8s:io.kubernetes.pod.namespace": kube-system
        k8s-app: kube-dns
    toPorts:
    - ports:
      - port: "53"
        protocol: UDP

Giải thích: Cấu hình này chọn tất cả các Pod (matchLabels: {}) trong namespace production, chặn toàn bộ kết nối đến nhưng cho phép kết nối ra ngoài duy nhất tới kube-dns để phân giải tên miền.

Bước 4.2: Phân Quyền Truy Cập Tầng 4 (L4) Cho Ứng Dụng Multi-Tier

Giả sử bạn có một ứng dụng Web (Frontend) cần kết nối tới Cơ sở dữ liệu (Database). Để chống Lateral Movement, chúng ta chỉ cho phép đúng Pod Frontend truy cập vào Pod Database qua cổng 5432 (PostgreSQL), mọi Pod khác cố gắng quét cổng này đều sẽ bị chặn đứng.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-frontend-to-db"
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: postgres-db
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: web-frontend
    toPorts:
    - ports:
      - port: "5432"
        protocol: TCP

Bước 4.3: Chống Tấn Công Giả Mạo API Bằng Bảo Mật Tầng 7 (L7 HTTP)

Đây là tính năng độc quyền và mạnh mẽ của Cilium. Kẻ tấn công nếu chiếm được quyền điều khiển web-frontend có thể cố gắng thực hiện các lệnh nguy hiểm (như DELETE, PUT) tới các dịch vụ nội bộ khác. Chúng ta có thể giới hạn chỉ cho phép phương thức GET tại đường dẫn cụ thể:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "restrict-api-access"
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: internal-api-service
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: web-frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/v1/public/.*"

Với cấu hình trên, nếu kẻ tấn công gửi một yêu cầu DELETE /v1/public/data, hệ thống eBPF của Cilium sẽ lập tức hủy gói tin ngay tại tầng nhân, ngăn chặn hoàn toàn nguy cơ phá hoại dữ liệu.

5. Giám Sát Và Xác Thực Chính Sách Bằng Cilium Hubble

Việc cấu hình Network Policy rất dễ dẫn đến tình trạng "chặn nhầm" khiến ứng dụng bị lỗi. Cilium giải quyết triệt để vấn đề này bằng công cụ Hubble.

Bằng cách kích hoạt Hubble UI hoặc sử dụng CLI, bạn có thể kiểm tra xem các kết nối nào đang bị chặn (Dropped) hoặc được cho phép (Forwarded). Câu lệnh CLI hữu ích để kiểm tra:

hubble observe --pod web-frontend --verdict DROPPED

Màn hình sẽ hiển thị chính xác dòng traffic nào bị từ chối, giúp kỹ sư DevSecOps nhanh chóng điều chỉnh policy mà không phải đoán mò dựa trên log ứng dụng.

6. Kết Luận Và Khuyến Nghị Cho Doanh Nghiệp

Bảo mật cụm K3s trên VPS không còn là tùy chọn mà là yếu tố sống còn khi đưa ứng dụng lên môi trường sản xuất (Production). Sử dụng Cilium Network Policy kết hợp với sức mạnh của eBPF mang lại khả năng phòng thủ vững chắc trước các kỹ thuật tấn công nội bộ (Lateral Movement) tinh vi nhất.

Để tối ưu hóa bảo mật, doanh nghiệp nên áp dụng lộ trình sau:

Triển khai Cilium ở chế độ Audit Mode để theo dõi luồng giao tiếp thực tế của ứng dụng mà không chặn traffic.
Dựa vào dữ liệu từ Hubble để viết các bộ quy tắc thắt chặt (Zero Trust).
Chuyển sang chế độ Enforcement Mode để chính thức bảo vệ hệ thống.
Tích hợp kiểm tra Network Policy vào quy trình CI/CD để đảm bảo mọi microservice mới sinh ra đều được bảo vệ nghiêm ngặt.

Bảo Mật K3s Nâng Cao: Chặn Tấn Công Lateral Movement Bằng Cilium Network Policy Trên VPS