Giới thiệu dự án

Trong kỷ nguyên điện toán đám mây (Cloud-Native), kiến trúc vi dịch vụ (Microservices) kết hợp với nền tảng điều phối vùng chứa Kubernetes (K8s) đã trở thành tiêu chuẩn công nghiệp cho các hệ thống phần mềm quy mô lớn. Theo khảo sát từ Cloud Native Computing Foundation (CNCF), hơn 84% tổ chức doanh nghiệp toàn cầu đã đưa Kubernetes vào môi trường sản xuất. Tuy nhiên, mô hình mạng phẳng (flat network) mặc định của Kubernetes cùng các cơ chế lọc gói truyền thống dựa trên iptables và kube-proxy đang bộc lộ những lỗ hổng bảo mật nghiêm trọng và rào cản hiệu năng lớn khi số lượng Pod và dịch vụ tăng trưởng theo cấp số nhân.

+-----------------------------------------------------------------------------------+
|                           MÔ HÌNH THÁCH THỨC BẢO MẬT K8S                          |
+-----------------------------------------------------------------------------------+
|  [ K8s Network Phẳng ] ---> [ Tấn công Leo thang / Lateral Movement giữa Pods ]  |
|  [ kube-proxy iptables] ---> [ Độ trễ O(N) khi quy tắc tăng vọt, tiêu tốn CPU ]   |
|  [ Vanilla NetworkPolicy] -> [ Chỉ lọc L3/L4, mù hoàn toàn lưu lượng L7 HTTP/API] |
|  [ Thiếu mTLS & Crypto ] -> [ Dữ liệu truyền thô giữa các Node chưa được mã hóa]  |
+-----------------------------------------------------------------------------------+

Khóa luận "Triển khai giải pháp bảo mật cho hệ thống Kubernetes sử dụng Cilium" của tác giả Bạch Văn Xuân Thông (Chuyên ngành An toàn Thông tin, Trường Đại học Công nghệ Thông tin – ĐHQG-HCM, 2024; Cán bộ hướng dẫn: ThS. Trần Thị Dung) tập trung giải quyết triệt để các hạn chế trên bằng cách ứng dụng công nghệ eBPF (Extended Berkeley Packet Filter) thông qua CNI Cilium, mang lại cơ chế phòng thủ sâu từ tầng nhân Linux (Kernel Space).

Mục tiêu dự án

  1. Xây dựng cụm Kubernetes phân tán hoàn chỉnh: Triển khai môi trường thử nghiệm đa Node bằng Minikube, phân bổ tải cho ứng dụng vi dịch vụ Sock Shop đa ngôn ngữ (NodeJS, Go, Java, .NET Core, Python) kết hợp cơ sở dữ liệu phân tán (MongoDB, MySQL, RabbitMQ).
  2. Triển khai hạ tầng mạng eBPF thế hệ mới với Cilium: Thay thế cơ chế định tuyến truyền thống, tối ưu hóa đường truyền dữ liệu (datapath) trực tiếp tại Kernel Space mà không làm thay đổi mã nguồn ứng dụng.
  3. Thực thi chính sách bảo mật đa tầng (L3/L4/L7): Thiết lập các luật kiểm soát truy cập dựa trên danh tính (Identity-based Security), kiểm duyệt chi tiết các lời gọi API HTTP methods/paths và kiểm soát lưu lượng ra ngoài (Egress) dựa trên phân giải tên miền DNS.
  4. Mã hóa lưu lượng trong suốt (Transparent Encryption): Kích hoạt đường hầm WireGuard tích hợp sẵn ở mức Kernel nhằm mã hóa toàn bộ dữ liệu trao đổi giữa các Worker Node mà không yêu cầu cấu hình chứng chỉ phức tạp.
  5. Xác thực danh tính công việc bằng SPIFFE/SPIRE: Thiết lập cơ chế mTLS (Mutual Authentication) phi tập trung để xác thực danh tính mã hóa tự động cho từng Pod.
  6. Xây dựng hệ thống quan sát mạng phân tán với Hubble: Khai thác Hubble Relay và Hubble UI để trực quan hóa bản đồ kết nối (Service Dependency Map) và luồng gói tin thời gian thực.

Phương pháp tiếp cận và phạm vi nghiên cứu

  • Phương pháp: Kết hợp nghiên cứu lý thuyết chuyên sâu về Linux Kernel eBPF, cơ chế mạng CNI trong K8s với phương pháp thực nghiệm triển khai thực tế trên hệ thống (Proof of Concept - PoC).
  • Phạm vi: Khảo sát trên cụm 3-node Minikube chạy Linux Kernel 5.x; kiểm thử tính thực thi chính sách trên ứng dụng thương mại điện tử Microservices; đánh giá tính toàn vẹn gói tin bằng tcpdump và kiểm tra xác thực thông qua SPIRE Server.
  • Chỉ số kỳ vọng: Đảm bảo 100% các kết nối trái phép ở tầng L3/L4/L7 bị triệt tiêu (Drop); độ trễ xử lý gói tin tối ưu hơn cơ chế tuần tự của iptables; giám sát luồng dữ liệu đạt độ trễ dưới 1 giây qua Hubble UI.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Trong môi trường Kubernetes truyền thống, các giải pháp CNI đời đầu (như Flannel hoặc Calico dùng chế độ iptables tiêu chuẩn) phụ thuộc hoàn toàn vào hệ thống chuỗi gói tin của Linux Netfilter. Khi cụm mở rộng tới hàng ngàn dịch vụ, số lượng quy tắc iptables tăng lên hàng chục ngàn, dẫn tới hiện tượng suy giảm hiệu năng nghiêm trọng (O(N) lookup time) và thiếu khả năng hiểu biết ngữ cảnh ứng dụng (Application-Awareness).

Tiêu chí kỹ thuật Native K8s Network Policy Calico (iptables mode) Cilium (eBPF Native)
Cơ chế thực thi Datapath Netfilter / iptables iptables / IPVS / eBPF eBPF Kernel Space
Phạm vi kiểm soát OSI Layer 3 & Layer 4 Layer 3 & Layer 4 (L7 cần sidecar) Layer 3, Layer 4 & Layer 7 (Native)
Định danh chính sách Nhãn Pod & Dải IP (CIDR) Nhãn Pod, IP, Workload Profile Endpoint Identity & Metadata động
Hỗ trợ DNS-based Policy Không hỗ trợ gốc Hỗ trợ hạn chế qua Calico Enterprise Tích hợp sẵn qua FQDN/DNS Proxy
Mã hóa Node-to-Node Không tích hợp sẵn IPsec / WireGuard WireGuard / IPsec in-kernel
Khả năng quan sát (Observability) Cơ bản qua CNI log Calico Flow Logs Hubble (gRPC, Flow Metrics, UI)

Phân loại yêu cầu hệ thống theo mô hình MoSCoW

  • Must-Have (Bắt buộc): Triển khai Cilium CNI v1.14+ trên cụm Kubernetes; thiết lập CiliumNetworkPolicy L3/L4/L7; cô lập dữ liệu cơ sở dữ liệu catalogue-db và user-db; trực quan hóa lưu lượng bằng Hubble UI.
  • Should-Have (Nên có): Kích hoạt mã hóa trong suốt WireGuard giữa các Node; chặn kết nối Egress trái phép bằng DNS filtering.
  • Could-Have (Có thể có): Tích hợp SPIFFE/SPIRE để cấp phát chứng chỉ X.509 SVID ngắn hạn tự động cho Pods.
  • Won't-Have (Chưa triển khai): Mở rộng kiến trúc liên cụm (Cilium ClusterMesh đa vùng) trong phạm vi đề tài này.

Thiết kế kiến trúc hệ thống

Kiến trúc giải pháp được thiết kế theo mô hình phân lớp rõ ràng, tận dụng sức mạnh điều phối của Kubernetes API Server và năng lực can thiệp gói tin của eBPF tại nhân Linux.

graph TB
    subgraph ControlPlane["Master Node (minikube)"]
        APIServer["Kubernetes API Server"]
        CiliumOp["Cilium Operator"]
        SpireServer["SPIRE Server"]
    end

    subgraph Worker1["Worker Node 1: minikube-m02 (zone=back-end)"]
        CA1["Cilium Agent (eBPF Engine)"]
        HS1["Hubble Server"]
        PodFE["Pod: Front-End (NodeJS:8079)"]
        PodOrder["Pod: Order (Java/.NET)"]
        PodPay["Pod: Payment (Go)"]
    end

    subgraph Worker2["Worker Node 2: minikube-m03 (zone=database)"]
        CA2["Cilium Agent (eBPF Engine)"]
        HS2["Hubble Server"]
        PodUserDB[("Pod: user-db (MongoDB)")]
        PodCatDB[("Pod: catalogue-db (MySQL)")]
        PodMQ["Pod: RabbitMQ"]
    end

    APIServer -->|Đồng bộ CRD / Policy| CA1
    APIServer -->|Đồng bộ CRD / Policy| CA2
    CA1 <===>|WireGuard In-Kernel Tunnel (Encrypted)| CA2
    PodFE -->|L7 REST Filter: /login| CA1
    CA1 -->|Cho phép / Chặn L3/L4/L7| CA2
    CA2 --> PodCatDB
    CA2 --> PodUserDB

Danh mục công nghệ và phiên bản sử dụng

  • Hệ điều hành Host: Linux Kernel $\ge 5.4$ (hỗ trợ đầy đủ eBPF BPF-to-BPF calls & WireGuard module).
  • Nền tảng Kubernetes: Minikube v1.32.0 (Kubernetes v1.28+).
  • Hạ tầng mạng & Bảo mật: Cilium CNI v1.14.0, Cilium CLI v0.15+, Hubble Relay/UI v0.12+.
  • Khung định danh phân tán: SPIFFE / SPIRE Server & Agent v1.8+.
  • Ứng dụng thử nghiệm (Microservices): Sock Shop Cloud-Native Demo Application.
  • Công cụ phân tích & kiểm thử: kubectl, tcpdump, curl, wireshark, ping (iputils).

Phương pháp luận triển khai (Methodology)

Dự án áp dụng mô hình phát triển phần mềm lặp tăng tiến (Iterative Engineering & DevSecOps Lifecycle) chia làm 4 giai đoạn chính:

[ Giai đoạn 1: Hạ tầng & Cụm ] ---> [ Giai đoạn 2: Ứng dụng & CNI ]
              │                                      │
              ▼                                      ▼
[ Giai đoạn 4: Đánh giá & Giám sát ] <--- [ Giai đoạn 3: Thực thi Chính sách ]
  1. Giai đoạn 1 (Milestone 1 - Tuần 1-2): Chuẩn bị môi trường máy chủ Linux, thiết lập cụm Minikube đa Node và cấu hình gán nhãn Topology (zone=front-end, zone=back-end, zone=database).
  2. Giai đoạn 2 (Milestone 2 - Tuần 3-4): Xây dựng container image cho Microservices, triển khai Manifests lên Kubernetes namespace sock-shop, tích hợp Cilium CNI và kích hoạt hệ thống Hubble.
  3. Giai đoạn 3 (Milestone 3 - Tuần 5-7): Xây dựng các tệp cấu hình CiliumNetworkPolicy (L3/L4/L7, DNS Egress), cấu hình tham số WireGuard trên Cilium Agent và tích hợp SPIFFE Workload Attestation.
  4. Giai đoạn 4 (Milestone 4 - Tuần 8-9): Kiểm thử xâm nhập giả lập (Penetration Test), phân tích gói tin mạng với tcpdump, đo đạc hiệu năng và đánh giá kết quả.

Implementation và kết quả

Quy trình phát triển và triển khai kỹ thuật

1. Phân vùng cụm Node và triển khai Microservices

Để đảm bảo tính cô lập và phản ánh cấu trúc môi trường thực tế, cụm Kubernetes được cấu hình gồm 1 Master Node và 2 Worker Node bằng công cụ Minikube. Đoạn mã Shell tự động hóa gán nhãn phân vùng được triển khai như sau:

#!/bin/bash
# node_labels.sh - Tự động phân loại nhãn phân vùng cho cụm Kubernetes
declare -A NODES_LABELS=(
  ["minikube"]="zone=front-end"
  ["minikube-m02"]="zone=back-end"
  ["minikube-m03"]="zone=database"
)

for NODE in "${!NODES_LABELS[@]}"; do
  LABEL=${NODES_LABELS[$NODE]}
  echo "Đang gán nhãn cho node $NODE với nhãn $LABEL"
  kubectl label node $NODE $LABEL --overwrite
  if [ $? -eq 0 ]; then
    echo "Node $NODE đã được gán nhãn thành công."
  else
    echo "Lỗi khi gán nhãn cho node $NODE"
  fi
done

Dịch vụ front-end được tối ưu hóa qua Dockerfile nhiều tầng (Multi-stage build) sử dụng image siêu nhẹ node:10-alpine, loại bỏ quyền root nhằm tuân thủ nguyên tắc đặc quyền tối thiểu:

FROM node:10-alpine
ENV NODE_ENV "production"
ENV PORT 8079
EXPOSE 8079

# Tạo người dùng không đặc quyền (non-root user)
RUN addgroup mygroup && adduser -D -G mygroup myuser && \
    mkdir -p /usr/src/app && chown -R myuser /usr/src/app

WORKDIR /usr/src/app
COPY package.json yarn.lock /usr/src/app/
RUN chown myuser /usr/src/app/yarn.lock

USER myuser
RUN yarn install --frozen-lockfile

COPY . /usr/src/app
CMD ["/usr/local/bin/npm", "start"]

2. Cài đặt Cilium CNI và kích hoạt Hubble

Quá trình cài đặt Cilium CNI lên cụm Kubernetes được thực hiện thông qua công cụ dòng lệnh Cilium CLI:

# Cài đặt Cilium CNI v1.14 vào cụm K8s
cilium install --version 1.14.0

# Kiểm tra tình trạng sẵn sàng của các thành phần
cilium status --wait

# Kích hoạt nền tảng giám sát mạng Hubble và giao diện UI
cilium hubble enable
cilium hubble enable --ui

3. Thiết lập chính sách bảo mật mạng với CiliumNetworkPolicy (CNP)

  • Chính sách 1: Cô lập cơ sở dữ liệu tại tầng L3/L4 (restrict-catalogue-db.yaml) Chỉ cho phép các Pod thuộc nhóm role: back-end truy vấn tới cổng dịch vụ của cơ sở dữ liệu catalogue-db, triệt tiêu hoàn toàn nguy cơ truy cập trực tiếp từ tầng front-end:
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: restrict-catalogue-db
  namespace: sock-shop
spec:
  endpointSelector:
    matchLabels:
      name: catalogue-db
  ingress:
    - fromEndpoints:
        - matchLabels:
            role: back-end
      toPorts:
        - ports:
            - port: "3306"
              protocol: TCP
  • Chính sách 2: Lọc sâu API tầng ứng dụng L7 (l7-policy.yaml) Kiểm soát lưu lượng từ front-end tới Pod user, chỉ chấp nhận duy nhất phương thức HTTP GET tại đường dẫn endpoint /login. Mọi hành vi tấn công thăm dò các API nhạy cảm khác (như POST /register, GET /customers) đều bị chặn đứng ngay tại tầng Kernel:
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l7-policy
  namespace: sock-shop
spec:
  endpointSelector:
    matchLabels:
      name: user
  ingress:
    - fromEndpoints:
        - matchLabels:
            name: front-end
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "^/login$"
  • Chính sách 3: Ngăn chặn rò rỉ dữ liệu qua DNS Egress Filtering (dns-egress.yaml) Chặn đứng các luồng kết nối độc hại ra ngoài Internet từ Pod nội bộ, chỉ cho phép phân giải tên miền và kết nối tới các dịch vụ thanh toán hợp lệ:
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: dns-egress
  namespace: sock-shop
spec:
  endpointSelector:
    matchLabels:
      name: payment
  egress:
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            k8s-app: kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchPattern: "*.paypal.com"

Kiểm thử, đánh giá và kết quả thực nghiệm

+-----------------------------------------------------------------------------------+
|                        KẾT QUẢ THỰC NGHIỆM ĐO ĐẠC GÓI TIN                         |
+-----------------------------------------------------------------------------------+
| [Kịch bản 1] Frontend --> catalogue-db (Port 3306)   ===> [DROP / Connection Refused]
| [Kịch bản 2] Frontend --> User API (GET /login)      ===> [ALLOW - HTTP Status 200 OK]
| [Kịch bản 3] Frontend --> User API (POST /customers) ===> [DROP / 403 Forbidden]   |
| [Kịch bản 4] Bắt gói tin Node-to-Node với tcpdump   ===> [WireGuard Encrypted]    |
| [Kịch bản 5] Truy vấn Pod chưa có SPIFFE ID          ===> [mTLS Handshake Rejected] |
+-----------------------------------------------------------------------------------+

1. Kiểm thử chính sách L3/L4 và L7

  • Thực thi Ping & ICMP: Khi áp dụng restrict-catalogue-db, lệnh ping từ Pod front-end tới địa chỉ IP của Pod catalogue-db bị chặn hoàn toàn ($100%$ packet loss), trong khi các dịch vụ back-end hợp lệ vẫn duy trì kết nối với độ trễ phản hồi $< 0.8\text{ ms}$.
  • Kiểm thử L7 HTTP Filter:
    • Thực hiện curl -X GET http://user/login: Trả về mã phản hồi HTTP 200 OK.
    • Thực hiện curl -X POST http://user/customers: eBPF HTTP parser lập tức can thiệp và phản hồi mã 403 Access Denied trực tiếp tại nhân mạng. Trên giao diện Hubble UI, các sự kiện vi phạm chính sách được hiển thị cảnh báo đỏ với trạng thái DROPPED (Policy denied).

2. Kiểm thử mã hóa trong suốt WireGuard

Sử dụng công cụ tcpdump bắt gói tin trực tiếp trên giao diện mạng vật lý eth0 giữa hai máy ảo Worker Node:

# Bắt gói tin truyền giữa minikube-m02 và minikube-m03
sudo tcpdump -i eth0 udp port 51871 -X -vv
  • Kết quả: Toàn bộ dữ liệu trao đổi giữa các Pod chạy trên hai Node khác nhau đều được đóng gói thành các gói tin UDP WireGuard đã được mã hóa theo thuật toán ChaCha20-Poly1305. Toàn bộ thông tin nhạy cảm (plaintext HTTP payload, SQL queries, thông tin tài khoản) hoàn toàn không thể bị đọc trộm bằng kỹ thuật Man-in-the-Middle (MitM).

3. Bảng tổng hợp mức độ hoàn thành mục tiêu

Mục tiêu nghiên cứu ban đầu Kết quả thực tế đạt được Đánh giá hiệu năng / Độ chính xác
Phân vùng mạng đa Node 100% Pods được gán đúng nodeSelector Phân tách ranh giới an toàn tuyệt đối
Chính sách L3/L4 Identity Triệt tiêu kết nối ngoài luồng nghiệp vụ Thời gian áp dụng chính sách $< 100\text{ ms}$
Kiểm soát API Layer 7 Lọc chính xác HTTP Methods và Endpoints Chặn 100% payload sai lệch quy chuẩn
Mã hóa WireGuard Tự động hóa toàn bộ inter-node traffic Băng thông đạt xấp xỉ $\sim 96%$ đường truyền gốc
Xác thực SPIFFE/SPIRE Cấp phát danh tính động tự động Xác thực mTLS không cần sidecar container
Giám sát trực quan Hubble Cung cấp Flow graph và Metrics chi tiết Tải tiêu thụ CPU của Hubble Agent $< 1.5%$

Đổi mới và đóng góp

Khóa luận mang lại những đóng góp rõ nét cả về mặt học thuật ứng dụng lẫn giải pháp kỹ thuật cho hạ tầng bảo mật Cloud-Native:

graph LR
    subgraph Traditional["Kiến trúc Truyền thống (Netfilter/Sidecar)"]
        App1["App Container"] <--> Sidecar["Envoy Proxy Sidecar"]
        Sidecar <--> IPTables["iptables / Netfilter Chains"]
        IPTables <--> Kernel1["Linux Kernel"]
    end

    subgraph CiliumeBPF["Kiến trúc Đổi mới với Cilium (eBPF Native)"]
        App2["App Container"]
        App2 <===>|Bypass Sidecar & iptables| eBPFEngine["eBPF In-Kernel Engine"]
        eBPFEngine <--> Kernel2["Linux Kernel Core"]
    end

Các cải tiến kỹ thuật nổi bật

  1. Loại bỏ hoàn toàn chi phí Sidecar Proxy: Thay vì phải chèn một container proxy phụ trợ (như Envoy trong Istio Service Mesh) vào từng Pod gây tốn bộ nhớ RAM (khoảng $50\text{ MB} - 100\text{ MB}$ cho mỗi Pod) và làm tăng độ trễ mạng qua 2 lần chuyển đổi context switch, Cilium thực thi logic L7 và mTLS ngay trong nhân thông qua eBPF helper functions.
  2. Định danh workload không phụ thuộc IP (Identity-Based Security): Giải quyết triệt để vấn đề "IP Churn" trong Kubernetes (khi Pod liên tục bị xóa và tạo mới với IP khác nhau). Cilium gán một số nguyên Identity 32-bit cố định dựa trên tập hợp Labels, giúp việc tra cứu luật trong eBPF BPF Map đạt độ phức tạp thuật toán $O(1)$.
  3. Bảo mật Egress thông minh dựa trên FQDN/DNS: Khắc phục nhược điểm của Network Policy tiêu chuẩn vốn chỉ hỗ trợ dải IP tĩnh. Cơ chế DNS proxy nội tại của Cilium tự động theo dõi các phản hồi DNS (DNS Response Snooping) để cập nhật danh sách IP động của các dịch vụ bên thứ ba trong thời gian thực.

Ứng dụng thực tế và triển khai

Kịch bản ứng dụng trong doanh nghiệp

  • Hệ thống Ngân hàng và Tài chính số (Fintech): Đáp ứng các tiêu chuẩn khắt khe về an toàn dữ liệu như PCI-DSS và ISO 27001 bằng cách mã hóa toàn bộ dữ liệu luân chuyển trên mạng nội bộ (Data in Transit Encryption) thông qua WireGuard và kiểm soát chặt chẽ quyền truy cập cơ sở dữ liệu tài khoản người dùng.
  • Hạ tầng Thương mại điện tử quy mô lớn: Đảm bảo hệ thống đứng vững trong các sự kiện cao điểm khuyến mãi; ngăn ngừa tấn công lateral movement khi một Pod giao diện công cộng bị khai thác lỗ hổng RCE.
  • Hệ thống Multi-tenant SaaS: Cách ly lưu lượng mạng giữa các khách hàng doanh nghiệp khác nhau dùng chung một cụm Kubernetes duy nhất với chi phí vận hành tối thiểu.

Yêu cầu hệ thống và khuyến nghị phần cứng

+-----------------------------------------------------------------------------------+
|                           YÊU CẦU PHẦN CỨNG VÀ MÔI TRƯỜNG                         |
+-----------------------------------------------------------------------------------+
|  [Hệ điều hành Host]  : Ubuntu Server 22.04 LTS / RHEL 9 (Kernel >= 5.4)          |
|  [Cấu hình Master Node]: Tối thiểu 2 vCPU, 4GB RAM, 20GB SSD                      |
|  [Cấu hình Worker Node]: Tối thiểu 4 vCPU, 8GB RAM, 50GB SSD                      |
|  [Phần mềm bổ trợ]    : Docker Engine v24+, Minikube v1.32+, kubectl v1.28+       |
+-----------------------------------------------------------------------------------+

Lộ trình triển khai khuyến nghị (6 bước)

  1. Bước 1 - Khảo sát hạ tầng: Nâng cấp Linux Kernel trên toàn bộ máy chủ Worker lên phiên bản hỗ trợ tốt nhất cho eBPF ($\ge 5.15$).
  2. Bước 2 - Triển khai thử nghiệm (Staging): Cài đặt Cilium ở chế độ giám sát (policyEnforcement=Audit), sử dụng Hubble để ghi nhận toàn bộ luồng kết nối thực tế mà không chặn gói tin.
  3. Bước 3 - Xây dựng Profile chính sách: Từ dữ liệu trực quan của Hubble UI, xuất ra các mẫu CiliumNetworkPolicy tương ứng cho từng nhóm dịch vụ nghiệp vụ.
  4. Bước 4 - Bật chế độ phòng vệ chủ động (policyEnforcement=Default): Thực thi áp dụng các luật L3/L4/L7 vào môi trường.
  5. Bước 5 - Kích hoạt mã hóa Transparent WireGuard: Bật tham số encryption.type=wireguard trong Helm values để bảo vệ toàn bộ đường truyền liên máy chủ.
  6. Bước 6 - Tích hợp hệ thống cảnh báo (SIEM): Kết nối Hubble Metrics với Prometheus, Grafana và hệ thống giám sát an ninh tập trung của doanh nghiệp.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật hiện tại

  • Ràng buộc phiên bản Kernel: Các máy chủ chạy nhân Linux cũ ($< 4.19$) không thể khai thác đầy đủ các tính năng nâng cao như WireGuard in-kernel hoặc L7 eBPF redirection.
  • Độ phức tạp khi gỡ lỗi (Debugging Complexity): eBPF Bytecode chạy trực tiếp trong không gian Kernel, do đó việc phân tích lỗi yêu cầu kỹ sư có trình độ chuyên môn cao về hệ điều hành và các công cụ chuyên dụng (bpftool, cilium-bugtool).
  • Môi trường thực nghiệm: Do hạn chế về tài nguyên phần cứng, mô hình thử nghiệm được xây dựng trên cụm máy ảo Minikube, chưa đánh giá hết các biến số về độ trễ mạng thực tế trên hạ tầng đám mây phân tán đa vùng (Multi-Region / Multi-Cloud).

Hướng nghiên cứu và phát triển tiếp theo

  • Tích hợp Cilium Tetragon: Bổ sung cơ chế giám sát an ninh mức Runtime (Runtime Security Enforcement), truy vết trực tiếp các lời gọi hàm hệ thống (System Calls - sys_exec, sys_open, sys_socket) để phát hiện và ngăn chặn mã độc, leo thang đặc quyền theo thời gian thực.
  • Mở rộng mô hình Cilium ClusterMesh: Thiết lập chính sách bảo mật đồng nhất cho hạ tầng đa cụm Kubernetes kết nối xuyên suốt giữa On-Premise và Cloud (AWS EKS, Google GKE).
  • Tự động hóa sinh chính sách bằng AI/ML: Tận dụng dữ liệu luồng mạng lịch sử từ Hubble kết hợp thuật toán máy học để tự động sinh và cập nhật CiliumNetworkPolicy theo cơ chế thích ứng động (Adaptive Zero Trust).

Đối tượng hưởng lợi

+------------------------------------------------------------------------------------+
|                         BẢNG GIÁ TRỊ DÀNH CHO CÁC NHÓM ĐỐI TƯỢNG                   |
+------------------------------------------------------------------------------------+
| [Sinh viên / Học viên]  : Tài liệu mẫu chi tiết về eBPF, K8s Networking & DevSecOps|
| [Kỹ sư DevSecOps / SRE] : Bộ manifests chuẩn, giải pháp giảm 40% CPU overhead      |
| [Doanh nghiệp Cloud]   : Kiến trúc Zero Trust hoàn chỉnh, đạt chuẩn PCI-DSS        |
| [Nhà nghiên cứu An ninh]: Nền tảng thực nghiệm đo đạc chính sách mạng thế hệ mới   |
+------------------------------------------------------------------------------------+
  1. Sinh viên và Người học: Tiếp cận tài liệu thực hành có tính ứng dụng cao, nắm vững cơ chế hoạt động của Linux Kernel eBPF, kiến trúc điều phối Kubernetes và các chuẩn mực an toàn thông tin hiện đại.
  2. Kỹ sư DevSecOps và Quản trị hệ thống (SRE): Sở hữu giải pháp mẫu hoàn chỉnh để thay thế kube-proxy, tối ưu hóa hiệu năng cụm máy chủ và chuẩn hóa quy trình cấu hình chính sách bảo mật mạng khai báo (Declarative Security).
  3. Doanh nghiệp và Tổ chức công nghệ: Giảm thiểu đáng kể chi phí hạ tầng (nhờ loại bỏ sidecar proxies tiêu tốn tài nguyên), rút ngắn thời gian khắc phục sự cố mạng qua Hubble và tăng cường năng lực phòng thủ trước các đợt tấn công nhắm vào chuỗi cung ứng phần mềm.
  4. Nhà nghiên cứu An toàn Thông tin: Có được khung kiểm thử thực nghiệm vững chắc để tiếp tục phát triển các thuật toán phát hiện xâm nhập (IDS/IPS) nhúng trực tiếp trong Linux Kernel.

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật tối thiểu để triển khai giải pháp Cilium là gì?

Hệ thống yêu cầu các Worker Node chạy hệ điều hành Linux với Kernel tối thiểu phiên bản 4.19 (khuyến nghị $\ge 5.4$ để hỗ trợ đầy đủ WireGuard và L7 eBPF). Cụm Kubernetes đạt phiên bản từ v1.22 trở lên, cấu hình mạng mở sẵn quyền quản trị nhân (CAP_BPF, CAP_NET_ADMIN, CAP_SYS_ADMIN) cho DaemonSet của Cilium.

2. Cilium mở rộng quy mô (Scalability) tốt hơn cơ chế iptables truyền thống như thế nào?

Cilium sử dụng BPF Hash Maps với độ phức tạp tìm kiếm cố định $O(1)$ thay vì duyệt tuần tự từng dòng quy tắc với độ phức tạp $O(N)$ như iptables. Khi hệ thống có hàng chục ngàn Pod và Services, tốc độ xử lý gói tin của Cilium gần như giữ nguyên, giảm tới $40% - 60%$ phụ tải CPU trên mỗi Node.

3. Có thể triển khai Cilium tích hợp song song với hệ thống mạng K8s hiện có không?

Có. Cilium hỗ trợ nhiều chế độ triển khai linh hoạt:

  • Chế độ Overlay Network (sử dụng Geneve hoặc VXLAN encapsulation) hoạt động trên bất kỳ hạ tầng mạng sẵn có nào mà không cần thay đổi cấu hình Switch/Router vật lý.
  • Chế độ Direct Routing / Native Routing (định tuyến trực tiếp qua BGP) cho các trung tâm dữ liệu đòi hỏi hiệu năng tối đa.

4. Chi phí vận hành và bảo trì hệ thống bảo mật bằng Cilium ra sao?

Cilium là dự án mã nguồn mở thuộc cấp độ Tốt nghiệp (Graduated) của quỹ CNCF, hoàn toàn miễn phí bản quyền. Do hoạt động không cần Sidecar container, giải pháp giúp tiết kiệm đáng kể chi phí cấp phát bộ nhớ RAM và CPU trên toàn cụm. Việc bảo trì được tự động hóa qua Helm Chart hoặc Cilium CLI với khả năng nâng cấp không gây gián đoạn dịch vụ (Rolling Upgrades).

5. Mã hóa WireGuard trong Cilium có làm giảm đáng kể tốc độ mạng không?

Không đáng kể. Do thuật toán mật mã hiện đại ChaCha20-Poly1305 được thực thi trực tiếp bên trong Linux Kernel module kết hợp với khả năng định tuyến eBPF, độ suy hao thông lượng mạng chỉ dao động trong khoảng $3% - 5%$ so với đường truyền vật lý gốc, vượt trội hoàn toàn so với giải pháp IPsec truyền thống hoặc mã hóa qua proxy người dùng (User-space TLS proxy).

Kết luận

Đồ án tốt nghiệp "Triển khai giải pháp bảo mật cho hệ thống Kubernetes sử dụng Cilium" của tác giả Bạch Văn Xuân Thông đã giải quyết xuất sắc các thách thức bảo mật cốt lõi trong hạ tầng vi dịch vụ đám mây. Bằng việc khai thác sức mạnh vượt trội của công nghệ eBPF, giải pháp không chỉ mang lại cơ chế kiểm soát truy cập đa tầng L3/L4/L7 chi tiết, mã hóa dữ liệu trong suốt và xác thực danh tính phân tán, mà còn nâng cao đáng kể hiệu năng vận hành và cung cấp khả năng quan sát toàn diện thông qua Hubble.

Kết quả nghiên cứu và thực nghiệm chứng minh tính khả thi, độ tin cậy và giá trị thực tiễn cao của mô hình trong việc xây dựng các hệ sinh thái Cloud-Native an toàn, sẵn sàng đáp ứng các tiêu chuẩn khắt khe của môi trường sản xuất doanh nghiệp hiện đại.