Trong môi trường Cloud Native hiện đại, bức tường lửa bao quanh (Perimeter-based Security) đã hoàn toàn lỗi thời. Mô hình Zero-Trust Security (Không tin tưởng bất kỳ ai, luôn xác thực mọi kết nối - Never Trust, Always Verify) là tiêu chuẩn bắt buộc cho mọi cụm Kubernetes chạy môi trường Production.

Bài viết này hướng dẫn chi tiết 4 lớp bảo mật then chốt giúp cô lập và bảo vệ toàn diện hệ thống Container phân tán.

1. Mã Hóa Kết Nối Nội Bộ Bằng mTLS Với Istio Service Mesh

Mặc định trên Kubernetes, lưu lượng trao đổi giữa các Pod trong mạng CNI (Overlay Network) hoàn toàn là dạng văn bản rõ (Clear Text). Kẻ tấn công khi thâm nhập vào một Pod bị lộ lọt có thể bắt gói tin (Packet Sniffing) của toàn bộ các service khác.

Istio Service Mesh giải quyết triệt để vấn đề này bằng cách tự động tiêm Envoy Sidecar Proxy, quản lý vòng đời chứng chỉ số X.509 và thực thi xác thực tương hỗ Mutual TLS (mTLS) ở chế độ nghiêm ngặt (STRICT):

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

2. Kiểm Soát Chính Sách Với Kyverno / OPA Gatekeeper

Để ngăn ngừa lỗi cấu hình (Misconfigurations) của các lập trình viên khi deploy manifest, chúng ta sử dụng Admission Controller để chặn đứng các Pod vi phạm quy chuẩn an ninh ngay tại cửa ngõ Kubernetes API Server.

Ví dụ chính sách Kyverno bắt buộc toàn bộ Pod phải chạy dưới quyền người dùng không đặc quyền (non-root) và cấm hoàn toàn cờ privileged:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-run-as-non-root
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: check-runAsNonRoot
      match:
        any:
        - resources:
            kinds:
              - Pod
      validate:
        message: "Chính sách bảo mật: Toàn bộ container bắt buộc phải khai báo securityContext.runAsNonRoot = true!"
        pattern:
          spec:
            securityContext:
              runAsNonRoot: true
            containers:
              - securityContext:
                  allowPrivilegeEscalation: false
                  capabilities:
                    drop:
                      - ALL

3. Giám Sát Thời Gian Thực (Runtime Security) Bằng eBPF & Falco

Ngay cả khi container đã vượt qua khâu rà quét ảnh (Image Vulnerability Scanning), kẻ tấn công vẫn có thể khai thác các lỗ hổng Zero-day trong quá trình chạy. Falco sử dụng công nghệ nhân Linux eBPF (Extended Berkeley Packet Filter) để giám sát các System Calls ở tầng kernel với chi phí tài nguyên cực thấp.

Bảng So Sánh Các Lớp Giám Sát An Ninh Kubernetes

Ví dụ quy tắc cảnh báo Falco phát hiện ai đó đang mở Interactive Shell bên trong Pod Production:

- rule: Terminal shell in container
  desc: Phát hiện hành vi mở shell (bash, sh, zsh) bên trong container production
  condition: >
    spawned_process and container
    and shell_procs and proc.pname exists
    and not k8s.ns.name in (kube-system, monitoring)
  output: "⚠️ CẢNH BÁO AN NINH: Shell được khởi tạo trong container (user=%user.name pod=%k8s.pod.name ns=%k8s.ns.name cmd=%proc.cmdline)"
  priority: WARNING

4. Quản Lý Secrets Tập Trung Với HashiCorp Vault & ESO

Không bao giờ lưu trữ mật khẩu, khóa API hoặc chứng chỉ SSL dưới dạng Kubernetes Secret Base64 thông thường trong Git repo (kể cả trong private repo). Thay vào đó, áp dụng mô hình External Secrets Operator (ESO) đồng bộ động từ HashiCorp Vault hoặc AWS Secrets Manager.

graph LR
    A[HashiCorp Vault] -->|Bảo mật & Dynamic Rotation| B(External Secrets Operator)
    B -->|Tạo tự động| C[K8s Secret In-Memory]
    C -->|Gắn vào| D[Application Pod]

5. Danh Sách Kiểm Tra Zero-Trust Kubernetes

• [x] Toàn bộ Namespace áp dụng Pod Security Standards ở mức Restricted.
• [x] Bật mTLS STRICT trên toàn bộ Mesh nội bộ.
• [x] Chặn đứng toàn bộ lưu lượng Egress ra Internet trừ các Domain được whitelist rõ ràng.
• [x] Tích hợp quét lỗ hổng container tự động vào Pipeline GitHub Actions / GitLab CI.
• [x] Cài đặt Falco eBPF giám sát các hành vi bất thường tầng kernel.